有人認為，微服務的大行其道是在給Java EE下達死刑判決書。也有人認為，Java EE已死的論調可笑至極。的讀者朋友，你們怎麼看?
引言
有人說，Java確實過於臃腫，經常“小題大做”。但PHP、Node.js擴充套件方面短板太明顯，做小應用可以，大型應用就玩不轉了。另外，Java EE領域有太多優秀框架可以解決開發效率的問題，事實上借用Spring等框架，開發的效率絲毫不亞於PHP。
網際網路時代的Java開發者，很多都不是基於Servlet和EJB來開發Web應用，而且WebLogic、WebSphere也只會存在於大公司的存量系統中，網際網路公司的Java都是Tomcat的世界。
那麼，微服務能完全彌補Java EE的短板嗎?對於Jave EE來說，微服務扮演的，究竟是拯救者還是掘墓人的角色?
在Java問世之初，包括IBM、BEA、Oracle在內的一些巨頭公司，看到了Java作為一門傑出的Web程式語言可能給他們帶來的巨大商機。那麼如何通過一門程式語言來賺錢呢?答案就是，使用這門語言構建複雜無比的伺服器，讓那些大公司支付一大筆費用來購買這些伺服器。於是緊接著就出現了Java EE規範、JSR規範，以及WebLogic、WebSphere等伺服器中介軟體。
在這些伺服器上面部署了大型的程式包，它們執行緩慢，消耗大量的記憶體。基於這些容器的開發和除錯對開發人員來說簡直就是噩夢，作為對他們的補償，他們從僱主那裡獲得了豐厚的報酬。
因為耗資巨大，幾乎找不到一家公司可以使用合理的費用長時間地支援Java。如果你要用Java構建一個網站，你必須支付一大筆費用來執行這些伺服器，哪怕你只用到了Servlet容器。在很長一段時間裡，Java被用在企業和公司裡，因為只有這些大公司能夠負擔得起數百萬美元的伺服器費用，併為那些企業級開發人員支付高額的薪水。
Rod Johnson在2003年釋出了Spring框架，Spring提供了IoC和對POJO的支援，幫助開發人員逃脫EJB魔掌。開發效率因此得到大幅的提升，大量開發人員轉向Spring，把EJB丟在一邊。應用伺服器開發商看到了這一點，他們在Java EE 5裡提供了一些可以減輕開發人員負擔的特性。可惜的是，Spring被一路追捧，人們幾乎把它跟Java EE容器混為一談，它仍然執行在Java EE的Servlet容器裡，這些容器沿用的是十年前的設計，並沒有考慮到多核CPU和NIO。
在這期間，PHP奮起直追。PHP使用更少的記憶體和資源，得到很多公司的支援。一些CMS平臺，比如WordPress、Drupal等都是基於PHP構建的，這些平臺吸引了大批PHP開發人員。不過，雖然PHP仍然是現今最流行的程式語言，但它也有自己的短板。它執行速度不是很快，而且難以橫向擴充套件。
2009年，Ryan Dahl啟動了Node.js專案，它支援非同步非阻塞的、基於事件驅動的I/O。如果伺服器的執行緒使用得當，Node.js可以極大地提升響應速度，單個伺服器的吞吐量可以媲美一個Java EE伺服器叢集。Node.js是一個很好的作品，但它也有自己的侷限性。Node.js難以擴充套件，也難以與遺留的系統整合。
2014年，Undertow出現了，它是一個基於Java的非阻塞Web伺服器。從techempower.com的測試結果來看，在一個價值8000美金的戴爾伺服器上，它可以每秒鐘處理幾百萬個請求，而谷歌需要使用一個叢集才能處理一百萬個同樣的請求。它是輕量級的，它的核心部分只需要1M記憶體，它還包含了一個內嵌的伺服器，這個伺服器使用不到4M的堆記憶體。
基於Undertow Core構建的Light Java Framework是一個微服務容器，它支援設計驅動及生成程式碼，並支援執行時安全和執行時驗證。
Java EE廠商
多年前，Java EE廠商，比如Oracle和IBM，他們花費數億美元開發應用伺服器(WebLogic和WebSphere)，這些伺服器以數百萬的價格賣給了大型組織。但現在這些伺服器賣不動了，因為JBoss迅速搶佔了市場份額，Oracle對Java EE的支援正在走下坡路:
https://developers.slashdot.org/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee
隨著微服務越來越多地受到關注，這些應用伺服器很難有好的銷量，因為這些伺服器更適合用來部署單體應用。有一個包含了數百個EJB的應用，為了在WebLogic上測試一行程式碼改動，居然用了45分鐘時間。
Java EE客戶
從客戶角度來看，耗費巨資購買這些伺服器是不值得的，因為Java EE所承諾的未必都是真的。一個為WebSphere開發的應用無法部署在WebLogic上，所以你需要花更多的錢去升級伺服器，因為廠商可能不再支援舊版的伺服器，而這樣的更新會花費你數百萬美元。
於是一些聰明人不禁要問，為什麼我們要把應用部署在這些龐然大物上?為什麼我們要把應用打包成一個ear包或war包，而不是jar包?為什麼我們不能把大型的應用拆分成更小的塊，讓它們可以獨立部署和擴充套件?
微服務
微服務是這些問題的解藥。Wikipedia把微服務定義為“……一種軟體架構風格，複雜的應用由一些獨立的程序組成，這些程序使用與語言無關的API進行互動。這些程序服務規模很小，高度離散，聚焦在一個很小的任務上，使用模組化方式來構建系統”。
微服務架構讓構建應用變得更加容易，而且應用被拆分成單獨的服務，這些服務可以被任意組合。每個服務可以被獨立部署，也可以被組合成一個應用。這些服務還可能會被其他應用依賴。它加快了服務的開發速度，因為只要定義好介面，服務可以並行開發。
微服務具備彈性和伸縮性。微服務不只依賴單個伺服器和部署，它們可以被髮布到多個機器上，或者多個數據中心及其它任何可用的區域。如果一個服務失效，可以啟動另外一個。因為整個應用被分解成了微服務(小型服務)，可以很容易地對其中某些熱門的服務進行橫向擴充套件。
如果你曾經使用過COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那麼你就會知道服務和元件並不是什麼新生事物。企業在使用元件方面存在的一個最大問題是他們依賴大型的硬體伺服器，並在同一個伺服器上執行很多應用。我們有EJB、WAR包和EAR包，以及各種元件包，因為伺服器資源太過昂貴，要儘可能地物盡其用。
不過從最近幾年的發展情況來看，之前的方式有些落伍。作業系統伺服器一直在變化，虛擬資源可以被當成元件釋出，比如EC2、OpenStack、Vagrant和Docker。世界變了。微服務架構看到了這種趨勢，硬體、雲技術、多核CPU和虛擬技術也在發展，所以我們要改變以前的開發方式。
在開始新專案的時候不要再使用EAR包或WAR包了。現在我們可以在Docker裡執行JVM，Docker只不過是一個程序，但它可以表現得像一個作業系統一樣。Docker執行在雲端的作業系統上，而云端的作業系統執行在虛擬機器裡，虛擬機器執行在Linux伺服器上。這些伺服器不是歸誰所有，而是被很多互不相識的人共享。如果出現流量高峰怎麼辦?很簡單，使用更多的伺服器例項。這就是為什麼要把Java微服務執行在一個單獨的程序裡，而不是Java EE容器或servlet容器。