微服務(wù)優(yōu)勢(shì)_微服務(wù)架構(gòu)的好處與不足

微服務(wù)定義

微服務(wù)是用一組小服務(wù)的方式來(lái)構(gòu)建一個(gè)應(yīng)用，服務(wù)獨(dú)立運(yùn)行在不同的進(jìn)程中，服務(wù)之間通過(guò)輕量的通訊機(jī)制（如RESTful接口）來(lái)交互，并且服務(wù)可以通過(guò)自動(dòng)化部署方式獨(dú)立部署。正因?yàn)槲⒎?wù)架構(gòu)中，服務(wù)之間是相互獨(dú)立的，所以不同的服務(wù)可以使用不同的語(yǔ)言來(lái)開(kāi)發(fā)，或者根據(jù)業(yè)務(wù)的需求使用不同類型的數(shù)據(jù)庫(kù)。

微服務(wù)優(yōu)勢(shì)

服務(wù)簡(jiǎn)單，只關(guān)注一個(gè)業(yè)務(wù)功能

在James看來(lái)，傳統(tǒng)的整體風(fēng)格的架構(gòu)在構(gòu)建部署和擴(kuò)展伸縮方面有很大的局限性，其服務(wù)端應(yīng)用就像是一塊鐵板，笨重且不可拆分，系統(tǒng)中任何程序的改變都需要整個(gè)應(yīng)用重新構(gòu)建和部署新版本。在進(jìn)行水平擴(kuò)展時(shí)也只能整個(gè)系統(tǒng)擴(kuò)展，而不能針對(duì)某一個(gè)功能模塊進(jìn)行擴(kuò)展。

而微服務(wù)架構(gòu)將系統(tǒng)以組件化的方式分解為多個(gè)服務(wù)，服務(wù)之間相對(duì)獨(dú)立且松耦合，單一功能的改變只需要重新構(gòu)建部署相應(yīng)的服務(wù)即可。

每個(gè)微服務(wù)可由不同團(tuán)隊(duì)開(kāi)發(fā)

傳統(tǒng)的開(kāi)發(fā)模式在分工時(shí)往往以技術(shù)為單位，比如UI團(tuán)隊(duì)、服務(wù)端團(tuán)隊(duì)和數(shù)據(jù)庫(kù)團(tuán)隊(duì)，這樣的分工可能會(huì)導(dǎo)致任何功能上的改變都需要跨團(tuán)隊(duì)溝通和協(xié)調(diào)。而微服務(wù)則倡導(dǎo)圍繞服務(wù)來(lái)分工，不同的服務(wù)可以采用不同的技術(shù)來(lái)實(shí)現(xiàn)，一個(gè)團(tuán)隊(duì)中應(yīng)該包含開(kāi)發(fā)所需的所有技能，比如用戶體驗(yàn)、數(shù)據(jù)庫(kù)、項(xiàng)目管理。

微服務(wù)是松散耦合的

微服務(wù)架構(gòu)拋棄了ESB復(fù)雜的業(yè)務(wù)規(guī)則編排、消息路由等功能，微服務(wù)架構(gòu)中服務(wù)是高內(nèi)聚的，每個(gè)服務(wù)都會(huì)處理相應(yīng)的業(yè)務(wù)，所有的業(yè)務(wù)邏輯應(yīng)該盡量在服務(wù)內(nèi)部處理，且服務(wù)間的通信盡可能的輕量化，比如使用Restful的方式。

可用不同的編程語(yǔ)言與工具開(kāi)發(fā)

傳統(tǒng)的軟件開(kāi)發(fā)中經(jīng)常會(huì)使用同一個(gè)技術(shù)平臺(tái)來(lái)解決所有的問(wèn)題，而經(jīng)驗(yàn)表明使用合適的工具做合適的事情會(huì)讓開(kāi)發(fā)變得事半功倍。微服務(wù)架構(gòu)天生就具有這樣的特性，我們可以使用Node.js來(lái)開(kāi)發(fā)一個(gè)簡(jiǎn)單的報(bào)表頁(yè)面，使用C++來(lái)編寫(xiě)一個(gè)實(shí)時(shí)聊天組件。

微服務(wù)架構(gòu)的引入為多樣化持久保存數(shù)據(jù)提供可能，持久層可以使用傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)和NoSQL。不同于傳統(tǒng)的應(yīng)用，微服務(wù)架構(gòu)中，我們可以為每個(gè)服務(wù)選擇一個(gè)新的適合業(yè)務(wù)邏輯的數(shù)據(jù)庫(kù)系統(tǒng)，比如MongoDB、PostgreSQL。這樣做的好處是顯而易見(jiàn)的，首先我們可以根據(jù)業(yè)務(wù)類型（讀多還是寫(xiě)多等）來(lái)決定使用哪種類型的數(shù)據(jù)庫(kù)，其次這樣可以減小單個(gè)數(shù)據(jù)庫(kù)的負(fù)載。

James的文章在社區(qū)引起了廣泛的討論，Contino公司的CTO Benjamin Wootton撰文表示微服務(wù)并沒(méi)有想象中的那么好，并建議開(kāi)發(fā)者在選用此架構(gòu)時(shí)一定要慎重。Benjamin認(rèn)為微服務(wù)架構(gòu)時(shí)可能會(huì)面臨下面一些挑戰(zhàn)：

運(yùn)維開(kāi)銷

