基于微服務的架構如今無處不在。 我們對Netflix和Amazon等當今的創新者如何利用它們在成功產生更多業務方面取得更大的成功了解到很多。 但是，我們所有人都在使用Java EE應用程序服務器并編寫經典系統嗎？ 我們都做錯了嗎？ 我們如何使我們的技術設計適合未來？

整體式

首先，讓我們研究一下那些經典系統。 或稱為單片應用程序。 即使最近這些詞有難聞的氣味，這也是我們構建軟件很長時間的方式。 它基本上描述了以下事實：我們構建單個應用程序來實現某些功能。

整體確實是指Java EE或最初設計的Java 2 Enterprise Edition的更好版本。 集中化的應用程序可以進行縮放和群集化，但不必通過構建就可以使其具有彈性。 在大多數情況下，他們在故障情況下都依賴于基礎架構和操作。

傳統上，Java EE應用程序遵循一些核心模式，并分為三個主要層：表示，業務和集成。 表示層打包在Web應用程序歸檔（WAR）中，而業務和集成邏輯則放在單獨的Java歸檔（JAR）中。 作為一個部署單元捆綁在一起，創建了一個所謂的企業歸檔（EAR）。 圍繞Java EE的技術和最佳實踐一直足以構建設計良好的整體應用程序。 但是大多數企業級項目往往會失去對架構的關注。 這就是為什么有時精心設計的意大利面條球是可視化項目依賴關系和內部結構的最佳方法的原因。 當這種情況發生時，我們很快就遇到了一些重大缺陷。 因為即使進行很小的更改，所有東西都過于耦合和集成，這需要大量的工作（或有時需要大量的重構），并且在將返工的零件投入生產之前，還必須從頭到尾仔細測試應用程序。

整個應用程序不僅僅是已編程的工件：它還包括不可計數的部署描述符和服務器配置文件，以及相關第三方環境的屬性。

變更的高風險以及將新配置投入生產的復雜性導致發行量越來越少。 一個新版本每年發布一次或兩次。 甚至團隊結構也受到這些整體軟件架構的嚴重影響。 數月的測試周期可能是最明顯的證明。 但是除此之外，壽命超過五年的項目往往會包含大量錯誤和功能數據庫。 而且，如果這還不夠困難，那么該測試就幾乎沒有資格-沒有驗收測試，并且幾乎沒有任何書面業務要求或設計和可用性方面的可識別領域。

處理這類企業項目需要多個團隊的共同努力，并且需要很多人來監督整個項目。 從軟件設計的角度來看，最終的應用程序具有非常技術性的層次。 業務組件或域主要由現有數據庫設計或過時的業務對象定義驅動。 我們的行業必須吸取這些教訓，我們不僅設法控制了這些企業整體，還發明了新的范例和方法來更好地管理它們。

因此，即使“獨石”一詞在當今被認為是設計不良的軟件的代名詞，這些體系結構也有許多好處。 整體應用程序易于開發，因為IDE和其他開發工具都是圍繞開發單個應用程序而設計的。 它是一個歸檔文件，可以與不同的團隊共享，并在其中封裝所有功能。 另外，圍繞Java EE的行業標準使企業能夠可靠地訪問不僅構建而且還運行這些應用程序所需的資源。 軟件供應商已經圍繞Java EE建立了扎實的知識庫，并且采購通常不是大問題。 迄今為止，與他們合作已有15年以上的時間，該行業終于能夠以或多或少的產品化和標準化方式來制造這些應用程序。 我們知道要使用哪些構建工具，哪些流程可以在大型團隊中擴展以及如何擴展這些應用程序。 自從出現Arquillian之類的工具以來，甚至集成測試也變得更加容易。 為了像Java EE這樣的成熟解決方案的便利，我們仍在付出代價。 代碼庫可能會變得很大。 當應用程序在企業中停留更長的時間時，它們將變得越來越復雜，并且對于開發團隊來說更難理解。 即使我們知道如何配置應用程序服務器，每個項目中的一兩個特殊設置仍然會引起操作上的頭疼。

微服務

但是我們的行業并沒有停滯不前。 幾年前，系統架構和設計的下一次發展才剛剛開始。 隨著集中式集成組件的復雜性不斷增加以及所連接應用程序的額外開銷，人們開始尋找更輕便，更具彈性的產品。 最終，整個理論從大型的重量級基礎架構和設計轉移了。 除此以外，IT部門開始重新審視應用服務器以及冗長的協議和接口技術。

由于在基于SOA和ESB的項目中大多數服務實現都被證明是不切實際的，因此技術設計又回到了更方便的工件和服務上。 微服務代替了智能路由和轉換，而是使用簡單路由并將邏輯封裝在端點本身中。 即使名稱暗示了定義的大小，也沒有一個。 微服務是關于具有單一業務目的的。 對于企業設置而言，更麻煩的是，微服務最有效的運行時不一定是功能完善的應用程序服務器。 它可能只是一個servlet引擎，或者JVM已經足夠作為執行環境。 隨著運行時變體的不斷增長和編程語言選擇的多樣化，這種發展變成了另一場操作的噩夢。 而且，即使今天的開發人員在定義微服務以及如何將此設計應用于現有應用程序時也有些失落。

