123,123

[導(dǎo)讀]作者：Alex來源：blog.caogo.cn/2021/06/20/基于Spring-Cloud的微服務(wù)架構(gòu)分析/SpringCloud是一個相對比較新的微服務(wù)框架，2016年才推出1.0的release版本.雖然SpringCloud時間最短,但是相比Dubbo等RPC框架,...

作者：Alex

來源：blog.caogo.cn/2021/06/20/基于Spring-Cloud的微服務(wù)架構(gòu)分析/

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

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開發(fā)，如服務(wù)發(fā)現(xiàn)注冊、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開發(fā)風(fēng)格做到一鍵啟動和部署。Spring并沒有重復(fù)制造輪子，它只是將目前各家公司(主要是 Netflix )開發(fā)的比較成熟、經(jīng)得起實際考驗的服務(wù)框架組合起來，通過Spring Boot風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。基于Spring?Cloud的微服務(wù)架構(gòu)分析

Spring Cloud 的核心組件

1. Eureka（注冊中心）

Eureka 是 Spring Cloud 微服務(wù)架構(gòu)中的注冊中心，專門負(fù)責(zé)服務(wù)的注冊與發(fā)現(xiàn),里面有一個注冊表,保存了各個服務(wù)器的機器和端口。

Eureka服務(wù)端：也稱服務(wù)注冊中心，同其他服務(wù)注冊中心一樣，支持高可用配置。如果Eureka以集群模式部署，當(dāng)集群中有分片出現(xiàn)故障時，那么Eureka就轉(zhuǎn)入自我保護模式。它允許在分片故障期間繼續(xù)提供服務(wù)的發(fā)現(xiàn)和注冊，當(dāng)故障分片恢復(fù)運行時，集群中其他分片會把它們的狀態(tài)再次同步回來
Eureka客戶端：主要處理服務(wù)的注冊與發(fā)現(xiàn)?？蛻舳朔?wù)通過注解和參數(shù)配置的方式，嵌入在客戶端應(yīng)用程序的代碼中，在應(yīng)用程序運行時，Eureka客戶端想注冊中心注冊自身提供的服務(wù)并周期性地發(fā)送心跳來更新它的服務(wù)租約。同時，它也能從服務(wù)端查詢當(dāng)前注冊的服務(wù)信息并把它們緩存到本地并周期性地刷新服務(wù)狀態(tài)

Eureka Server 的高可用實際上就是將自己作為服務(wù)向其他注冊中心注冊自己，這樣就可以形成一組互相注冊的服務(wù)注冊中心，以實現(xiàn)服務(wù)清單的互相同步，達(dá)到高可用效果。

2. Zuul（服務(wù)網(wǎng)關(guān)）

Zuul網(wǎng)關(guān)負(fù)責(zé)轉(zhuǎn)發(fā)請求給對應(yīng)的服務(wù)，這個組件是負(fù)責(zé)網(wǎng)絡(luò)路由的。Spring Cloud Zuul通過與Spring Cloud Eureka進(jìn)行整合，將自身注冊為Eureka服務(wù)治理下的應(yīng)用，同時從Eureka中獲得了所有其他微服務(wù)的實例信息對于路由規(guī)則的維護，Zuul默認(rèn)會將通過以服務(wù)名作為ContextPath的方式來創(chuàng)建路由映射Zuul提供了一套過濾器機制，可以支持在API網(wǎng)關(guān)無附上進(jìn)行統(tǒng)一調(diào)用來對微服務(wù)接口做前置過濾，已實現(xiàn)對微服務(wù)接口的攔截和校驗

3. Ribbon（負(fù)載均衡）

