微服務架構是當前很熱門的一個概念，它不是憑空產生的，是技術發展的必然結果。雖然微服務架構沒有公認的技術標準和規範草案，但業界已經有一些很有影響力的開源微服務架構平臺，架構師可以根據公司的技術實力並結合專案的特點來選擇某個合適的微服務架構平臺，以此穩妥地實施專案的微服務化改造或開發程序。
本文盤點了四種常用的微服務架構方案，分別是ZeroC IceGrid、Spring Cloud、基於訊息佇列與Docker Swarm。
ZeroC IceGrid微服務架構

ZeroC IceGrid作為一種微服務架構，它基於RPC框架發展而來，具有良好的效能與分散式能力，如下所示是它的整體示意圖。

IceGrid具備微服務架構的如下明顯特徵。
首先，微服務架構需要一個集中的服務註冊中心，以及某種服務發現機制。IceGrid服務註冊採用XML檔案來定義，其服務註冊中心就是Ice Registry，這是一個獨立的程序，並且提供了HA高可用機制；對應的服務發現機制就是命名查詢服務，即LocatorService提供的API，可以根據服務名查詢對應的服務例項可用地址。
其次，微服務架構中的每個微服務通常會被部署為一個獨立的程序，當無狀態服務時，一般會由多個獨立程序提供服務。對應在IceGrid裡，一個IceBox就是一個單獨的程序，當一個IceBox只封裝一個Servant時，就是一個典型的微服務程序了。
然後，微服務架構中通常都需要內嵌某種負載均衡機制。在 IceGrid 裡是通過客戶端API內嵌的負載均衡演算法實現的，相對於採用中介軟體Proxy轉發流量的方式，IceGrid的做法更加高效，但增加了平臺開發的工作量與難度，因為採用各種語言的客戶端都需要實現一遍負載均衡的演算法邏輯。
最後，一個好的微服務架構平臺應該簡化和方便應用部署。我們看到 IceGrid提供了grid.xml來描述與定義一個基於微服務架構的Application，一個命令列工具一鍵部署這個Application，還提供了釋出二進位制程式的輔助工具——icepatch2。下圖顯示icepatch2的工作機制，icepatch2server類似於FTP Sever，用於存放要釋出到每個Node上的二進位制程式碼與配置檔案，而位於每個Node上的icepatch2client則從icepatch2server上拉取檔案，這個過程中採用了壓縮傳輸及差量傳輸等高階特性，以減少不必要的檔案傳輸過程。客觀地評價，在Docker技術之前，icepatch2這套做法還是很先進與完備的，也大大減少了分散式叢集下微服務系統的運維工作量。

如果基於IceGrid開發系統，則通常有三種典型的技術方案，下圖展示了這三種技術方案。

其中方案一是比較符合傳統Java Web專案的一種漸進改造方案，Spring Boot裡只有Controller元件而沒有資料訪問層與Service物件，這些Controller元件通過Ice RPC方式呼叫部署在IceGrid裡的遠端的Ice微服務，面向前端包裝為REST服務。此方案的整體思路清晰，分工明確。Leader在開源專案中給出了這種方式的一個基本框架以供參考：https://github.com/MyCATApache/mycat-ice。
方案二與方案三則比較適合前端JavaScript能力強的團隊，比如很擅長Node.js的團隊可以考慮方案二，即用JavaScript來替代Spring Boot實現REST服務。主要做網際網路App的系統則可以考慮方案三，瀏覽器端的JavaScript以HTML5的WebSocket技術與Ice Glacier2直接通訊，整體高效敏捷。
IceGrid在3.6版本之後還增加了容器化的執行方式，即Ice Node與Ice Registry可以通過Docker容器的方式啟動，這就簡化了IceGrid在Linux上的部署。對於用Java編寫的Ice微服務架構系統，我們還可以藉助Java遠端類載入機制，讓每臺Node自動從某個遠端HTTP Server下載指定的Jar包並載入相關的Servant類，從而實現類似Docker Hub的機制。下圖顯示了前面提到mycat-ice開源專案時給出的具體實現方案。

Spring Cloud微服務架構

Spring Cloud是基於Spring Boot的一整套實現微服務的框架，因此它只能採用Java語言，這是它與其他幾個微服務框架的最明顯區別。Spring Cloud是一個包含了很多子專案的整體方案，其中由Netflix開發後來又併入Spring Cloud的Spring Cloud Netflix是Spring Cloud微服務架構的核心專案，即可以簡單地認為Spring Cloud微服務架構就是Spring Cloud Netflix，後面我們用Spring Cloud時如果不特意宣告，就是指Spring Cloud Netflix。
首先，Spring Cloud中的服務註冊中心是Eureka模組，它提供了一個服務註冊中心、服務發現的客戶端，還有一個簡單的管理介面，所有服務使用Eureka的服務發現客戶端來將自己註冊到Eureka中，如下所示為相關示意圖，你會發現它很像之前第4章中的某個圖。

那麼Spring Cloud是如何解決服務的負載均衡問題的呢？由於Spring Cloud的微服務介面主要是基於REST協議實現的，因此它採用了傳統的HTTP Proxy機制。如下圖所示，Zuul類似一個Nginx的服務閘道器，所有客戶端請求都通過這個閘道器來訪問後臺的服務。

