微服務(wù)最近非常流行，各大互聯(lián)網(wǎng)公司紛紛采用微服務(wù)架構(gòu)體系，微服務(wù)架構(gòu)模式正在為敏捷部署以及復(fù)雜企業(yè)應(yīng)用實施提供巨大的幫助。

本文受中國Java開發(fā)者大會組委會邀約編撰而成，讓大家10分鐘了解微服務(wù)。

1?什么是微服務(wù)？

微服務(wù)架構(gòu)我們沒有一個明確的定義，但簡單來說微服務(wù)架構(gòu)是：?采用一組服務(wù)的方式來構(gòu)建一個應(yīng)用，服務(wù)獨立部署在不同的進程中，不同服務(wù)通過一些輕量級交互機制來通信，例如?RPC、HTTP?等，服務(wù)可獨立擴展伸縮，每個服務(wù)定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實現(xiàn)，由獨立的團隊來維護。

2?微服務(wù)架構(gòu)有哪些特征（Characteristics）？

1.?通過服務(wù)實現(xiàn)組件化

傳統(tǒng)實現(xiàn)組件的方式是通過庫（library），傳統(tǒng)組件是和應(yīng)用一起運行在進程中，組件的局部變化意味著整個應(yīng)用的重新部署。?通過服務(wù)來實現(xiàn)組件，意味著將應(yīng)用拆散為一系列的服務(wù)運行在不同的進程中，那么單一服務(wù)的局部變化只需重新部署對應(yīng)的服務(wù)進程。?另外將服務(wù)作為組件可以更明確的定義出組件的邊界。

2.?按業(yè)務(wù)能力來劃分服務(wù)與組織團隊

康威定律（Conway's?law）指出：

organizations?which?design?systems?...?are?constrained?to?produce?designs?which?are?copies?of?the?communication?structures?of?these?organizations.

任何設(shè)計系統(tǒng)的組織，最終產(chǎn)生的設(shè)計等同于組織之內(nèi)、之間的溝通結(jié)構(gòu)。

傳統(tǒng)開發(fā)方式中，我們將工程師按技能專長分層為前端層、中間層、數(shù)據(jù)層，前端對應(yīng)的角色為UI、頁面構(gòu)建師等，中間層對應(yīng)的角色為服務(wù)端業(yè)務(wù)開發(fā)工程師，數(shù)據(jù)層對應(yīng)著DBA等角色。?事實上傳統(tǒng)應(yīng)用設(shè)計架構(gòu)的分層結(jié)構(gòu)正反應(yīng)了不同角色的溝通結(jié)構(gòu)。?而微服務(wù)架構(gòu)的開發(fā)模式不同于傳統(tǒng)方式，它將應(yīng)用按業(yè)務(wù)能力來劃分為不同的服務(wù)，每個服務(wù)都要求在對應(yīng)業(yè)務(wù)領(lǐng)域的全棧（從前端到后端）軟件實現(xiàn)，從界面到數(shù)據(jù)存儲到外部溝通協(xié)作等等。?因此團隊的組織是跨功能的，包含實現(xiàn)業(yè)務(wù)所需的全面的技能。?近年興起的全棧工程師正是因為架構(gòu)和開發(fā)模式的轉(zhuǎn)變而出現(xiàn)，當(dāng)然具備全棧的工程師其實很少，但將不同領(lǐng)域的工程師組織為一個全棧的團隊就容易的多。

3.?服務(wù)即產(chǎn)品

傳統(tǒng)的應(yīng)用開發(fā)都是基于項目模式的，開發(fā)團隊根據(jù)一堆功能列表開發(fā)出一個軟件應(yīng)用并交付給客戶后，該軟件應(yīng)用就進入維護模式，由另一個維護團隊負(fù)責(zé)，開發(fā)團隊的職責(zé)結(jié)束。?而微服務(wù)架構(gòu)的倡導(dǎo)者提議避免采用這種項目模式，更傾向于讓開發(fā)團隊負(fù)責(zé)整個產(chǎn)品的全部生命周期。Amazon?對此提出了一個觀點：

You?buidl?it,?you?run?it.

開發(fā)團隊對軟件在生產(chǎn)環(huán)境的運行負(fù)全部責(zé)任，讓服務(wù)的開發(fā)者與服務(wù)的使用者（客戶）形成每天的交流反饋，來自直接客戶端的反饋有助于開發(fā)者提升服務(wù)的質(zhì)量。

