在Java問(wèn)世之初，包括IBM、BEA、Oracle在內(nèi)的一些巨頭公司看到了Java作為一門(mén)杰出的Web編程語(yǔ)言可能給他們帶來(lái)的巨大商機(jī)。那么如何通過(guò)一門(mén)編程語(yǔ)言來(lái)賺錢(qián)呢？答案就是使用這門(mén)語(yǔ)言構(gòu)建復(fù)雜無(wú)比的服務(wù)器，讓那些大公司支付一大筆費(fèi)用來(lái)購(gòu)買(mǎi)這些服務(wù)器。于是緊接著就出現(xiàn)了Java EE規(guī)范、JSR規(guī)范，以及WebLogic、WebSphere等服務(wù)器中間件。

在這些服務(wù)器上面部署了大型的程序包，它們運(yùn)行緩慢，消耗大量的內(nèi)存?；谶@些容器的開(kāi)發(fā)和調(diào)試對(duì)開(kāi)發(fā)人員來(lái)說(shuō)簡(jiǎn)直就是噩夢(mèng)，作為對(duì)他們的補(bǔ)償，他們從雇主那里獲得了豐厚的報(bào)酬。

因?yàn)楹馁Y巨大，幾乎找不到一家公司可以使用合理的費(fèi)用長(zhǎng)時(shí)間地支持Java。如果你要用Java構(gòu)建一個(gè)網(wǎng)站，你必須支付一大筆費(fèi)用來(lái)運(yùn)行這些服務(wù)器，哪怕你只用到了Servlet容器。在很長(zhǎng)一段時(shí)間里，Java被用在企業(yè)和公司里，因?yàn)橹挥羞@些大公司能夠負(fù)擔(dān)得起數(shù)百萬(wàn)美元的服務(wù)器費(fèi)用，并為那些企業(yè)級(jí)開(kāi)發(fā)人員支付高額的薪水。

Rod Johnson在2003年發(fā)布了Spring框架，Spring提供了IoC和對(duì)POJO的支持，幫助開(kāi)發(fā)人員逃脫EJB魔掌。開(kāi)發(fā)效率因此得到大幅的提升，大量開(kāi)發(fā)人員轉(zhuǎn)向Spring，把EJB丟在一邊。應(yīng)用服務(wù)器開(kāi)發(fā)商看到了這一點(diǎn)，他們?cè)贘ava EE 5里提供了一些可以減輕開(kāi)發(fā)人員負(fù)擔(dān)的特性?？上У氖牵琒pring被一路追捧，人們幾乎把它跟Java EE容器混為一談，它仍然運(yùn)行在Java EE的Servlet容器里，這些容器沿用的是十年前的設(shè)計(jì)，并沒(méi)有考慮到多核CPU和NIO。

在這期間，PHP奮起直追。PHP使用更少的內(nèi)存和資源，得到很多公司的支持。一些CMS平臺(tái)，比如WordPress、Drupal等都是基于PHP構(gòu)建的，這些平臺(tái)吸引了大批PHP開(kāi)發(fā)人員。不過(guò)，雖然PHP仍然是現(xiàn)今最流行的編程語(yǔ)言，但它也有自己的短板。它運(yùn)行速度不是很快，而且難以橫向擴(kuò)展。

2009年，Ryan Dahl啟動(dòng)了Node.js項(xiàng)目，它支持異步非阻塞的、基于事件驅(qū)動(dòng)的I/O。如果服務(wù)器的線程使用得當(dāng)，Node.js可以極大地提升響應(yīng)速度，單個(gè)服務(wù)器的吞吐量可以媲美一個(gè)Java EE服務(wù)器集群。Node.js是一個(gè)很好的作品，但它也有自己的局限性。Node.js難以擴(kuò)展，也難以與遺留的系統(tǒng)集成。

2014年，Undertow出現(xiàn)了，它是一個(gè)基于Java的非阻塞Web服務(wù)器。從techempower.com的測(cè)試結(jié)果來(lái)看，在一個(gè)價(jià)值8000美金的戴爾服務(wù)器上，它可以每秒鐘處理幾百萬(wàn)個(gè)請(qǐng)求，而谷歌需要使用一個(gè)集群才能處理一百萬(wàn)個(gè)同樣的請(qǐng)求。它是輕量級(jí)的，它的核心部分只需要1M內(nèi)存，它還包含了一個(gè)內(nèi)嵌的服務(wù)器，這個(gè)服務(wù)器使用不到4M的堆內(nèi)存。

基于Undertow Core構(gòu)建的Light Java Framework是一個(gè)微服務(wù)容器，它支持設(shè)計(jì)驅(qū)動(dòng)及生成代碼，并支持運(yùn)行時(shí)安全和運(yùn)行時(shí)驗(yàn)證。

Java EE廠商

