微服務與Java EE
時至今日，基於微服務的架構已經隨處可見了。我們見識到了Netflix與Amazon等創新者是如何透過微服務來取得業務上的成功。不過，對於那些使用Java EE伺服器，編寫傳統系統的開發者來說應該何去何從呢？我們一直所做的都是錯誤的麼？我們該如何讓技術設計能夠適應於未來？
單體架構
首先，我們來看一下這些傳統系統，或者說是單體應用。雖然單體這個詞現在看起來頗有一種壞味道之感，但這確實是我們長久以來構建軟體的方式。基本上，它指的是這樣一個事實，即我們構建一個個應用來實現某些功能。單體指的就是Java EE或是一開始的Java 2 Enterprise Edition設計的目標。集中式應用可以進行伸縮與叢集，但其設計卻不一定具有彈性。在大多數時候，其失敗場景都要依賴於底層基礎設施與運維。
傳統上，Java EE應用遵循著一些核心模式，並且會分成3個主要的層次：展現、業務與整合。展現層會被打包到Web Application Archives（WARs）中，業務與整合邏輯則會被劃分到單獨的Java Archives（JARs）中。他們會被打包作為一個部署單元，即所謂的Enterprise Archive（EAR）。
圍繞著Java EE的技術與最佳實踐足以構建出設計良好的單體應用。不過，大多數企業級專案都不太關注架構。這也說明了為何有時設計良好的義大利麵條是專案依賴與內部結構視覺化的最佳方式。當這發生時，我們很快就會體會到一些嚴重的缺陷。由於一切都是耦合並且整合到一起的，因此即便進行一些非常小的變更也需要大量的工作（有時還需要重構），然後才能將修改過的部分放到產品中；同時，我們還需要從始至終非常小心地對應用進行測試。整個應用不僅僅只是一些程式化的構件：它還包含了很多部署描述符以及服務端配置檔案，此外還有第三方環境的屬性等。
開發這些企業專案需要多個團隊聯手，需要很多人從更高的視角來審查整個專案。業務元件與領域大多數都是由既有的資料庫設計或是業務物件定義所驅動的。
變更的高風險與將新配置引入到生產中的複雜性會導致釋出頻率變得越來越低。新的釋出可能一年才有那麼幾次。甚至團隊結構都會受到單體軟體架構的嚴重影響。長久的測試周期就是最直觀的證據。
微服務
時代在不斷髮展，下一代系統架構與設計在幾年前出現了。隨著集中式整合元件日益增長的複雜性以及應用之間連線的成本越來越高，人們開始尋求更加輕量級、更加富有彈性的解決方案，逐步開始放棄大型、重量級基礎設施與設計。與之相伴的是IT部門開始重新審視應用伺服器以及冗長的協議和介面技術。對於那些基於SOA與ESB的專案來說，其服務實現迴歸到了更加敏捷的構件與服務中來。相對於智慧路由與轉換來說，微服務使用了簡單路由，並且將邏輯封裝到了端點本身當中。
微服務是圍繞單業務目標而展開的。雖然企業系統的設定讓人感到非常煩惱，但對於微服務來說，最有效的執行時卻並不一定是功能完善的應用伺服器。它可能只是個Servlet引擎，JVM已經足以作為一個執行環境了。
執行時千變萬化，程式語言的選擇也是數量龐大的，因此這種開發模式很可能會成為另一種運維夢魘。甚至連開發者都可能會在定義微服務以及如何將這種設計應用到既有應用中迷失方向。微服務的設計目標是要形成小型、無狀態、獨立且自包含的應用。在理想情況下，可以將其部署到任何地方，因為部署本身已經包含了所有必要的元件。
微服務要足夠小。不過，“小型”的定義是很主觀的。可以使用一些估算方法如程式碼行數、功能點、用例等。不過一般來說，“小型”與尺寸之間並沒有什麼必然的聯絡。在Building Microservices一書中，作者Sam Newman就微服務尺寸的定義給出了一些技術：
足夠小，可以由一個小型的敏捷開發團隊所擁有
可以在一兩個敏捷Sprint（一般來說是2到4周）中完成重寫
其複雜度不需要對服務做進一步拆分
無狀態應用在處理每個請求時只會使用請求所包含的資訊。微服務必須要是無狀態的，在處理請求時無需記住與外部系統之前通訊的資訊。微服務必須要能獨立處理請求，它可以與生態系統當中的其他微服務協作來進行處理。比如說，在與其他微服務互動後生成報表的微服務就是個相互依賴的系統。在這種場景中，只向報表微服務提供必要資料的微服務可能是個獨立服務。全棧應用本身是可以部署的。它擁有自己的伺服器、網路、託管環境。業務邏輯、資料模型與服務介面（API / UI）必須是整個系統的一部分。微服務必須是個全棧應用。
創新與持續不斷的改進是企業與企業級專案背後的助推器。如果沒有創新，那些過時與昂貴的基礎設施元件可能要比在他們上面執行的軟體的生命週期還要長。老舊的中介軟體可能會超期服役，結果是隻有少數供應商才知道如何開發它。落後於最新標準的平臺棧可能會引入臨時應急的解決方案，最終則會產生技術債務。將專案快速遷移到微服務的就是那些開源專案了。
Netflix OSS、Spring、Camel、Fabric8等都是很好的例子。藉助於當下的PaaS，我們可以更加輕鬆地操縱多語言構成的全棧應用，而PasS一般來說也是由諸如Docker和Kubernetes等開源專案所維護的。在這個快節奏的時代中，從開發到上線以及修復Bug的時間被大大縮短了。幾乎沒有多少企業還能夠容忍幾個月的產品週期，他們需要軟體為業務創造更多的價值。對於那些完全由軟體驅動的公司如Uber、NetFlix、Amazon等來說更是如此。我們需要針對靈活性與彈性來構建系統，而不僅僅是效率和健壯性。Java EE並不會消亡，它會得到補充和完善。