4.?智能終端與啞管道

微服務(wù)架構(gòu)拋棄了?ESB?過度復(fù)雜的業(yè)務(wù)規(guī)則編排、消息路由等。?服務(wù)作為智能終端，所有的業(yè)務(wù)智能邏輯在服務(wù)內(nèi)部處理，而服務(wù)間的通信盡可能的輕量化，不添加任何額外的業(yè)務(wù)規(guī)則。

5.?去中心統(tǒng)一化

傳統(tǒng)應(yīng)用中傾向采用統(tǒng)一的技術(shù)平臺或產(chǎn)品來解決所有問題。?不是每個問題都是釘子，也不是每個解決方案都是一個錘子。?問題有其具體性，解決方案也應(yīng)有其針對性。?用最適合的技術(shù)方案去解決具體的問題，在大一統(tǒng)的傳統(tǒng)應(yīng)用中其實很難做到，而微服務(wù)的架構(gòu)意味著，你可以針對不同的業(yè)務(wù)服務(wù)特征選擇不同的技術(shù)平臺或產(chǎn)品，有針對性的解決具體的業(yè)務(wù)問題。

6.?基礎(chǔ)設(shè)施自動化

單一進程的傳統(tǒng)應(yīng)用被拆分為一系列的多進程服務(wù)后，意味著開發(fā)、調(diào)試、測試、集成、監(jiān)控和發(fā)布的復(fù)雜度都會相應(yīng)增大。?必須要有合適的自動化基礎(chǔ)設(shè)施來支持微服務(wù)架構(gòu)模式，否則開發(fā)、運維成本將大大增加。

7.?Design?for?failure

正因為將服務(wù)獨立在不同的進程中后，引入了額外的失敗因素。?任何時刻對服務(wù)的調(diào)用都可能因為服務(wù)方不可用導(dǎo)致失敗，這就要求服務(wù)的消費方需要優(yōu)雅的處理此類錯誤。?這其實是相對傳統(tǒng)應(yīng)用開發(fā)方式的一個缺點，不過隨著一些開源服務(wù)化框架的出現(xiàn)，對業(yè)務(wù)開發(fā)人員而言適當(dāng)?shù)钠帘瘟祟愃频腻e誤處理，不過開發(fā)人員依然需要知道對服務(wù)的調(diào)用是完全不同于進程內(nèi)的方法或函數(shù)調(diào)用的。

8.?進化設(shè)計

一旦采用了微服務(wù)架構(gòu)模式，那么在服務(wù)需要變更時我們要特別小心，服務(wù)提供者的變更可能引發(fā)服務(wù)消費者的兼容性破壞，時刻謹(jǐn)記保持服務(wù)契約（接口）的兼容性。?對于解耦服務(wù)消費方和服務(wù)提供方，伯斯塔爾法則（Postel's?law）特別適用：

Be?conservative?in?what?you?send,?be?liberal?in?what?you?accept.

發(fā)送時要保守，接收時要開放。

按照伯斯塔爾法則的思想來設(shè)計實現(xiàn)服務(wù)調(diào)用時，發(fā)送的數(shù)據(jù)要更保守，意味著最小化的傳送必要的信息，接收時更開放意味著要最大限度的容忍信息的兼容性。?多余的信息不認(rèn)識可以忽略，而不應(yīng)該拒絕或拋出錯誤。

3?為什么要使用微服務(wù)架構(gòu)？

開發(fā)單體式應(yīng)用

假設(shè)你正準(zhǔn)備開發(fā)一款與Uber和Hailo競爭的出租車調(diào)度軟件，經(jīng)過初步會議和需求分析，你可能會手動或者使用基于Rails、Spring?Boot、Play或者Maven的生成器開始這個新項目，它的六邊形架構(gòu)是模塊化的

應(yīng)用核心是業(yè)務(wù)邏輯，由定義服務(wù)、域?qū)ο蠛褪录哪K完成。圍繞著核心的是與外界打交道的適配器。適配器包括數(shù)據(jù)庫訪問組件、生產(chǎn)和處理消息的消息組件，以及提供API或者UI訪問支持的web模塊等。

盡管也是模塊化邏輯，但是最終它還是會打包并部署為單體式應(yīng)用。具體的格式依賴于應(yīng)用語言和框架。例如，許多Java應(yīng)用會被打包為WAR格式，部署在Tomcat或者Jetty上，而另外一些Java應(yīng)用會被打包成自包含的JAR格式，同樣，Rails和Node.js會被打包成層級目錄。