提供云端負(fù)載均衡，有多種負(fù)載均衡策略可供選擇，可配合服務(wù)發(fā)現(xiàn)和斷路器使用。Ribbon是一個基于HTTP和TCP的客戶端負(fù)載均衡器，它可以在通過客戶端中配置的ribbonServerList服務(wù)端列表去輪詢訪問以達(dá)到服務(wù)均衡的作用。當(dāng)Ribbon和Eureka聯(lián)合使用時，Ribbon的服務(wù)實例清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka注冊中心中獲取服務(wù)端列表。同時它也會用NIWSDiscoveryPing來取代IPing，它將職責(zé)委托給Eureka來去定服務(wù)端是否已經(jīng)啟動在客戶端負(fù)載均衡中，所有客戶端節(jié)點都維護著自己要訪問的服務(wù)端清單，而這些服務(wù)端的清單來自于服務(wù)注冊中心（比如Eureka）。在客戶端負(fù)載均衡中也需要心跳去維護服務(wù)端清單的健康性，只是這個步驟需要與服務(wù)注冊中心配合完成。通過Spring Cloud Ribbon的封裝，我們在微服務(wù)架構(gòu)中使用客戶端負(fù)載均衡調(diào)用只需要如下兩步：

服務(wù)提供者只需要啟動多個服務(wù)實例并且注冊到一個注冊中心或是多個相關(guān)聯(lián)的服務(wù)注冊中心
服務(wù)消費者直接通過調(diào)用被@LoadBalanced注解修飾過的RestTemplate來實現(xiàn)面向服務(wù)的接口調(diào)用

4. Hystrix（熔斷保護器）

熔斷器，容錯管理工具，旨在通過熔斷機制控制服務(wù)和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力。
提供線程池不同的服務(wù)走不同的線程池，實現(xiàn)了不同服務(wù)調(diào)用的隔離，避免了服務(wù)器雪崩的問題。在微服務(wù)架構(gòu)中，存在著那么多的服務(wù)單元，若一個單元出現(xiàn)故障，就很容易因依賴關(guān)系而引發(fā)故障的蔓延，最終導(dǎo)致整個系統(tǒng)的癱瘓，這樣的架構(gòu)相較傳統(tǒng)架構(gòu)更加不穩(wěn)定。為了解決這樣的問題，產(chǎn)生了斷路器等一系列的服務(wù)保護機制在分布式架構(gòu)中，當(dāng)某個服務(wù)單元發(fā)生故障之后，通過斷路器的故障監(jiān)控，向調(diào)用方返回一個錯誤響應(yīng)，而不是長時間的等待。這樣就不會使得線程因調(diào)用故障服務(wù)被長時間占用不釋放，避免了故障在分布式系統(tǒng)中的蔓延Hystrix具備服務(wù)降級、服務(wù)熔斷、線程和信號隔離、請求緩存、請求合并以及服務(wù)監(jiān)控等強大功能Hystrix使用艙壁模式實現(xiàn)線程池的隔離，它會為每一個依賴服務(wù)創(chuàng)建一個獨立的線程池，這樣就算某個依賴服務(wù)出現(xiàn)延遲過高的情況，也只是對該依賴服務(wù)的調(diào)用產(chǎn)生影響，而不會拖慢其他的依賴服務(wù)

5. Feign（REST轉(zhuǎn)換器）

基于動態(tài)代理機制，根據(jù)注解和選擇的機器，拼接請求url地址，發(fā)起請求。Feign的關(guān)鍵機制是使用了動態(tài)代理

首先，對某個接口定義了@FeignClient注解，F(xiàn)eign就會針對這個接口創(chuàng)建一個動態(tài)代理
接著調(diào)用接口的時候，本質(zhì)就是調(diào)用Feign創(chuàng)建的動態(tài)代理
Feign的動態(tài)代理會根據(jù)在接口上的@RequestMapping等注解，來動態(tài)構(gòu)造要請求的服務(wù)的地址
針對這個地址，發(fā)起請求、解析響應(yīng)

Feign是和Ribbon以及Eureka緊密協(xié)作的

首先Ribbon會從Eureka Client里獲取到對應(yīng)的服務(wù)注冊表，也就知道了所有的服務(wù)都部署在了哪些機器上，在監(jiān)聽哪些端口
然后Ribbon就可以使用默認(rèn)的Round Robin算法，從中選擇一臺機器
Feign就會針對這臺機器，構(gòu)造并發(fā)起請求

