基於 Spring Cloud 的微服務架構分析

Spring Cloud 是一個相對比較新的微服務框架，2016 年才推出 1.0 的 release 版本. 雖然 Spring Cloud 時間最短, 但是相比 Dubbo 等 RPC 框架, Spring Cloud 提供的全套的分佈式系統解決方案。

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用 Spring Boot 的開發風格做到一鍵啓動和部署。

Spring 並沒有重複製造輪子，它只是將目前各家公司 (主要是 Netflix) 開發的比較成熟、經得起實際考驗的服務框架組合起來，通過 Spring Boot 風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

Spring Cloud 的核心組件

1. Eureka（註冊中心）

Eureka 是 Spring Cloud 微服務架構中的註冊中心，專門負責服務的註冊與發現, 裏面有一個註冊表, 保存了各個服務器的 機器和端口。

• Eureka服務端：也稱服務註冊中心，同其他服務註冊中心一樣，支持高可用配置。如果 Eureka 以集羣模式部署，當集羣中有分片出現故障時，那麼 Eureka 就轉入自我保護模式。它允許在分片故障期間繼續提供服務的發現和註冊，當故障分片恢復運行時，集羣中其他分片會把它們的狀態再次同步回來

• Eureka客戶端：主要處理服務的註冊與發現。客戶端服務通過註解和參數配置的方式，嵌入在客戶端應用程序的代碼中，在應用程序運行時，Eureka 客戶端想註冊中心註冊自身提供的服務並週期性地發送心跳來更新它的服務租約。同時，它也能從服務端查詢當前註冊的服務信息並把它們緩存到本地並週期性地刷新服務狀態

Eureka Server 的高可用實際上就是將自己作爲服務向其他註冊中心註冊自己，這樣就可以形成一組互相註冊的服務註冊中心，以實現服務清單的互相同步，達到高可用效果。

2. Zuul（服務網關）

Zuul 網關負責轉發請求給對應的服務，這個組件是負責網絡路由的。

Spring Cloud Zuul 通過與 Spring Cloud Eureka 進行整合，將自身註冊爲 Eureka 服務治理下的應用，同時從 Eureka 中獲得了所有其他微服務的實例信息

對於路由規則的維護，Zuul 默認會將通過以服務名作爲 ContextPath 的方式來創建路由映射

Zuul 提供了一套過濾器機制，可以支持在 API 網關無附上進行統一調用來對微服務接口做前置過濾，已實現對微服務接口的攔截和校驗

3. Ribbon（負載均衡）

提供雲端負載均衡，有多種負載均衡策略可供選擇，可配合服務發現和斷路器使用。

Ribbon 是一個基於 HTTP 和 TCP 的客戶端負載均衡器，它可以在通過客戶端中配置的ribbonServerList服務端列表去輪詢訪問以達到服務均衡的作用。

當 Ribbon 和 Eureka 聯合使用時，Ribbon 的服務實例清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從 Eureka 註冊中心中獲取服務端列表。同時它也會用NIWSDiscoveryPing來取代 IPing，它將職責委託給 Eureka 來去定服務端是否已經啓動

在客戶端負載均衡中，所有客戶端節點都維護着自己要訪問的服務端清單，而這些服務端的清單來自於服務註冊中心（比如 Eureka）。在客戶端負載均衡中也需要心跳去維護服務端清單的健康性，只是這個步驟需要與服務註冊中心配合完成。

通過 Spring Cloud Ribbon 的封裝，我們在微服務架構中使用客戶端負載均衡調用只需要如下兩步：

• 服務提供者只需要啓動多個服務實例並且註冊到一個註冊中心或是多個相關聯的服務註冊中心

• 服務消費者直接通過調用被 @LoadBalanced 註解修飾過的 RestTemplate 來實現面向服務的接口調用

4. Hystrix（熔斷保護器）

熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點, 從而對延遲和故障提供更強大的容錯能力。
提供線程池不同的服務走不同的線程池，實現了不同服務調用的隔離，避免了服務器雪崩的問題。

在微服務架構中，存在着那麼多的服務單元，若一個單元出現故障，就很容易因依賴關係而引發故障的蔓延，最終導致整個系統的癱瘓，這樣的架構相較傳統架構更加不穩定。爲了解決這樣的問題，產生了斷路器等一系列的服務保護機制