這種應(yīng)用開發(fā)風(fēng)格很常見，因為IDE和其它工具都擅長開發(fā)一個簡單應(yīng)用，這類應(yīng)用也很易于調(diào)試，只需要簡單運行此應(yīng)用，用Selenium鏈接UI就可以完成端到端測試。單體式應(yīng)用也易于部署，只需要把打包應(yīng)用拷貝到服務(wù)器端，通過在負(fù)載均衡器后端運行多個拷貝就可以輕松實現(xiàn)應(yīng)用擴展。在早期這類應(yīng)用運行的很好。

單體式應(yīng)用的不足

不幸的是，這種簡單方法卻有很大的局限性。一個簡單的應(yīng)用會隨著時間推移逐漸變大。在每次的sprint中，開發(fā)團隊都會面對新“故事”，然后開發(fā)許多新代碼。幾年后，這個小而簡單的應(yīng)用會變成了一個巨大的怪物。

一旦你的應(yīng)用變成一個又大又復(fù)雜的怪物，那開發(fā)團隊肯定很痛苦。敏捷開發(fā)和部署舉步維艱，其中最主要問題就是這個應(yīng)用太復(fù)雜，以至于任何單個開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，并且很耗時。另外，團隊士氣也會走下坡路。如果代碼難于理解，就不可能被正確的修改。最終會走向巨大的、不可理解的泥潭。

單體式應(yīng)用也會降低開發(fā)速度。應(yīng)用越大，啟動時間會越長。比如，最近的一個調(diào)查表明，有時候應(yīng)用的啟動時間居然超過了12分鐘。我還聽說某些應(yīng)用需要40分鐘啟動時間。如果開發(fā)者需要經(jīng)常重啟應(yīng)用，那么大部分時間就要在等待中渡過，生產(chǎn)效率受到極大影響。

另外，復(fù)雜而巨大的單體式應(yīng)用也不利于持續(xù)性開發(fā)。今天，SaaS應(yīng)用常態(tài)就是每天會改變很多次，而這對于單體式應(yīng)用模式非常困難。另外，這種變化帶來的影響并沒有很好的被理解，所以不得不做很多手工測試。那么接下來，持續(xù)部署也會很艱難。

單體式應(yīng)用在不同模塊發(fā)生資源沖突時，擴展將會非常困難。比如，一個模塊完成一個CPU敏感邏輯，應(yīng)該部署在AWS?EC2?Compute?Optimized?instances，而另外一個內(nèi)存數(shù)據(jù)庫模塊更合適于EC2?Memory-optimized?instances。然而，由于這些模塊部署在一起，因此不得不在硬件選擇上做一個妥協(xié)。

單體式應(yīng)用另外一個問題是可靠性。因為所有模塊都運行在一個進程中，任何一個模塊中的一個bug，比如內(nèi)存泄露，將會有可能弄垮整個進程。除此之外，因為所有應(yīng)用實例都是唯一的，這個bug將會影響到整個應(yīng)用的可靠性。

最后，單體式應(yīng)用使得采用新架構(gòu)和語言非常困難。比如，設(shè)想你有兩百萬行采用XYZ框架寫的代碼。如果想改成ABC框架，無論是時間還是成本都是非常昂貴的，即使ABC框架更好。因此，這是一個無法逾越的鴻溝。你不得不在最初選擇面前低頭。

那么如何應(yīng)對上述的問題呢？

解決方案：微處理架構(gòu)——處理復(fù)雜事務(wù)

許多公司，比如Amazon、eBay和NetFlix，通過采用微處理結(jié)構(gòu)模式解決了上述問題。其思路不是開發(fā)一個巨大的單體式的應(yīng)用，而是將應(yīng)用分解為小的、互相連接的微服務(wù)。

一個微服務(wù)一般完成某個特定的功能，比如下單管理、客戶管理等等。每一個微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器。一些微服務(wù)還會發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用。其它微服務(wù)完成一個Web?UI，運行時，每一個實例可能是一個云VM或者是Docker容器。

比如，一個系統(tǒng)可能分解，讓每一個應(yīng)用功能區(qū)都使用微服務(wù)完成，另外，Web應(yīng)用會被拆分成一系列簡單的Web應(yīng)用（比如一個對乘客，一個對出租車駕駛員）。這樣的拆分對于不同用戶、設(shè)備和特殊應(yīng)用場景部署都更容易。