更多的服務(wù)也就意味著更多的運(yùn)維，產(chǎn)品團(tuán)隊(duì)需要保證所有的相關(guān)服務(wù)都有完善的監(jiān)控等基礎(chǔ)設(shè)施，傳統(tǒng)的架構(gòu)開(kāi)發(fā)者只需要保證一個(gè)應(yīng)用正常運(yùn)行，而現(xiàn)在卻需要保證幾十甚至上百道工序高效運(yùn)轉(zhuǎn)，這是一個(gè)艱巨的任務(wù)。

DevOps要求

使用微服務(wù)架構(gòu)后，開(kāi)發(fā)團(tuán)隊(duì)需要保證一個(gè)Tomcat集群可用，保證一個(gè)數(shù)據(jù)庫(kù)可用，這就意味著團(tuán)隊(duì)需要高品質(zhì)的DevOps和自動(dòng)化技術(shù)。而現(xiàn)在，這樣的全棧式人才很少。

隱式接口

服務(wù)和服務(wù)之間通過(guò)接口來(lái)“聯(lián)系”，當(dāng)某一個(gè)服務(wù)更改接口格式時(shí)，可能涉及到此接口的所有服務(wù)都需要做調(diào)整。

重復(fù)勞動(dòng)

在很多服務(wù)中可能都會(huì)使用到同一個(gè)功能，而這一功能點(diǎn)沒(méi)有足夠大到提供一個(gè)服務(wù)的程度，這個(gè)時(shí)候可能不同的服務(wù)團(tuán)隊(duì)都會(huì)單獨(dú)開(kāi)發(fā)這一功能，重復(fù)的業(yè)務(wù)邏輯，這違背了良好的軟件工程中的很多原則。

分布式系統(tǒng)的復(fù)雜性

微服務(wù)通過(guò)REST API或消息來(lái)將不同的服務(wù)聯(lián)系起來(lái)，這在之前可能只是一個(gè)簡(jiǎn)單的遠(yuǎn)程過(guò)程調(diào)用。分布式系統(tǒng)也就意味著開(kāi)發(fā)者需要考慮網(wǎng)絡(luò)延遲、容錯(cuò)、消息序列化、不可靠的網(wǎng)絡(luò)、異步、版本控制、負(fù)載等，而面對(duì)如此多的微服務(wù)都需要分布式時(shí)，整個(gè)產(chǎn)品需要有一整套完整的機(jī)制來(lái)保證各個(gè)服務(wù)可以正常運(yùn)轉(zhuǎn)。

事務(wù)、異步、測(cè)試面臨挑戰(zhàn)

跨進(jìn)程之間的事務(wù)、大量的異步處理、多個(gè)微服務(wù)之間的整體測(cè)試都需要有一整套的解決方案，而現(xiàn)在看起來(lái)，這些技術(shù)并沒(méi)有成熟。

微處理架構(gòu)——處理復(fù)雜事物

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

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

比如，一個(gè)前面描述系統(tǒng)可能的分解如下：

?

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

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

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

?

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

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

?

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

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

?

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

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

微服務(wù)架構(gòu)的好處

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

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

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

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

微服務(wù)架構(gòu)的不足

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

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

另外一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來(lái)自于分區(qū)的數(shù)據(jù)庫(kù)架構(gòu)。商業(yè)交易中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍。這種交易對(duì)于單體式應(yīng)用來(lái)說(shuō)很容易，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫(kù)。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫(kù)。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫(kù)和消息傳遞中間件并不支持這一需求。最終你不得不使用一個(gè)最終一致性的方法，從而對(duì)開(kāi)發(fā)者提出了更高的要求和挑戰(zhàn)。

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

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

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

一種自動(dòng)化方法是使用PaaS服務(wù)，例如Cloud Foundry。PaaS給開(kāi)發(fā)者提供一個(gè)部署和管理微服務(wù)的簡(jiǎn)單方法，它把所有這些問(wèn)題都打包內(nèi)置解決了。同時(shí)，配置PaaS的系統(tǒng)和網(wǎng)絡(luò)專家可以采用最佳實(shí)踐和策略來(lái)簡(jiǎn)化這些問(wèn)題。另外一個(gè)自動(dòng)部署微服務(wù)應(yīng)用的方法是開(kāi)發(fā)對(duì)于你來(lái)說(shuō)最基礎(chǔ)的PaaS系統(tǒng)。一個(gè)典型的開(kāi)始點(diǎn)是使用一個(gè)集群化方案，比如配合Docker使用Mesos或者Kubernetes。后面的系列我們會(huì)看看如何基于軟件部署方法例如NGINX，可以方便的在微服務(wù)層面提供緩存、權(quán)限控制、API統(tǒng)計(jì)和監(jiān)控。

總結(jié)

總而言之，微服務(wù)架構(gòu)有很多吸引人的地方，不過(guò)在擁抱微服務(wù)之前要認(rèn)清它所帶來(lái)的挑戰(zhàn)。而每一種架構(gòu)都有其優(yōu)缺點(diǎn)，我們需要根據(jù)項(xiàng)目業(yè)務(wù)和團(tuán)隊(duì)情況來(lái)選擇合適的架構(gòu)。構(gòu)建復(fù)雜的應(yīng)用真的是非常困難。單體式的架構(gòu)更適合輕量級(jí)的簡(jiǎn)單應(yīng)用。如果你用它來(lái)開(kāi)發(fā)復(fù)雜應(yīng)用，那真的會(huì)很糟糕。微服務(wù)架構(gòu)模式可以用來(lái)構(gòu)建復(fù)雜應(yīng)用，當(dāng)然，這種架構(gòu)模型也有自己的缺點(diǎn)和挑戰(zhàn)。