在分佈式架構中，當某個服務單元發生故障之後，通過斷路器的故障監控，向調用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障服務被長時間佔用不釋放，避免了故障在分佈式系統中的蔓延

Hystrix 具備服務降級、服務熔斷、線程和信號隔離、請求緩存、請求合併以及服務監控等強大功能

Hystrix 使用艙壁模式實現線程池的隔離，它會爲每一個依賴服務創建一個獨立的線程池，這樣就算某個依賴服務出現延遲過高的情況，也只是對該依賴服務的調用產生影響，而不會拖慢其他的依賴服務

5. Feign（REST 轉換器）

基於動態代理機制，根據註解和選擇的機器，拼接請求 url 地址，發起請求。Feign 的關鍵機制是使用了動態代理

• 首先，對某個接口定義了 @FeignClient 註解，Feign 就會針對這個接口創建一個動態代理

• 接着調用接口的時候，本質就是調用 Feign 創建的動態代理

• Feign 的動態代理會根據在接口上的 @RequestMapping 等註解，來動態構造要請求的服務的地址

• 針對這個地址，發起請求、解析響應

Feign 是和 Ribbon 以及 Eureka 緊密協作的

• 首先 Ribbon 會從 Eureka Client 裏獲取到對應的服務註冊表，也就知道了所有的服務都部署在了哪些機器上，在監聽哪些端口

• 然後 Ribbon 就可以使用默認的 Round Robin 算法，從中選擇一臺機器

• Feign 就會針對這臺機器，構造併發起請求

6. Config（分佈式配置）

配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集羣配置，目前支持本地存儲、Git 以及 Subversion。

註冊中心與 API 網關的分析

微服務網關更多是在前後端分離，或者說涉及到獨立的類似手機 APP 等前端應用的時候使用的最多，即把內部各個微服務組件模塊的 API 接口能力統一註冊和接入到網關，對於 APP 也只需要訪問網關暴露的接口即可，同時通過網關還可以進一步的實現安全隔離。

也就是說在這種場景下，網關更多的是實現了接口服務的代理和路由轉發能力，更多的是向外的一種能力發佈。

1. 一個獨立的開發團隊，爲保證獨立自治，以及內部多個微服務模塊間的交互集成，最好啓用獨立的服務註冊中心實現服務註冊，發現能力。即開發團隊內部多個微服務模塊間的集成，不需要通過網關，只需要通過服務註冊中心進行集成即可。

2. 開發團隊需要暴露能力給外部，包括暴露能力給其它的開發團隊，需要考慮將該 API 接口註冊到外部的網關上。在這裏建議是拆分兩個獨立網關，一個是內部 API 網關，一個是放置到 DMZ 區面對公網訪問的 API 網關。對於服務如果同時涉及到內部和外部使用，則兩邊註冊。建議不要通過兩次網關去路由，一個是影響性能，一個是不方便後續問題排查。

3. 構建在開發團隊之外的 API 網關必須具備負載均衡能力，可以配置多個 IP 地址。通過該 API 網關也最好具備和 Docker 容器擴展後的服務自動註冊和地址加入擴展能力。

Eureka 的競品分析：Nacos、ZooKeeper、Etcd

服務發現是一個古老的話題，當應用開始脫離單機運行和訪問時，服務發現就誕生了。目前的網絡架構是每個主機都有一個獨立的 IP 地址，那麼服務發現基本上都是通過某種方式獲取到服務所部署的 IP 地址。DNS 協議是最早將一個網絡名稱翻譯爲網絡 IP 的協議，在最初的架構選型中，DNS+LVS+Nginx 基本可以滿足所有的 RESTful 服務的發現，此時服務的 IP 列表通常配置在 Nginx 或者 LVS。後來出現了 RPC 服務，服務的上下線更加頻繁，人們開始尋求一種能夠支持動態上下線並且推送 IP 列表變化的註冊中心產品。

Eureka

• Spring Cloud Eureka 所選擇的是 AP，採用的是去中心化結構，放棄了強一致性。也就是說 Eureka 集羣中的各個結點都是平等的，沒有主從的概念。通過互相註冊的方式來進行消息同步和保證高可用。並且一個 Eureka Server 結點掛掉了，還有其他同等的結點來提供服務，並不會引發服務的中斷