每一個后臺服務(wù)開放一個REST?API，許多服務(wù)本身也采用了其它服務(wù)提供的API。比如，駕駛員管理使用了告知駕駛員一個潛在需求的通知服務(wù)。UI服務(wù)激活其它服務(wù)來更新Web頁面。所有服務(wù)都是采用異步的，基于消息的通訊。微服務(wù)內(nèi)部機制將會在后續(xù)系列中討論。

一些REST?API也對乘客和駕駛員采用的移動應(yīng)用開放。這些應(yīng)用并不直接訪問后臺服務(wù)，而是通過API?Gateway來傳遞中間消息。API?Gateway負(fù)責(zé)負(fù)載均衡、緩存、訪問控制、API?計費監(jiān)控等等任務(wù)，可以通過NGINX方便實現(xiàn)，后續(xù)文章將會介紹到API?Gateway。

微服務(wù)架構(gòu)模式在上圖中對應(yīng)于代表可擴展Scale?Cube的Y軸，這是一個在《The?Art?of?Scalability》書中描述過的三維擴展模型。另外兩個可擴展軸，X軸由負(fù)載均衡器后端運行的多個應(yīng)用副本組成，Z軸是將需求路由到相關(guān)服務(wù)。

應(yīng)用基本可以用以上三個維度來表示，Y軸代表將應(yīng)用分解為微服務(wù)。運行時，X軸代表運行多個隱藏在負(fù)載均衡器之后的實例，提供吞吐能力。一些應(yīng)用可能還是用Z軸將服務(wù)分區(qū)。下面的圖演示行程管理服務(wù)如何部署在運行于AWS?EC2上的Docker上。

運行時，行程管理服務(wù)由多個服務(wù)實例構(gòu)成。每一個服務(wù)實例都是一個Docker容器。為了保證高可用，這些容器一般都運行在多個云VM上。服務(wù)實例前是一層諸如NGINX的負(fù)載均衡器，他們負(fù)責(zé)在各個實例間分發(fā)請求。負(fù)載均衡器也同時處理其它請求，例如緩存、權(quán)限控制、API統(tǒng)計和監(jiān)控。

這種微服務(wù)架構(gòu)模式深刻影響了應(yīng)用和數(shù)據(jù)庫之間的關(guān)系，不像傳統(tǒng)多個服務(wù)共享一個數(shù)據(jù)庫，微服務(wù)架構(gòu)每個服務(wù)都有自己的數(shù)據(jù)庫。另外，這種思路也影響到了企業(yè)級數(shù)據(jù)模式。同時，這種模式意味著多份數(shù)據(jù)，但是，如果你想獲得微服務(wù)帶來的好處，每個服務(wù)獨有一個數(shù)據(jù)庫是必須的，因為這種架構(gòu)需要這種松耦合。

每種服務(wù)都有自己的數(shù)據(jù)庫，另外，每種服務(wù)可以用更適合自己的數(shù)據(jù)庫類型，也被稱作多語言一致性架構(gòu)。比如，駕駛員管理（發(fā)現(xiàn)哪個駕駛員更靠近乘客），必須使用支持地理信息查詢的數(shù)據(jù)庫。

表面上看來，微服務(wù)架構(gòu)模式有點像SOA，他們都由多個服務(wù)構(gòu)成。但是，可以從另外一個角度看此問題，微服務(wù)架構(gòu)模式是一個不包含Web服務(wù)（WS-）和ESB服務(wù)的SOA。微服務(wù)應(yīng)用樂于采用簡單輕量級協(xié)議，比如REST，而不是WS-，在微服務(wù)內(nèi)部避免使用ESB以及ESB類似功能。微服務(wù)架構(gòu)模式也拒絕使用canonical?schema等SOA概念。

4?微服務(wù)架構(gòu)跟SOA有什么不一樣？

SOA與微服務(wù)應(yīng)用了很多相同的原則，只是在組織中的應(yīng)用層次不同。SOA專注于對“大型服務(wù)”進行編排操作，但這些大型服務(wù)也可以通過對一系列微服務(wù)進行組合而實現(xiàn)。服務(wù)的大小并不是一種定義微服務(wù)的好方法。

表面上看來，微服務(wù)架構(gòu)模式有點像SOA，他們都由多個服務(wù)構(gòu)成。從另外一個角度看此，微服務(wù)架構(gòu)模式是一個不包含Web服務(wù)（WS-）和ESB服務(wù)的SOA。