6. Config（分布式配置）

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

注冊中心與API網(wǎng)關(guān)的分析

微服務(wù)網(wǎng)關(guān)更多是在前后端分離，或者說涉及到獨立的類似手機APP等前端應(yīng)用的時候使用的最多，即把內(nèi)部各個微服務(wù)組件模塊的API接口能力統(tǒng)一注冊和接入到網(wǎng)關(guān)，對于APP也只需要訪問網(wǎng)關(guān)暴露的接口即可，同時通過網(wǎng)關(guān)還可以進(jìn)一步的實現(xiàn)安全隔離。也就是說在這種場景下，網(wǎng)關(guān)更多的是實現(xiàn)了接口服務(wù)的代理和路由轉(zhuǎn)發(fā)能力，更多的是向外的一種能力發(fā)布。

一個獨立的開發(fā)團隊，為保證獨立自治，以及內(nèi)部多個微服務(wù)模塊間的交互集成，最好啟用獨立的服務(wù)注冊中心實現(xiàn)服務(wù)注冊，發(fā)現(xiàn)能力。即開發(fā)團隊內(nèi)部多個微服務(wù)模塊間的集成，不需要通過網(wǎng)關(guān)，只需要通過服務(wù)注冊中心進(jìn)行集成即可。
開發(fā)團隊需要暴露能力給外部，包括暴露能力給其它的開發(fā)團隊，需要考慮將該API接口注冊到外部的網(wǎng)關(guān)上。在這里建議是拆分兩個獨立網(wǎng)關(guān)，一個是內(nèi)部API網(wǎng)關(guān)，一個是放置到DMZ區(qū)面對公網(wǎng)訪問的API網(wǎng)關(guān)。對于服務(wù)如果同時涉及到內(nèi)部和外部使用，則兩邊注冊。建議不要通過兩次網(wǎng)關(guān)去路由，一個是影響性能，一個是不方便后續(xù)問題排查。
構(gòu)建在開發(fā)團隊之外的API網(wǎng)關(guān)必須具備負(fù)載均衡能力，可以配置多個IP地址。通過該API網(wǎng)關(guān)也最好具備和Docker容器擴展后的服務(wù)自動注冊和地址加入擴展能力。

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

服務(wù)發(fā)現(xiàn)是一個古老的話題，當(dāng)應(yīng)用開始脫離單機運行和訪問時，服務(wù)發(fā)現(xiàn)就誕生了。目前的網(wǎng)絡(luò)架構(gòu)是每個主機都有一個獨立的IP地址，那么服務(wù)發(fā)現(xiàn)基本上都是通過某種方式獲取到服務(wù)所部署的IP地址。DNS協(xié)議是最早將一個網(wǎng)絡(luò)名稱翻譯為網(wǎng)絡(luò)IP的協(xié)議，在最初的架構(gòu)選型中，DNS LVS Nginx基本可以滿足所有的RESTful服務(wù)的發(fā)現(xiàn)，此時服務(wù)的IP列表通常配置在Nginx或者LVS。后來出現(xiàn)了RPC服務(wù)，服務(wù)的上下線更加頻繁，人們開始尋求一種能夠支持動態(tài)上下線并且推送IP列表變化的注冊中心產(chǎn)品。基于Spring?Cloud的微服務(wù)架構(gòu)分析

Eureka

Spring Cloud Eureka所選擇的是AP，采用的是去中心化結(jié)構(gòu)，放棄了強一致性。也就是說Eureka集群中的各個結(jié)點都是平等的，沒有主從的概念。通過互相注冊的方式來進(jìn)行消息同步和保證高可用。并且一個Eureka Server結(jié)點掛掉了，還有其他同等的結(jié)點來提供服務(wù)，并不會引發(fā)服務(wù)的中斷
Eureka只能當(dāng)注冊中心，想搞配置中心的話，還得搭配Spring Cloud Config Spring Cloud Bus。其中后者支持Rabbiimq和Kafka兩種模式。
使用Java語言來開發(fā)的，并且也是Spring Cloud的子項目，所以可以直接通過引入jar包的方式來集成Eureka，這點非常方便

