123,123,123

[導讀]-???前言??-SpringCloud是一個相對比較新的微服務框架，2016年才推出1.0的release版本.雖然SpringCloud時間最短,但是相比Dubbo等RPC框架,SpringCloud提供的全套的分布式系統解決方案。SpringCloud是一系列框架的有序集合...

- 前言 -

Spring Cloud是一個相對比較新的微服務框架，2016年才推出1.0的release版本. 雖然Spring Cloud時間最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系統解決方案。
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統基礎設施的開發(fā)，如服務發(fā)現注冊、配置中心、消息總線、負載均衡、斷路器、數據監(jiān)控等，都可以用Spring Boot的開發(fā)風格做到一鍵啟動和部署。Spring并沒有重復制造輪子，它只是將目前各家公司(主要是 Netflix )開發(fā)的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統開發(fā)工具包。基于?Spring?Cloud?的微服務架構分析

- 核心組件剖析 -

1. Eureka（注冊中心）

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

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

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

2. Zuul（服務網關）

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

3. Ribbon（負載均衡）

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

服務提供者只需要啟動多個服務實例并且注冊到一個注冊中心或是多個相關聯的服務注冊中心
服務消費者直接通過調用被@LoadBalanced注解修飾過的RestTemplate來實現面向服務的接口調用

4. Hystrix（熔斷保護器）

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

5. Feign（REST轉換器）

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

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

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

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

6. Config（分布式配置）

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

- 注冊中心與 API 網關 -

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

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

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

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

Eureka

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

1. ZooKeeper

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

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

2. Nacos

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

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

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

3. Consul

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

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

4. Etcd（待續(xù)）

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

- 一圖詳解Spring Cloud全家桶 -

Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集群配置，目前支持本地存儲、Git 以及 Subversion。
Spring Cloud Bus：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態(tài)變化，可與 Spring Cloud Config 聯合實現熱部署。
Eureka：云端服務發(fā)現，一個基于 REST 的服務，用于定位服務，以實現云端中間層服務發(fā)現和故障轉移。
Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力。
Zuul：Zuul 是在云平臺上提供動態(tài)路由,監(jiān)控,彈性,安全等邊緣服務的框架。Zuul 相當于是設備和 Netflix 流應用的 Web 網站后端所有請求的前門。
Archaius：配置管理 API，包含一系列配置管理 API，提供動態(tài)類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。
Consul：封裝了 Consul 操作，Consul 是一個服務發(fā)現與配置工具，與 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 方式的服務發(fā)現和配置管理。
Spring Cloud Stream：數據流操作開發(fā)包，封裝了與 Redis、Rabbit、Kafka 等發(fā)送接收消息。
Spring Cloud CLI：基于 Spring Boot CLI，可以讓你以命令行方式快速建立云組件。
Ribbon：提供云端負載均衡，有多種負載均衡策略可供選擇，可配合服務發(fā)現和斷路器使用。
Turbine：Turbine 是聚合服務器發(fā)送事件流數據的一個工具，用來監(jiān)控集群下 Hystrix 的 Metrics 情況。
Feign：Feign 是一種聲明式、模板化的 HTTP 客戶端。
Spring Cloud Task：提供云端計劃任務管理、任務調度。
Spring Cloud Connectors：便于云端應用程序在各種 PaaS 平臺連接到后端，如：數據庫和消息代理服務。
Spring Cloud Cluster：提供 Leadership 選舉，如：Zookeeper，Redis，Hazelcast，Consul 等常見狀態(tài)模式的抽象和實現。
Spring Cloud Starters：Spring Boot 式的啟動項目，為 Spring Cloud 提供開箱即用的依賴管理。