• Eureka 只能當註冊中心，想搞配置中心的話，還得搭配 Spring Cloud Config+Spring Cloud Bus。其中後者支持 Rabbiimq 和 Kafka 兩種模式。

• 使用 Java 語言來開發的，並且也是 Spring Cloud 的子項目，所以可以直接通過引入 jar 包的方式來集成 Eureka，這點非常方便

1. ZooKeeper

這是一款經典的服務註冊中心產品（雖然它最初的定位並不在於此），在很長一段時間裏，它是國人在提起 RPC 服務註冊中心時心裏想到的唯一選擇，這很大程度上與 Dubbo 在中國的普及程度有關。

• Apache Zookeeper 所選擇的是 CP，也就是放棄了高可用性。Zookeeper 集羣在進行消息同步的時候，必須有一半以上結點完成了同步纔會返回；而當 Master 結點掛了或者集羣中有過半的結點不能工作了，此時就會觸發故障恢復，重新進行 Master 選舉。在這個過程中，整個 Zookeeper 集羣無法對外提供服務，從而實去了 A（可用性）

• 爲了達到 C，Zookeeper 採用的是自己的 ZAB 協議。

2. Nacos

Nacos 是阿里巴巴旗下的開源項目，在 2018 年開源，攜帶着阿里巴巴大規模服務生產經驗，試圖在服務註冊和配置管理這個市場上，提供給用戶一個新的選擇。

• Nacos 一大特性是即支持 CP，也支持 AP。可以根據需要靈活選擇。

• Nacos 除了註冊中心之外，也能充當配置中心的作用。且配置中心可以按照 namespace，group 等維度來進行數據隔離，來達到不同環境之間配置隔離的功能。

值得一提的是，Nacos 作爲配置中心的持久化機制可以依賴於Mysql來完成（默認依賴於內置數據庫）。只需要將 Nacos 目錄下的 sql 腳本放到 mysql 中執行（會生成 11 個表），然後在 nacos 配置文件裏面配一下 mysql 的賬號密碼即可。這樣使用 mysql 作爲數據源的方式相比於 nacos 內置數據庫來說更容易管理

3. Consul

Consul 是 HashiCorp 公司推出的一個開源工具。

• Consul 是用 Go 語言編寫的，所以無法像 Eureka 那樣直接引入 jar 包就能集成，它還需要去服務器中進行額外的安裝。

• 除了註冊中心的功能之外，Consul 還能起到配置中心的作用。
  Consul 它保證的是 CP，使用 raft 協議，要求必須有過半的結點都寫入成功纔算是註冊成功了，並且它也有 Master 和 Follower 的概念，在 Master 掛掉後，也需要自己內部進行

4. Etcd（待續）

對比 SpringCloud，Kubernetes 也提供完整的分佈式微服務管理框架，幾乎所有組件都有對應的產品，其中 Etcd 也可以提供類似 Eureka 的註冊中心。

在 Go 生態中，還可以選擇基於 Etcd 作爲註冊中心，Etcd 是由 CoreOS 團隊維護的、高可用分佈式鍵值存儲數據庫，可用於爲集羣提供配置和服務發現功能，Google 開源的容器管理工具 Kuberbetes 就是基於 Etcd 的。

和 Consul 一樣，Etcd 也是基於 Raft 協議作爲分佈式一致性算法來解決領導者選舉和日誌複製問題，同樣也是基於 Go 語言編寫。

Etcd 也支持代理模式（proxy），只不過在 Etcd 中，代理模式和 Consul 的客戶端代理模式類似，安裝在部署服務的節點上，用來轉發請求到 Etcd 集羣，本身不存儲任何數據，Etcd 集羣相當於 Consul 中以服務端模式運行的 Consul 集羣，通常要求配置三個及以上節點（不要太多，3~5 就夠了，以便可用性和性能上達到平衡），負責真正的請求處理 —— 服務註冊與發現。

在目前最新版本的 Etcd v3 中，通過網關模式（gateway）取代了 V2 版本中的代理模式（proxy）。