1. ZooKeeper

這是一款經(jīng)典的服務(wù)注冊中心產(chǎn)品（雖然它最初的定位并不在于此），在很長一段時間里，它是國人在提起RPC服務(wù)注冊中心時心里想到的唯一選擇，這很大程度上與Dubbo在中國的普及程度有關(guān)。

Apache Zookeeper所選擇的是CP，也就是放棄了高可用性。Zookeeper集群在進(jìn)行消息同步的時候，必須有一半以上結(jié)點完成了同步才會返回；而當(dāng)Master結(jié)點掛了或者集群中有過半的結(jié)點不能工作了，此時就會觸發(fā)故障恢復(fù)，重新進(jìn)行Master選舉。在這個過程中，整個Zookeeper集群無法對外提供服務(wù)，從而實去了A（可用性）
為了達(dá)到C，Zookeeper采用的是自己的ZAB協(xié)議。

2. Nacos

Nacos是阿里巴巴旗下的開源項目，在2018年開源，攜帶著阿里巴巴大規(guī)模服務(wù)生產(chǎn)經(jīng)驗，試圖在服務(wù)注冊和配置管理這個市場上，提供給用戶一個新的選擇。

Nacos一大特性是即支持CP，也支持AP。可以根據(jù)需要靈活選擇。
Nacos除了注冊中心之外，也能充當(dāng)配置中心的作用。且配置中心可以按照namespace，group等維度來進(jìn)行數(shù)據(jù)隔離，來達(dá)到不同環(huán)境之間配置隔離的功能。

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

3. Consul

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

Consul是用Go語言編寫的，所以無法像Eureka那樣直接引入jar包就能集成，它還需要去服務(wù)器中進(jìn)行額外的安裝。
除了注冊中心的功能之外，Consul還能起到配置中心的作用。
Consul它保證的是CP，使用raft協(xié)議，要求必須有過半的結(jié)點都寫入成功才算是注冊成功了，并且它也有Master和Follower的概念，在Master掛掉后，也需要自己內(nèi)部進(jìn)行

4. Etcd（待續(xù)）

對比SpringCloud，Kubernetes也提供完整的分布式微服務(wù)管理框架，幾乎所有組件都有對應(yīng)的產(chǎn)品，其中Etcd也可以提供類似Eureka的注冊中心。在 Go 生態(tài)中，還可以選擇基于 Etcd 作為注冊中心，Etcd 是由 CoreOS 團隊維護的、高可用分布式鍵值存儲數(shù)據(jù)庫，可用于為集群提供配置和服務(wù)發(fā)現(xiàn)功能，Google 開源的容器管理工具 Kuberbetes 就是基于 Etcd 的。和 Consul 一樣，Etcd 也是基于 Raft 協(xié)議作為分布式一致性算法來解決領(lǐng)導(dǎo)者選舉和日志復(fù)制問題，同樣也是基于 Go 語言編寫。Etcd 也支持代理模式（proxy），只不過在 Etcd 中，代理模式和 Consul 的客戶端代理模式類似，安裝在部署服務(wù)的節(jié)點上，用來轉(zhuǎn)發(fā)請求到 Etcd 集群，本身不存儲任何數(shù)據(jù)，Etcd 集群相當(dāng)于 Consul 中以服務(wù)端模式運行的 Consul 集群，通常要求配置三個及以上節(jié)點（不要太多，3~5就夠了，以便可用性和性能上達(dá)到平衡），負(fù)責(zé)真正的請求處理 —— 服務(wù)注冊與發(fā)現(xiàn)。在目前最新版本的 Etcd v3中，通過網(wǎng)關(guān)模式（gateway）取代了 V2 版本中的代理模式（proxy）。從服務(wù)發(fā)現(xiàn)的實現(xiàn)原理上來說，Consul 和 Etcd 的基本設(shè)計思路是一致的，Etcd 更簡單，Consul 則更像一個全棧的解決方案，功能比 Etcd 要更豐富，比如支持可視化的 Web UI 管理界面、支持多數(shù)據(jù)庫中心、安全層面除了 HTTPS 外還支持 ACL、更加全面的健康檢查功能、內(nèi)置 DNS Server 等，這些都是 Etcd 所不具備的，但是更全面的功能往往意味著更高的復(fù)雜性，針對微服務(wù)的服務(wù)注冊和發(fā)現(xiàn)場景，Etcd 完全夠用了。