SOA的提出是在企業(yè)計算領(lǐng)域，就是要將緊耦合的系統(tǒng)，劃分為面向業(yè)務(wù)的，粗粒度，松耦合，無狀態(tài)的服務(wù)。服務(wù)發(fā)布出來供其他服務(wù)調(diào)用，一組互相依賴的服務(wù)就構(gòu)成了SOA架構(gòu)下的系統(tǒng)。

基于這些基礎(chǔ)的服務(wù)，可以將業(yè)務(wù)過程用類似BPEL流程的方式編排起來，而BPEL反映的是業(yè)務(wù)處理的過程，這些過程對于業(yè)務(wù)人員更為直觀，調(diào)整也比hardcode的代碼更容易。當(dāng)然企業(yè)還需要對服務(wù)治理，比如服務(wù)注冊庫，監(jiān)控管理等。

我們知道企業(yè)計算領(lǐng)域，如果不是交易系統(tǒng)的話，并發(fā)量都不是很大的，所以大多數(shù)情況下，一臺服務(wù)器就容納將許許多多的服務(wù)，這些服務(wù)采用統(tǒng)一的基礎(chǔ)設(shè)施，可能都運行在一個應(yīng)用服務(wù)器的進程中。雖然說是面向服務(wù)了，但還是單一的系統(tǒng)。

而微服務(wù)架構(gòu)大體是從互聯(lián)網(wǎng)企業(yè)興起的，由于大規(guī)模用戶，對分布式系統(tǒng)的要求很高，如果像企業(yè)計算那樣的系統(tǒng)，伸縮就需要多個容納續(xù)續(xù)多多的服務(wù)的系統(tǒng)實例，前面通過負(fù)載均衡使得多個系統(tǒng)成為一個集群。

但這是很不方便的，互聯(lián)網(wǎng)企業(yè)迭代的周期很短，一周可能發(fā)布一個版本，甚至可能每天一個版本，而不同的子系統(tǒng)的發(fā)布周期是不一樣的。

而且，不同的子系統(tǒng)也不像原來企業(yè)計算那樣采用集中式的存儲，使用昂貴的Oracle存儲整個系統(tǒng)的數(shù)據(jù)，二是使用MongoDB，HBase，Cassandra等NOSQL數(shù)據(jù)庫和Redis，memcache等分布式緩存。

那么就傾向采用以子系統(tǒng)為分割，不同的子系統(tǒng)采用自己的架構(gòu)，那么各個服務(wù)運行自己的Web容器中，當(dāng)需要增加計算能力的時候，只需要增加這個子系統(tǒng)或服務(wù)的實例就好了，當(dāng)升級的時候，可以不影響別的子系統(tǒng)。這種組織方式大體上就被稱作微服務(wù)架構(gòu)。

微服務(wù)與SOA相比，更強調(diào)分布式系統(tǒng)的特性，比如橫向伸縮性，服務(wù)發(fā)現(xiàn)，負(fù)載均衡，故障轉(zhuǎn)移，高可用。互聯(lián)網(wǎng)開發(fā)對服務(wù)治理提出了更多的要求，比如多版本，比如灰度升級，比如服務(wù)降級，比如分布式跟蹤，這些都是在SOA實踐中重視不夠的。

5?微服務(wù)架構(gòu)的好處有哪些？

微服務(wù)架構(gòu)模式有很多好處。

首先，通過分解巨大單體式應(yīng)用為多個服務(wù)方法解決了復(fù)雜性問題。在功能不變的情況下，應(yīng)用被分解為多個可管理的分支或服務(wù)。每個服務(wù)都有一個用RPC-或者消息驅(qū)動API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實現(xiàn)的功能提供了模塊化的解決方案，由此，單個服務(wù)很容易開發(fā)、理解和維護。

第二，這種架構(gòu)使得每個服務(wù)都可以有專門開發(fā)團隊來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務(wù)。當(dāng)然，許多公司試圖避免混亂，只提供某些技術(shù)選擇。然后，這種自由意味著開發(fā)者不需要被迫使用某項目開始時采用的過時技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因為服務(wù)都是相對簡單，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。

第三，微服務(wù)架構(gòu)模式是每個微服務(wù)獨立的部署。開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響。這種改變可以加快部署速度。UI團隊可以采用AB測試，快速的部署變化。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

