常見微服務架構方案：Spring Cloud、消息隊列、Docker Swarm等
微服務架構是當前很熱門的一個概念，它不是憑空產生的，是技術發展的必然結果。雖然微服務架構沒有公認的技術標準和規範草案，但業界已經有一些很有影響力的開源微服務架構平台，架構師可以根據公司的技術實力並結合項目的特點來選擇某個合適的微服務架構平台，以此穩妥地實施項目的微服務化改造或開發進程。
本文盤點了四種常用的微服務架構方案,分別是ZeroC IceGrid、Spring Cloud、基於消息隊列與Docker Swarm。
1 . ZeroC IceGrid微服務架構
ZeroC IceGrid作為一種微服務架構，它基於RPC框架發展而來，具有良好的性能與分散式能力，如下所示是它的整體示意圖。
首先，微服務架構需要一個集中的服務註冊中心，以及某種服務發現機制。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 項目的一種漸進改造方案，SpringBoot 里只有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開源項目時給出的具體實現方案。
2 . 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中，如下所示為相關示意圖。
那麼Spring Cloud是如何解決服務的負載均衡問題的呢？由於Spring Cloud的微服務介面主要是基於REST協議實現的，因此它採用了傳統的HTTP Proxy機制。如下圖所示，Zuul類似一個Nginx的服務網關，所有客戶端請求都通過這個網關來訪問後台的服務。
如下所示是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互聯網業務平台，採用SpringCloud是一個門檻相對較低的解決方案。3 基於消息隊列的微服務架構
除了標準的基於RPC通信（以及類RPC的通信如Http Rest、SOAP等）的微服務架構，還有基於消息隊列通信的微服務架構，這種架構下的微服務採用發送消息（Publish Message）與監聽消息（Subscribe Message）的方式來實現彼此之間的交互。下圖是這種微服務架構下各個組件之間的交互示意圖，我們看到消息中間件是關鍵，它負責連通各個微服務與UI組件，擔任了整個系統互聯互通的重任。
基於消息隊列的微服務架構是全非同步通信模式的一種設計，各個組件之間沒有直接的耦合關係，也不存在服務介面與服務調用的說法，服務之間通過消息來實現彼此的通信與業務流程的驅動，從這點來看，基於消息隊列的微服務架構非常接近Actor模型。實際上，分散式的Actor模型也可以算作一種微服務架構，並且在微服務概念產生之前就已經存在很久了。下面是一個購物網站的微服務設計示意圖，我們看到它採用了基於消息隊列的微服務架構。
網易的蜂巢平台就採用了基於消息隊列的微服務架構設計思路，如下圖所示，微服務之間通過RabbitMQ傳遞消息，實現通信。
4 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）到工作節點（SwarmNode）上等。
- 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的設計，而且在微服務架構中並沒有太多的影響力，所以我們在此並未做深入介紹，在《架構解密：從分散式到微服務》一書中將會重點介紹Kubernetes微服務平台。
本文選自《架構解密：從分散式到微服務》一書，感興趣的小夥伴不妨到書中去一探究竟~
------------
更多科技資訊請見微信公眾號：博文視點Broadview（微信號：bvbooks）
推薦閱讀：
TAG:微服務架構 | SpringCloud |