幾種常見的微服務架構方案

本文盤點了四種常用的微服務架構方案，分別是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的做法更加高效，但增加了平臺開發的工作量與難度，因為採用各種語言的客戶端都需要實現一遍負載均衡的演算法邏輯。

如果你也想在IT行業拿高薪，可以參加我們的訓練營課程，選擇最適合自己的課程學習，技術大牛親授，7個月後，進入名企拿高薪。我們的課程內容有：Java工程化、高效能及分散式、高效能、深入淺出。高架構。效能調優、Spring，MyBatis，Netty原始碼分析和大資料等多個知識點。如果你想拿高薪的，想學習的，想就業前景好的，想跟別人競爭能取得優勢的，想進阿里面試但擔心面試不過的，你都可以來，群號為：71859422

注：加群要求

1、具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。

2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。

3、如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。

4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加。

5.阿里Java高階大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知！

6.小號或者小白之類加群一律不給過，謝謝。

目標已經有了，下面就看行動了！記住：學習永遠是自己的事情，你不學時間也不會多，你學了有時候卻能夠使用自己學到的知識換得更多自由自在的美好時光！時間是生命的基本組成部分，也是萬物存在的根本尺度，我們的時間在那裡我們的生活就在那裡！我們價值也將在那裡提升或消弭！Java程式設計師，加油吧

最後，一個好的微服務架構平臺應該簡化和方便應用部署。我們看到 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的做法。