最后，微服務(wù)架構(gòu)模式使得每個服務(wù)獨立擴展。你可以根據(jù)每個服務(wù)的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務(wù)資源需求的硬件。比如，你可以在EC2?Compute?Optimized?instances上部署CPU敏感的服務(wù)，而在EC2?memory-optimized?instances上部署內(nèi)存數(shù)據(jù)庫。

6?微服務(wù)架構(gòu)的不足有哪些？

像任何其它科技一樣，微服務(wù)架構(gòu)也有不足。其中一個跟他的名字類似，『微服務(wù)』強調(diào)了服務(wù)大小，實際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100?LOC服務(wù)組。盡管小服務(wù)更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務(wù)的目的是有效的拆分應(yīng)用，實現(xiàn)敏捷開發(fā)和部署。

另外一個主要的不足是，微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當(dāng)然這并不是什么難事，但相對于單體式應(yīng)用中通過語言層級的方法或者進程調(diào)用，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些。

另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因為只有一個數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。比如，采用流行的Spring?Boot架構(gòu)，對一個單體式web應(yīng)用，測試它的REST?API，是很容易的事情。反過來，同樣的服務(wù)測試需要啟動和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性。

另外一個挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體式應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個應(yīng)用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。相對比，一個微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成。例如，根據(jù)Adrian?Cockcroft，Hailo有160個不同服務(wù)構(gòu)成，NetFlix有大約600個服務(wù)。每個服務(wù)都有多個實例。這就造成許多需要配置、部署、擴展和監(jiān)控的部分，除此之外，你還需要完成一個服務(wù)發(fā)現(xiàn)機制，以用來發(fā)現(xiàn)與它通訊服務(wù)的地址（包括服務(wù)器地址和端口）。傳統(tǒng)的解決問題辦法不能用于解決這么復(fù)雜的問題。接續(xù)而來，成功部署一個微服務(wù)應(yīng)用需要開發(fā)者有足夠的控制部署方法，并高度自動化。

一種自動化方法是使用PaaS服務(wù)，例如Cloud?Foundry。PaaS給開發(fā)者提供一個部署和管理微服務(wù)的簡單方法，它把所有這些問題都打包內(nèi)置解決了。同時，配置PaaS的系統(tǒng)和網(wǎng)絡(luò)專家可以采用最佳實踐和策略來簡化這些問題。另外一個自動部署微服務(wù)應(yīng)用的方法是開發(fā)對于你來說最基礎(chǔ)的PaaS系統(tǒng)。一個典型的開始點是使用一個集群化方案，比如配合Docker使用Mesos或者Kubernetes。

7?微服務(wù)架構(gòu)的開發(fā)團隊組織結(jié)構(gòu)是怎樣的？

“微”服務(wù)并不一定微。服務(wù)的具體規(guī)模可謂多種多樣。其中規(guī)模最大的成果源自Amazon公司旗下的“兩塊披薩”團隊（即整個團隊只需兩塊披薩即可填飽肚子），這意味著其總?cè)藬?shù)在十位左右。而規(guī)模較小的團隊則由六人組成，負(fù)責(zé)支持六項服務(wù)。

采取此類組織方式的企業(yè)實例，其各職能團隊共同負(fù)責(zé)構(gòu)建并運營每款產(chǎn)品，而每款產(chǎn)品則被拆分為一系列獨立的服務(wù)——且各服務(wù)間通過一套消息收發(fā)總線實現(xiàn)通信。

大型整體應(yīng)用程序亦可以始終圍繞業(yè)務(wù)功能實際模塊化，由大型團隊構(gòu)建的單一整體應(yīng)用程序根據(jù)自身業(yè)務(wù)線進行設(shè)計與劃分。然而在這類情況下，最大的問題在于整體應(yīng)用程序在組織當(dāng)中需要考慮太多背景信息。如果其整體范疇當(dāng)中包含太多模塊邊界，那么團隊中的單一成員將很難通過短期記憶對其進行管理。

這種模塊化業(yè)務(wù)線的維護工作還要求相關(guān)人員具備極高的專業(yè)技能水平。相比之下，服務(wù)組件能夠令拆分方式更為明確，從而大大簡化團隊邊界的設(shè)定與認(rèn)知。

8?為什么微服務(wù)是產(chǎn)品而非項目視角？

