微服務定義

微服務是用一組小服務的方式來構建一個應用，服務獨立運行在不同的進程中，服務之間通過輕量的通訊機制（如RESTful接口）來交互，并且服務可以通過自動化部署方式獨立部署。正因為微服務架構中，服務之間是相互獨立的，所以不同的服務可以使用不同的語言來開發，或者根據業務的需求使用不同類型的數據庫。

微服務優勢

服務簡單，只關注一個業務功能

在James看來，傳統的整體風格的架構在構建部署和擴展伸縮方面有很大的局限性，其服務端應用就像是一塊鐵板，笨重且不可拆分，系統中任何程序的改變都需要整個應用重新構建和部署新版本。在進行水平擴展時也只能整個系統擴展，而不能針對某一個功能模塊進行擴展。

而微服務架構將系統以組件化的方式分解為多個服務，服務之間相對獨立且松耦合，單一功能的改變只需要重新構建部署相應的服務即可。

每個微服務可由不同團隊開發

傳統的開發模式在分工時往往以技術為單位，比如UI團隊、服務端團隊和數據庫團隊，這樣的分工可能會導致任何功能上的改變都需要跨團隊溝通和協調。而微服務則倡導圍繞服務來分工，不同的服務可以采用不同的技術來實現，一個團隊中應該包含開發所需的所有技能，比如用戶體驗、數據庫、項目管理。

微服務是松散耦合的

微服務架構拋棄了ESB復雜的業務規則編排、消息路由等功能，微服務架構中服務是高內聚的，每個服務都會處理相應的業務，所有的業務邏輯應該盡量在服務內部處理，且服務間的通信盡可能的輕量化，比如使用Restful的方式。

可用不同的編程語言與工具開發

傳統的軟件開發中經常會使用同一個技術平臺來解決所有的問題，而經驗表明使用合適的工具做合適的事情會讓開發變得事半功倍。微服務架構天生就具有這樣的特性，我們可以使用Node.js來開發一個簡單的報表頁面，使用C++來編寫一個實時聊天組件。

微服務架構的引入為多樣化持久保存數據提供可能，持久層可以使用傳統關系數據庫和NoSQL。不同于傳統的應用，微服務架構中，我們可以為每個服務選擇一個新的適合業務邏輯的數據庫系統，比如MongoDB、PostgreSQL。這樣做的好處是顯而易見的，首先我們可以根據業務類型（讀多還是寫多等）來決定使用哪種類型的數據庫，其次這樣可以減小單個數據庫的負載。

James的文章在社區引起了廣泛的討論，Contino公司的CTO Benjamin Wootton撰文表示微服務并沒有想象中的那么好，并建議開發者在選用此架構時一定要慎重。Benjamin認為微服務架構時可能會面臨下面一些挑戰：

運維開銷

更多的服務也就意味著更多的運維，產品團隊需要保證所有的相關服務都有完善的監控等基礎設施，傳統的架構開發者只需要保證一個應用正常運行，而現在卻需要保證幾十甚至上百道工序高效運轉，這是一個艱巨的任務。

DevOps要求

使用微服務架構后，開發團隊需要保證一個Tomcat集群可用，保證一個數據庫可用，這就意味著團隊需要高品質的DevOps和自動化技術。而現在，這樣的全棧式人才很少。

隱式接口

服務和服務之間通過接口來“聯系”，當某一個服務更改接口格式時，可能涉及到此接口的所有服務都需要做調整。

重復勞動

在很多服務中可能都會使用到同一個功能，而這一功能點沒有足夠大到提供一個服務的程度，這個時候可能不同的服務團隊都會單獨開發這一功能，重復的業務邏輯，這違背了良好的軟件工程中的很多原則。

分布式系統的復雜性

微服務通過REST API或消息來將不同的服務聯系起來，這在之前可能只是一個簡單的遠程過程調用。分布式系統也就意味著開發者需要考慮網絡延遲、容錯、消息序列化、不可靠的網絡、異步、版本控制、負載等，而面對如此多的微服務都需要分布式時，整個產品需要有一整套完整的機制來保證各個服務可以正常運轉。

事務、異步、測試面臨挑戰

跨進程之間的事務、大量的異步處理、多個微服務之間的整體測試都需要有一整套的解決方案，而現在看起來，這些技術并沒有成熟。

微處理架構——處理復雜事物

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

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

比如，一個前面描述系統可能的分解如下：

?

每一個應用功能區都使用微服務完成，另外，Web應用會被拆分成一系列簡單的Web應用（比如一個對乘客，一個對出租車駕駛員）。這樣的拆分對于不同用戶、設備和特殊應用場景部署都更容易。

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

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

?

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

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

?

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

這種微服務架構模式深刻影響了應用和數據庫之間的關系，不像傳統多個服務共享一個數據庫，微服務架構每個服務都有自己的數據庫。另外，這種思路也影響到了企業級數據模式。同時，這種模式意味著多份數據，但是，如果你想獲得微服務帶來的好處，每個服務獨有一個數據庫是必須的，因為這種架構需要這種松耦合。下面的圖演示示例應用數據庫架構。

?

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

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

微服務架構的好處

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

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

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

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

微服務架構的不足

Fred Brooks在30年前寫道，“there are no silver bullets”，像任何其它科技一樣，微服務架構也有不足。其中一個跟他的名字類似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一些的，10-100 LOC服務組。盡管小服務更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。

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

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

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

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

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

一種自動化方法是使用PaaS服務，例如Cloud Foundry。PaaS給開發者提供一個部署和管理微服務的簡單方法，它把所有這些問題都打包內置解決了。同時，配置PaaS的系統和網絡專家可以采用最佳實踐和策略來簡化這些問題。另外一個自動部署微服務應用的方法是開發對于你來說最基礎的PaaS系統。一個典型的開始點是使用一個集群化方案，比如配合Docker使用Mesos或者Kubernetes。后面的系列我們會看看如何基于軟件部署方法例如NGINX，可以方便的在微服務層面提供緩存、權限控制、API統計和監控。

總結

總而言之，微服務架構有很多吸引人的地方，不過在擁抱微服務之前要認清它所帶來的挑戰。而每一種架構都有其優缺點，我們需要根據項目業務和團隊情況來選擇合適的架構。構建復雜的應用真的是非常困難。單體式的架構更適合輕量級的簡單應用。如果你用它來開發復雜應用，那真的會很糟糕。微服務架構模式可以用來構建復雜應用，當然，這種架構模型也有自己的缺點和挑戰。