從服務發現的實現原理上來說，Consul 和 Etcd 的基本設計思路是一致的，Etcd 更簡單，Consul 則更像一個全棧的解決方案，功能比 Etcd 要更豐富，比如支持可視化的 Web UI 管理界面、支持多數據庫中心、安全層面除了 HTTPS 外還支持 ACL、更加全面的健康檢查功能、內置 DNS Server 等，這些都是 Etcd 所不具備的，但是更全面的功能往往意味着更高的複雜性，針對微服務的服務註冊和發現場景，Etcd 完全夠用了。

Spring Cloud 全家桶的簡介

• Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集羣配置，目前支持本地存儲、Git 以及 Subversion。

• Spring Cloud Bus：事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與 Spring Cloud Config 聯合實現熱部署。

• Eureka：雲端服務發現，一個基於 REST 的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。

• Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點, 從而對延遲和故障提供更強大的容錯能力。

• Zuul：Zuul 是在雲平臺上提供動態路由, 監控, 彈性, 安全等邊緣服務的框架。Zuul 相當於是設備和 Netflix 流應用的 Web 網站後端所有請求的前門。

• Archaius：配置管理 API，包含一系列配置管理 API，提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。

• Consul：封裝了 Consul 操作，Consul 是一個服務發現與配置工具，與 Docker 容器可以無縫集成。

• Spring Cloud for Cloud Foundry：通過 Oauth2 協議綁定服務到 CloudFoundry，CloudFoundry 是 VMware 推出的開源 PaaS 雲平臺。

• Spring Cloud Sleuth：日誌收集工具包，封裝了 Dapper 和 log-based 追蹤以及 Zipkin 和 HTrace 操作，爲 Spring Cloud 應用實現了一種分佈式追蹤解決方案。

• Spring Cloud Data Flow：大數據操作工具，作爲 Spring XD 的替代產品，它是一個混合計算模型，結合了流數據與批量數據的處理方式。

• Spring Cloud Security：基於 Spring Security 的安全工具包，爲你的應用程序添加安全控制。

• Spring Cloud Zookeeper：操作 Zookeeper 的工具包，用於使用 Zookeeper 方式的服務發現和配置管理。

• Spring Cloud Stream：數據流操作開發包，封裝了與 Redis、Rabbit、Kafka 等發送接收消息。

• Spring Cloud CLI：基於 Spring Boot CLI，可以讓你以命令行方式快速建立雲組件。

• Ribbon：提供雲端負載均衡，有多種負載均衡策略可供選擇，可配合服務發現和斷路器使用。

• Turbine：Turbine 是聚合服務器發送事件流數據的一個工具，用來監控集羣下 Hystrix 的 Metrics 情況。

• Feign：Feign 是一種聲明式、模板化的 HTTP 客戶端。

• Spring Cloud Task：提供雲端計劃任務管理、任務調度。

• Spring Cloud Connectors：便於雲端應用程序在各種 PaaS 平臺連接到後端，如：數據庫和消息代理服務。

• Spring Cloud Cluster：提供 Leadership 選舉，如：Zookeeper，Redis，Hazelcast，Consul 等常見狀態模式的抽象和實現。

• Spring Cloud Starters：Spring Boot 式的啓動項目，爲 Spring Cloud 提供開箱即用的依賴管理。

參考文獻

• Nacos PMC 朱鵬飛的深度技術分析

• 深入理解 Spring Cloud 核心組件與底層原理

• Spring Cloud 核心模型 & 案例彙集

• 基於電商網站的 spring Cloud 架構分析

• 一個完整的 Spring Cloud 的分佈式架構

• Spring Cloud - Nacos 與 Eureka 區別及如何選型

• 各大微服務註冊中心簡單對比：ZooKeeper、Eureka、Consul 、Nacos

• 微服務網關和服務註冊中心

• 註冊中心與 API 網關不是這樣用的！

• Eureka 介紹和部署

• Eureka 集羣部署的踩坑記錄

作者：Alex

來源：blog.caogo.cn/2021/06/20/%E5%9F%BA%E4%BA%8ESpring-Cloud%E7%9A%84%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E5%88%86%E6%9E%90/

架構師

我們都是架構師！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/bY3MsjH_Ha0jfD8cJMpjmw