多年前，Java EE廠商，比如Oracle和IBM，他們花費(fèi)數(shù)億美元開(kāi)發(fā)應(yīng)用服務(wù)器（WebLogic和WebSphere），這些服務(wù)器以數(shù)百萬(wàn)的價(jià)格賣(mài)給了大型組織。但現(xiàn)在這些服務(wù)器賣(mài)不動(dòng)了，因?yàn)镴Boss迅速搶占了市場(chǎng)份額，Oracle對(duì)Java EE的支持正在走下坡路。

隨著微服務(wù)越來(lái)越多地受到關(guān)注，這些應(yīng)用服務(wù)器很難有好的銷(xiāo)量，因?yàn)檫@些服務(wù)器更適合用來(lái)部署單體應(yīng)用。有一個(gè)包含了數(shù)百個(gè)EJB的應(yīng)用，為了在WebLogic上測(cè)試一行代碼改動(dòng)，居然用了45分鐘時(shí)間。

Java EE客戶(hù)

從客戶(hù)角度來(lái)看，耗費(fèi)巨資購(gòu)買(mǎi)這些服務(wù)器是不值得的，因?yàn)镴ava EE所承若的未必都是真的。一個(gè)為WebSphere開(kāi)發(fā)的應(yīng)用無(wú)法部署在WebLogic上，所以你需要花更多的錢(qián)去升級(jí)服務(wù)器，因?yàn)閺S商可能不再支持舊版的服務(wù)器，而這樣的更新會(huì)花費(fèi)你數(shù)百萬(wàn)美元。

于是一些聰明人不禁要問(wèn)，為什么我們要把應(yīng)用部署在這些龐然大物上？為什么我們要把應(yīng)用打包成一個(gè)ear包或war包，而不是jar包？為什么我們不能把大型的應(yīng)用拆分成更小的塊，讓它們可以獨(dú)立部署和擴(kuò)展？

微服務(wù)

微服務(wù)是這些問(wèn)題的解藥。Wikipedia把微服務(wù)定義為“……一種軟件架構(gòu)風(fēng)格，復(fù)雜的應(yīng)用由一些獨(dú)立的進(jìn)程組成，這些進(jìn)程使用與語(yǔ)言無(wú)關(guān)的API進(jìn)行交互。這些進(jìn)程服務(wù)規(guī)模很小，高度離散，聚焦在一個(gè)很小的任務(wù)上，使用模塊化方式來(lái)構(gòu)建系統(tǒng)”。

微服務(wù)架構(gòu)讓構(gòu)建應(yīng)用變得更加容易，而且應(yīng)用被拆分成單獨(dú)的服務(wù)，這些服務(wù)可以被任意組合。每個(gè)服務(wù)可以被獨(dú)立部署，也可以被組合成一個(gè)應(yīng)用。這些服務(wù)還可能會(huì)被其它應(yīng)用依賴(lài)。它加快了服務(wù)的開(kāi)發(fā)速度，因?yàn)橹灰x好接口，服務(wù)可以并行開(kāi)發(fā)。

微服務(wù)具備彈性和伸縮性。微服務(wù)不只依賴(lài)單個(gè)服務(wù)器和部署，它們可以被發(fā)布到多個(gè)機(jī)器上，或者多個(gè)數(shù)據(jù)中心及其它任何可用的區(qū)域。如果一個(gè)服務(wù)失效，可以啟動(dòng)另外一個(gè)。因?yàn)檎麄€(gè)應(yīng)用被分解成了微服務(wù)（小型服務(wù)），可以很容易地對(duì)其中某些熱門(mén)的服務(wù)進(jìn)行橫向擴(kuò)展。

如果你曾經(jīng)使用過(guò)COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就會(huì)知道服務(wù)和組件并不是什么新生事物。企業(yè)在使用組件方面存在的一個(gè)最大問(wèn)題是他們依賴(lài)大型的硬件服務(wù)器，并在同一個(gè)服務(wù)器上運(yùn)行很多應(yīng)用。我們有EJB、WAR包和EAR包，以及各種組件包，因?yàn)榉?wù)器資源太過(guò)昂貴，要盡可能地物盡其用。不過(guò)從最近幾年的發(fā)展情況來(lái)看，之前的方式有些落伍。操作系統(tǒng)服務(wù)器一直在變化，虛擬資源可以被當(dāng)成組件發(fā)布，比如EC2、OpenStack、Vagrant和Docker。世界變了。微服務(wù)架構(gòu)看到了這種趨勢(shì)，硬件、云技術(shù)、多核CPU和虛擬技術(shù)也在發(fā)展，所以我們要改變以前的開(kāi)發(fā)方式。

