幾種常見的微服務架構方案——ZeroC IceGrid、Spring Cloud、基於消息隊列、Docker Swarm

微服務架構是當前很熱門的一個概念，它不是憑空產生的，是技術發展的必然結果。雖然微服務架構沒有公認的技術標準和規範草案，但業界已經有一些頗有影響力的開源微服務架構平臺，架構師能夠根據公司的技術實力並結合項目的特色來選擇某個合適的微服務架構平臺，以此穩妥地實施項目的微服務化改造或開發進程。

本文盤點了四種經常使用的微服務架構方案，分別是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在開源項目中給出了這種方式的一個基本框架以供參考：github.com/MyCATApache…

方案二與方案三則比較適合前端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的設計，並且在微服務架構中並無太多的影響力，因此咱們在此並未作深刻介紹。
廣告時間到，你看，咱們給你準備好了各大互聯網公司Java面試題，賞不賞臉取一下嘛~~~

關注微信公衆號「Java高級架構」，回覆「面試」便可獲取~~

想獲取下方學習資料關注微信公衆號「Java高級架構」回覆「架構資料」便可獲取~~

原文連接：www.broadview.com.cn/article/348