微服務被設計為小型，無狀態，相互依賴且完全包含的應用程序。 理想地能夠將它們部署到任何地方，因為部署包含所有必需的部分。

微服務被設計得很小。 但是定義“小”是主觀的。 可以使用某些估算技術，例如代碼行，功能點，用例。 但是通常，“小”與大小無關。
在《構建微服務》一書中，作者Sam Newman建議了幾種定義微服務大小的技術，它們是：

• 足夠小，可以由小型敏捷開發團隊擁有，
• 在一到兩個敏捷的沖刺（通常兩到四個星期）內可重寫
• 復雜性不需要進一步劃分服務

無狀態應用程序使用僅包含在其中的信息來處理每個請求。 微服務必須是無狀態的，并且必須在不記住來自外部系統的先前通信的情況下為請求提供服務。

微服務必須獨立處理請求，它可以與生態系統內的其他微服務協作。 例如，在與其他微服務交互后生成唯一報告的微服務是一個相互依賴的系統。 在這種情況下，僅向報告的微服務提供必要數據的其他微服務可能是獨立的服務。 一個完整的堆棧應用程序可以單獨部署。 它擁有自己的服務器，網絡和托管環境。 業務邏輯，數據模型和服務接口（API / UI）必須是整個系統的一部分。 微服務必須是全棧應用程序。

為什么是我？

“我已經經歷了足夠的工作，下一個Java EE版本已經在開發中。 我們甚至都沒有使用最新的Java EE7。有很多生產力功能即將出現：我不在乎是否只要它能完成工作并且我們就可以處理，就建造一個整體。 我確實了解這些想法。 我和您可能都一樣喜歡Java EE，并且很感興趣地發現為什么微服務最近得到了發展。 這兩個問題的答案可能不是一個簡單的答案：但是讓我們嘗試：

考慮到我們行業中的所有問題以及仍然存在大量項目失敗的情況，完全可以理解增長和消除問題的需求。 新的炒作和改良的方法論的很大一部分是人類的成長意愿。

而且，我們行業通常希望比上次做得更好，而不是“永遠不要觸摸運行中的系統”。
因此，首先要回答問題的第二部分：“您可能想研究一下，因為不做任何事情都不是解決方案。”

作為開發人員，架構師或質量保證工程師，我們基本上都注冊了實時學習。 我現在只能為自己說話，但這就是為什么我如此喜歡這份工作的很大一部分。 問題的第一部分不是那么容易回答。

創新和持續改進是企業和企業級項目的驅動力。 如果沒有創新，將存在過時且昂貴的基礎架構組件（例如主機系統），其生存期比其運行的軟件設計的壽命更長。 如果不對狀態進行持續驗證，將存在隱式或顯式的供應商鎖定。 老化的中間件將獲得擴展支持，只有少數供應商仍將能夠提供專門知識來開發它。 落后于最新標準的平臺堆棧試圖引入快速而骯臟的解決方案，最終導致技術債務。 微服務領域最杰出，發展最快的項目是開源項目。 Netflix OSS，Spring，Camel，Fabric8等是突出的例子。 通過如今的PaaS產品，使用多源全棧應用程序變得容易得多，這些產品也得到了Docker和Kubernetes等開源項目的支持。 在我們瞬息萬變的世界中，法律上導致軟件更改或簡單錯誤修復的交貨時間正在縮短。 很少有企業能夠在長達一個月的生產周期內工作，并且對軟件產生業務實際價值的需求更加明顯。 這不僅適用于完全由軟件驅動的公司，例如Uber，NetFlix，Amazon等。

我們需要構建具有靈活性和彈性的系統，而不僅僅是效率和健壯性。 今天，我們需要利用已有的資源開始構建它們。

我真的想確保您以正確的方式閱讀此聲明：我并不是說，從今天開始，一切都是微服務。

• 但是我們應該意識到他們可以提供幫助并能夠提供幫助的領域
• 在有意義的情況下，將現有應用程序更改為新方法。
• 我們希望能夠成為那些詢問該主題的人的優秀顧問

而且Java EE不會很快推出。 它將得到補充，多語言世界將在各個地方發展，但是我們不會很快擺脫它。 這是個好消息。

通過從developers.redhat.com下載我的免費電子書，了解有關如何將Java EE應用程序轉變為微服務的更多信息。 確保重新觀看有關“ Java EE微服務體系結構 ”的O'Reilly網絡廣播，并關注我的blog.eisele.net，了解有關WildFly Swarm ，Docker和帶有OpenShift的 Kubernetes的更多技術信息。

翻譯自: https://www.javacodegeeks.com/2015/12/microservices-java-ee.html

總結

以上是生活随笔為你收集整理的微服务和Java EE的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。