微服務：Java 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的支援正在走下坡路。

随着微服務越來越多地受到關注，這些應用伺服器很難有好的銷量，因為這些伺服器更适合用來部署單體應用。有一個包含了數百個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容器。

微服務一般會提供基于http/json的api端點。這樣可以很容易地與其它服務（開源或閉源的）內建，隻要這些服務提供了http/json接口。服務可以通過更有意義的方式被消費、被組合。ec2、s3及其它來自amazon（或其它公司）的服務就是最好的例子。基礎設施會成為應用程式的一部分，而且它們是可程式設計的。

使用微服務架構的應用程式應該是子產品化、可程式設計和可組合的。微服務之間可以互相替換。應用程式的局部可以被重寫或改進，而不會影響到整個應用。如果所有的元件都提供了可程式設計的api，那麼微服務之間的互動就會變得更簡單（永遠不要相信那些不能通過curl通路的微服務）。

随着微服務逐漸流行起來，很多廠商開始嘗試把他們的java ee web服務轉成微服務，這樣他們就可以繼續賣他們的過時産品，api gateway就是這些廠商中的一個。

jason bloomberg是intellyx的主席，他在一篇文章裡指出了傳統web服務和微服務的差別，并對把傳統web服務轉成微服務的趨勢提出了質疑。

微服務不是企業服務總線裡的web服務，也不是傳統的面向服務架構，盡管它沿襲了soa的一些基本概念。從根本上來說，微服務跟soa是不一樣的，因為整個環境已經發生了徹底的轉變。

微服務架構的環境是沒有邊界的：端到端，基于雲的應用程式運作在完全虛拟和容器化的基礎設施上。容器把應用程式和服務元件化，devops為it基礎設施提供架構，幫助自動化開發、部署和管理環境。

雖然容器對微服務來說不是必需的，不過微服務可以很容易地運作在容器裡。況且，把非微服務的代碼部署在容器裡不是一個明智的選擇。

docker和其它容器技術在某種程度上已經被視為微服務的最好伴侶。容器是運作微服務的最小資源子集。docker簡化了微服務的開發，讓內建測試變得更簡單。

容器有助于微服務開發，但不是必需的。docker也可以被用來部署單體應用。微服務與容器可以很好地相融并進，不過微服務包含的東西遠比容器多！

結論

應用開發的風格這幾年一直在變化，而微服務變得越來越流行。大公司把大型應用拆分成可以單獨部署的小型應用，這些小型應用被部署在雲端的容器裡。開源微服務架構light java為這些運作在容器裡的微服務提供了很多特性，它支援設計驅動，開發者隻需要把注意力專注在業務邏輯上，剩下的事情可以由架構和devops流程來處理。

本文轉自d1net（轉載）