大部分應(yīng)用程序開發(fā)工作都會遵循項目模式：其目標(biāo)在于交付軟件方案中的特定部分，并擁有直觀的完成指標(biāo)。在軟件開發(fā)工作完成后，其會被傳遞至運維部門，這時負(fù)責(zé)構(gòu)建該軟件的團隊也將即刻解散。

微服務(wù)的支持者們則認(rèn)為這種模式并不可取——他們的主張是相關(guān)團隊?wèi)?yīng)該伴隨產(chǎn)品走過整個生命周期。這方面最典型的例子應(yīng)該是Amazon公司提出的“誰構(gòu)建，誰運行”原則，其中開發(fā)團隊需要對生產(chǎn)環(huán)境下的軟件成果承擔(dān)全部責(zé)任。這就要求開發(fā)人員在日常工作中全程關(guān)注其軟件的生產(chǎn)運行情況，同時掌握來自用戶的反饋意見，意味著他們需要在一定程度上為用戶提供技術(shù)支持服務(wù)。

產(chǎn)品的定位應(yīng)始終與業(yè)務(wù)功能相協(xié)調(diào)。相較于以往將軟件視為一整套已經(jīng)完成的功能集的心態(tài)，微服務(wù)架構(gòu)要求我們?nèi)膛c之保持關(guān)聯(lián)，并思考該軟件能夠如何協(xié)助用戶加強業(yè)務(wù)功能。

當(dāng)然，我們完全可以將同樣的思路引入整體應(yīng)用程序當(dāng)中，不過大量小型服務(wù)集合能夠顯著簡化服務(wù)開發(fā)人員與及用戶之間的個人聯(lián)系。

9?微服務(wù)跨越不同進程構(gòu)建通信結(jié)構(gòu)的方式是怎樣的？

在跨越不同進程構(gòu)建通信結(jié)構(gòu)時，我們發(fā)現(xiàn)很多產(chǎn)品及方案會直接把智能化機制塞進通信機制本體當(dāng)中。這方面的典型實例就是企業(yè)服務(wù)總線（簡稱ESB），ESB產(chǎn)品當(dāng)中通常包含復(fù)雜度極高的消息跌幅、編排、轉(zhuǎn)換以及業(yè)務(wù)規(guī)則應(yīng)用等機制。

微服務(wù)社區(qū)則傾向于使用另一種實現(xiàn)方式：智能化端點與傻瓜式流程。采用微服務(wù)架構(gòu)的應(yīng)用程序旨在盡可能實現(xiàn)解耦化與關(guān)聯(lián)性——它們各自擁有自己的域邏輯，而且在經(jīng)典Unix場景下的運作方式更像是過濾器機制——接收請求、應(yīng)用合適的邏輯并生成響應(yīng)。這一切都通過簡單的REST類協(xié)議實現(xiàn)編排，而非經(jīng)由WS-Choreography或者BPEL等復(fù)雜協(xié)議以及中央編排工具實現(xiàn)。

目前最常用的兩類協(xié)議為配合源API的HTTP請求-響應(yīng)與輕量化消息收發(fā)協(xié)議。對于前者，最簡練而準(zhǔn)確的說明是：

立足于Web，而非居于Web背后。

--?Ian?Robinson

微服務(wù)團隊采用的正是萬維網(wǎng)（在很大程度上亦包括Unix在內(nèi)）所遵循的原則與協(xié)議。一般來講，其使用的資源能夠為開發(fā)人員或者運維人員輕松實現(xiàn)緩存處理。

第二類作法則是立足于輕量化消息總線實現(xiàn)消息收發(fā)。這類基礎(chǔ)設(shè)施選項通常具備傻瓜式特性（這種傻瓜特性體現(xiàn)在實現(xiàn)操作上，即只需匹配消息路由機制，再無其它）——以RabbitMQ或者ZeroMQ為代表的簡單實現(xiàn)方案僅僅需要提供一套可靠的異步結(jié)構(gòu)，而服務(wù)的全部智能化元素仍然存在于端點當(dāng)中并負(fù)責(zé)消息的生成與消費。

在整體應(yīng)用程序當(dāng)中，各組件在進程內(nèi)執(zhí)行并通過方法調(diào)用或者函數(shù)調(diào)用的方式實現(xiàn)彼此通信。將整體應(yīng)用程序轉(zhuǎn)化為微服務(wù)形式的最大難題在于改變這種通信模式。由內(nèi)存內(nèi)方法調(diào)用指向PC通信機制的簡單轉(zhuǎn)換往往無法良好起效。相反，大家需要利用粗粒度方式取代原本的細(xì)粒度通信機制。