Spring Cloud 全家桶的簡介

Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠(yuǎn)程服務(wù)器，集中化管理集群配置，目前支持本地存儲、Git 以及 Subversion。
Spring Cloud Bus：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態(tài)變化，可與 Spring Cloud Config 聯(lián)合實現(xiàn)熱部署。
Eureka：云端服務(wù)發(fā)現(xiàn)，一個基于 REST 的服務(wù)，用于定位服務(wù)，以實現(xiàn)云端中間層服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移。
Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務(wù)和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力。
Zuul：Zuul 是在云平臺上提供動態(tài)路由,監(jiān)控,彈性,安全等邊緣服務(wù)的框架。Zuul 相當(dāng)于是設(shè)備和 Netflix 流應(yīng)用的 Web 網(wǎng)站后端所有請求的前門。
Archaius：配置管理 API，包含一系列配置管理 API，提供動態(tài)類型化屬性、線程安全配置操作、輪詢框架、回調(diào)機制等功能。
Consul：封裝了 Consul 操作，Consul 是一個服務(wù)發(fā)現(xiàn)與配置工具，與 Docker 容器可以無縫集成。
Spring Cloud for Cloud Foundry：通過 Oauth2 協(xié)議綁定服務(wù)到 CloudFoundry，CloudFoundry 是 VMware 推出的開源 PaaS 云平臺。
Spring Cloud Sleuth：日志收集工具包，封裝了 Dapper 和 log-based 追蹤以及 Zipkin 和 HTrace 操作，為 Spring Cloud 應(yīng)用實現(xiàn)了一種分布式追蹤解決方案。
Spring Cloud Data Flow：大數(shù)據(jù)操作工具，作為 Spring XD 的替代產(chǎn)品，它是一個混合計算模型，結(jié)合了流數(shù)據(jù)與批量數(shù)據(jù)的處理方式。
Spring Cloud Security：基于 Spring Security 的安全工具包，為你的應(yīng)用程序添加安全控制。
Spring Cloud Zookeeper：操作 Zookeeper 的工具包，用于使用 Zookeeper 方式的服務(wù)發(fā)現(xiàn)和配置管理。
Spring Cloud Stream：數(shù)據(jù)流操作開發(fā)包，封裝了與 Redis、Rabbit、Kafka 等發(fā)送接收消息。
Spring Cloud CLI：基于 Spring Boot CLI，可以讓你以命令行方式快速建立云組件。
Ribbon：提供云端負(fù)載均衡，有多種負(fù)載均衡策略可供選擇，可配合服務(wù)發(fā)現(xiàn)和斷路器使用。
Turbine：Turbine 是聚合服務(wù)器發(fā)送事件流數(shù)據(jù)的一個工具，用來監(jiān)控集群下 Hystrix 的 Metrics 情況。
Feign：Feign 是一種聲明式、模板化的 HTTP 客戶端。
Spring Cloud Task：提供云端計劃任務(wù)管理、任務(wù)調(diào)度。
Spring Cloud Connectors：便于云端應(yīng)用程序在各種 PaaS 平臺連接到后端，如：數(shù)據(jù)庫和消息代理服務(wù)。
Spring Cloud Cluster：提供 Leadership 選舉，如：Zookeeper，Redis，Hazelcast，Consul 等常見狀態(tài)模式的抽象和實現(xiàn)。
Spring Cloud Starters：Spring Boot 式的啟動項目，為 Spring Cloud 提供開箱即用的依賴管理。