在開(kāi)始新項(xiàng)目的時(shí)候不要再使用EAR包或WAR包了?，F(xiàn)在我們可以在Docker里運(yùn)行JVM，Docker只不過(guò)是一個(gè)進(jìn)程，但它可以表現(xiàn)得像一個(gè)操作系統(tǒng)一樣。Docker運(yùn)行在云端的操作系統(tǒng)上，而云端的操作系統(tǒng)運(yùn)行在虛擬機(jī)里，虛擬機(jī)運(yùn)行在Linux服務(wù)器上。這些服務(wù)器不是歸誰(shuí)所有，而是被很多互不相識(shí)的人共享。如果出現(xiàn)流量高峰怎么辦？很簡(jiǎn)單，使用更多的服務(wù)器實(shí)例。這就是為什么要把Java微服務(wù)運(yùn)行在一個(gè)單獨(dú)的進(jìn)程里，而不是Java EE容器或servlet容器。

微服務(wù)一般會(huì)提供基于HTTP/JSON的API端點(diǎn)。這樣可以很容易地與其它服務(wù)（開(kāi)源或閉源的）集成，只要這些服務(wù)提供了HTTP/JSON接口。服務(wù)可以通過(guò)更有意義的方式被消費(fèi)、被組合。EC2、S3及其它來(lái)自Amazon（或其它公司）的服務(wù)就是最好的例子?；A(chǔ)設(shè)施會(huì)成為應(yīng)用程序的一部分，而且它們是可編程的。

使用微服務(wù)架構(gòu)的應(yīng)用程序應(yīng)該是模塊化、可編程和可組合的。微服務(wù)之間可以相互替換。應(yīng)用程序的局部可以被重寫(xiě)或改進(jìn)，而不會(huì)影響到整個(gè)應(yīng)用。如果所有的組件都提供了可編程的API，那么微服務(wù)之間的交互就會(huì)變得更簡(jiǎn)單（永遠(yuǎn)不要相信那些不能通過(guò)curl訪問(wèn)的微服務(wù)）。

隨著微服務(wù)逐漸流行起來(lái)，很多廠商開(kāi)始嘗試把他們的Java EE Web服務(wù)轉(zhuǎn)成微服務(wù)，這樣他們就可以繼續(xù)賣(mài)他們的過(guò)時(shí)產(chǎn)品，API Gateway就是這些廠商中的一個(gè)。

Jason Bloomberg是Intellyx的主席，他在一篇文章里指出了傳統(tǒng)Web服務(wù)和微服務(wù)的區(qū)別，并對(duì)把傳統(tǒng)Web服務(wù)轉(zhuǎn)成微服務(wù)的趨勢(shì)提出了質(zhì)疑。

微服務(wù)不是企業(yè)服務(wù)總線里的Web服務(wù)，也不是傳統(tǒng)的面向服務(wù)架構(gòu)，盡管它沿襲了SOA的一些基本概念。從根本上來(lái)說(shuō)，微服務(wù)跟SOA是不一樣的，因?yàn)檎麄€(gè)環(huán)境已經(jīng)發(fā)生了徹底的轉(zhuǎn)變。

微服務(wù)架構(gòu)的環(huán)境是沒(méi)有邊界的：端到端，基于云的應(yīng)用程序運(yùn)行在完全虛擬和容器化的基礎(chǔ)設(shè)施上。容器把應(yīng)用程序和服務(wù)組件化，DevOps為IT基礎(chǔ)設(shè)施提供框架，幫助自動(dòng)化開(kāi)發(fā)、部署和管理環(huán)境。

雖然容器對(duì)微服務(wù)來(lái)說(shuō)不是必需的，不過(guò)微服務(wù)可以很容易地運(yùn)行在容器里。況且，把非微服務(wù)的代碼部署在容器里不是一個(gè)明智的選擇。

Docker和其它容器技術(shù)在某種程度上已經(jīng)被視為微服務(wù)的最好伴侶。容器是運(yùn)行微服務(wù)的最小資源子集。Docker簡(jiǎn)化了微服務(wù)的開(kāi)發(fā)，讓集成測(cè)試變得更簡(jiǎn)單。

容器有助于微服務(wù)開(kāi)發(fā)，但不是必需的。Docker也可以被用來(lái)部署單體應(yīng)用。微服務(wù)與容器可以很好地相融并進(jìn)，不過(guò)微服務(wù)包含的東西遠(yuǎn)比容器多！

結(jié)論

應(yīng)用開(kāi)發(fā)的風(fēng)格這幾年一直在變化，而微服務(wù)變得越來(lái)越流行。大公司把大型應(yīng)用拆分成可以單獨(dú)部署的小型應(yīng)用，這些小型應(yīng)用被部署在云端的容器里。開(kāi)源微服務(wù)框架Light Java為這些運(yùn)行在容器里的微服務(wù)提供了很多特性，它支持設(shè)計(jì)驅(qū)動(dòng)，開(kāi)發(fā)者只需要把注意力專(zhuān)注在業(yè)務(wù)邏輯上，剩下的事情可以由框架和DevOps流程來(lái)處理。