10?實施微服務(wù)架構(gòu)，應(yīng)該從哪些維度來考量？

建模

服務(wù)圍繞業(yè)務(wù)能力建模，服務(wù)應(yīng)該清晰地反應(yīng)業(yè)務(wù)能力。

協(xié)作

采用微服務(wù)架構(gòu)模式后，開發(fā)和運行的協(xié)作模式都會發(fā)生變化。

按微服務(wù)的組織方式，不同人或小團隊負(fù)責(zé)一個或一組微服務(wù)，服務(wù)之間可能存在相互調(diào)用關(guān)系，所以在服務(wù)之間也完全采用了像面向外部開放的契約化開發(fā)模式。

每一個服務(wù)都提供了一份契約文檔，發(fā)布到公開的內(nèi)部?wiki，方便服務(wù)干系人可自由獲取查看。契約文檔要求至少對服務(wù)的幾個基本方面作出說明，如下：

API，具體接口的?API?接入技術(shù)說明。

能力，服務(wù)能力的描述。

契約，提供這些能力所約定的一些限制條件說明。

版本，支持的最新和歷史的版本說明。

使用契約文檔來減少多余且可能反復(fù)重復(fù)的口頭溝通，降低協(xié)作成本。

采用微服務(wù)后一個業(yè)務(wù)功能的調(diào)用會涉及多個服務(wù)間的協(xié)同工作，由于服務(wù)間都是跨進城的調(diào)用通信，一個業(yè)務(wù)功能的完成涉及的服務(wù)調(diào)用鏈條可能較長，這就涉及到服務(wù)間需遵循一些規(guī)則來確保協(xié)作的可靠性和可用性。我們采用的原則是：長鏈條的內(nèi)部服務(wù)之間的調(diào)用異步化。若一個調(diào)用鏈條中的個別服務(wù)變慢或阻塞可能導(dǎo)致整個鏈條產(chǎn)生雪崩效應(yīng)，采用異步化來規(guī)避調(diào)用阻塞等待導(dǎo)致的雪崩情形。

測試

而微服務(wù)的測試，服務(wù)開發(fā)和運營人員專注于做好服務(wù)實現(xiàn)層面的單元測試和服務(wù)契約層面的接口測試。而面向業(yè)務(wù)功能的端到端測試，更多是依賴自動化腳本完成。而為了維護好這些自動化測試腳本，也需要保持服務(wù)接口和契約的兼容性和穩(wěn)定性，這些自動化測試腳本也屬于服務(wù)的消費方之一。

部署

借助于虛擬化或容器等隔離技術(shù)，每個服務(wù)感覺都是獨享資源，不必考慮額外的資源使用沖突。

監(jiān)控

大量松耦合的微服務(wù)通過相互協(xié)作來完成業(yè)務(wù)功能的流程處理，在這樣一個復(fù)雜的生產(chǎn)環(huán)境中，出現(xiàn)異常或錯誤是很難迅速定位的。這就需要一套成體系的監(jiān)控基礎(chǔ)設(shè)施，在我們的實踐中借助了公司統(tǒng)一的監(jiān)控基礎(chǔ)設(shè)施，對監(jiān)控進行了分層，頂層的監(jiān)控站在用戶視角，底層的監(jiān)控站在系統(tǒng)視角，形成更完善的反饋鏈路。

總結(jié)

構(gòu)建復(fù)雜的應(yīng)用真的是非常困難。單體式的架構(gòu)更適合輕量級的簡單應(yīng)用。如果你用它來開發(fā)復(fù)雜應(yīng)用，那真的會很糟糕。微服務(wù)架構(gòu)模式可以用來構(gòu)建復(fù)雜應(yīng)用，當(dāng)然，這種架構(gòu)模型也有自己的缺點和挑戰(zhàn)。

topgeek社區(qū)舉辦的中國Java開發(fā)者大會上有4個來自百度、阿里巴巴等多家互聯(lián)網(wǎng)大公司和專業(yè)咨詢公司Thoughtworks的講師分享的微服務(wù)話題，歡迎參加。

您可以點擊鏈接http://event.3188.la/309430881進入購票頁，或去大會官網(wǎng)http://javacon.topgeek.org/查看更多信息。

或掃描二維碼進入購票頁：