許多公司，比如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概念。

微服務架構的優勢與不足（二）