Zuul從Eureka那裡獲取服務資訊，自動完成路由規則的對映，無須手工配置，比如上圖中的URL路徑/customer/*就被對映到Customer這個微服務上。當Zuul轉發請求到某個指定的微服務上時，會採用類似ZeroC IceGrid的客戶端負載均衡機制，被稱為Ribbon元件，下圖給出了Zuul與Eureka的關係及實現服務負載均衡的示意圖。

如下所示是Spring Cloud微服務架構平臺的全景圖。我們看到它很明顯地繼承了Spring Framework一貫的思路——集大成！

從圖中來看，Spring Cloud 微服務架構平臺集成了以下一些實際專案開發中常用的技術與功能模組。
基於Spring Security的OAuth模組，解決服務安全問題。
提供組合服務（Composite Services）的能力。
電路斷路器 Hystrix，實現對某些關鍵服務介面的熔斷保護功能，如果一個服務沒有響應（如超時或者網路連線故障），則Hystrix可以在服務消費方中重定向請求到回退方法（fallback method）。如果服務重複失敗，則Hystrix會快速失敗（例如直接呼叫內部的回退方法，不再嘗試呼叫服務），直到服務重新恢復正常。
監控用的Dashboard，可以簡化運維相關的開發工作量。
總體來說，Spring Cloud是替代Dubbo的一種好方案，雖然Spring Cloud是基於REST通訊介面的微服務架構，而Dubbo以RPC通訊為基礎。對於效能要求不是很高的Java網際網路業務平臺，採用Spring Cloud是一個門檻相對較低的解決方案。
基於訊息佇列的微服務架構

除了標準的基於RPC通訊（以及類RPC的通訊如Http Rest、SOAP等）的微服務架構，還有基於訊息佇列通訊的微服務架構，這種架構下的微服務採用傳送訊息（Publish Message）與監聽訊息（Subscribe Message）的方式來實現彼此之間的互動。下圖是這種微服務架構下各個元件之間的互動示意圖，我們看到訊息中介軟體是關鍵，它負責連通各個微服務與UI元件，擔任了整個系統互聯互通的重任。

基於訊息佇列的微服務架構是全非同步通訊模式的一種設計，各個元件之間沒有直接的耦合關係，也不存在服務介面與服務呼叫的說法，服務之間通過訊息來實現彼此的通訊與業務流程的驅動，從這點來看，基於訊息佇列的微服務架構非常接近Actor模型。實際上，分散式的Actor模型也可以算作一種微服務架構，並且在微服務概念產生之前就已經存在很久了。下面是一個購物網站的微服務設計示意圖，我們看到它採用了基於訊息佇列的微服務架構。
網易的蜂巢平臺就採用了基於訊息佇列的微服務架構設計思路，如下圖所示，微服務之間通過RabbitMQ傳遞訊息，實現通訊。

與上面幾種微服務架構相比，基於訊息佇列的微服務架構並不多，案例也相對較少，更多地體現為一種與業務相關的設計經驗，各家有各家的實現方式，缺乏公認的設計思路與參考架構，也沒有形成一個知名的開源平臺。因此，如果需要實施這種微服務架構，則基本上需要專案組自己從零開始去設計實現一個微服務架構基礎平臺，其代價是成本高、風險大，因此決策之前需要架構師“接地氣”地進行全盤思考與客觀評價。
Docker Swarm微服務架構

Docker Swarm其實是Docker公司“高仿”Google開源的Kubernetes微服務架構平臺的一個產品，但一直無法跟上對手的腳步，在業界始終缺乏影響力。2016年釋出Docker 1.12時，Docker Swarm就被強行整合到了Docker Engine中而不再作為單獨的工具釋出了，這類似當年微軟推廣IE瀏覽器的做法。不過即使這樣，也難以掩蓋Docker Swarm還沒成名就已經隕落的事實。
Docker Swarm的最初目標是將一些獨立的Docker主機變成一個叢集，如下圖所示，我們通過簡單的Docker命令列工具就能建立一個Swarm叢集。

後來隨著Kubernetes微服務架構平臺越來越火，Docker 公司開始努力讓Swarm向著Kubernetes的方向靠攏，即變成一個基於容器技術的微服務平臺。下面給出了Swarm叢集的結構圖。

從圖中我們看到一個Swarm叢集中有兩種角色的節點。
Swarm Manager：負責叢集的管理、叢集狀態的維持及排程任務（Task）到工作節點（Swarm Node）上等。
Swarm Node：承載執行在Swarm叢集中的容器例項，每個Node主動彙報其上執行的任務（Task）並維持同步狀態。
上圖中的Docker Compose是官方編排（Orchestration）專案，它提供了一個YAML格式的檔案，用於描述一個容器化的分散式應用，並且提供了相應的工具來實現一鍵部署的功能。下圖給出了兩節點的Couchbase叢集對應的YAML檔案定義，此Couchbase叢集隨後被部署到了Swarm叢集中的兩個Node節點上。

注意上圖左邊YAML檔案中的Services定義，Swarm manager節點給每個Service分配唯一的DNS名字，因此可以通過最古老又簡單的DNS輪詢機制來實現服務的發現與負載均衡，這明顯借鑑了Kubernetes的做法。
由於Docker Swarm高仿了前輩Kubernetes的設計，而且在微服務架構中並沒有太多的影響力，所以我們在此並未做深入介紹。
推薦一個交流學習群：685167672 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多：