Spring Cloud是一個相對比較新的微服務框架，2016年才推出1.0的release版本 。雖然Spring Cloud時間最短，但是相比Dubbo等RPC框架，Spring Cloud提供的全套的分布式系統(tǒng)解決方案 。Spring Cloud是一系列框架的有序集合 。它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎設施的開發(fā)，如服務發(fā)現(xiàn)注冊、配置中心、消息總線、負載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開發(fā)風格做到一鍵啟動和部署 。Spring并沒有重復制造輪子，它只是將目前各家公司（主要是Netflix）開發(fā)的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包 。
Spring Cloud 的核心組件Eureka（注冊中心）Eureka是Spring Cloud微服務架構中的注冊中心，專門負責服務的注冊與發(fā)現(xiàn),里面有一個注冊表，保存了各個服務器的機器和端口 。
- Eureka服務端：也稱服務注冊中心，同其他服務注冊中心一樣，支持高可用配置 。如果Eureka以集群模式部署，當集群中有分片出現(xiàn)故障時，那么Eureka就轉入自我保護模式 。它允許在分片故障期間繼續(xù)提供服務的發(fā)現(xiàn)和注冊，當故障分片恢復運行時，集群中其他分片會把它們的狀態(tài)再次同步回來 。
- Eureka客戶端：主要處理服務的注冊與發(fā)現(xiàn) ?？蛻舳朔胀ㄟ^注解和參數(shù)配置的方式，嵌入在客戶端應用程序的代碼中，在應用程序運行時，Eureka客戶端想注冊中心注冊自身提供的服務并周期性地發(fā)送心跳來更新它的服務租約 。同時，它也能從服務端查詢當前注冊的服務信息并把它們緩存到本地并周期性地刷新服務狀態(tài) 。
Zuul（服務網(wǎng)關）Zuul網(wǎng)關負責轉發(fā)請求給對應的服務，這個組件是負責網(wǎng)絡路由的 。Spring Cloud Zuul通過與Spring Cloud Eureka進行整合，將自身注冊為Eureka服務治理下的應用，同時從Eureka中獲得了所有其他微服務的實例信息 。對于路由規(guī)則的維護，Zuul默認會將通過以服務名作為ContextPath的方式來創(chuàng)建路由映射 。Zuul提供了一套過濾器機制，可以支持在API網(wǎng)關無附上進行統(tǒng)一調用來對微服務接口做前置過濾，已實現(xiàn)對微服務接口的攔截和校驗 。
Ribbon（負載均衡）提供云端負載均衡，有多種負載均衡策略可供選擇，可配合服務發(fā)現(xiàn)和斷路器使用 。Ribbon是一個基于HTTP和TCP的客戶端負載均衡器，它可以在通過客戶端中配置的ribbonServerList服務端列表去輪詢訪問以達到服務均衡的作用 。當Ribbon和Eureka聯(lián)合使用時，Ribbon的服務實例清單RibbonServerList會被DiscoveryEnabledNIWSServerList重寫，擴展成從Eureka注冊中心中獲取服務端列表 。同時它也會用NIWSDiscoveryPing來取代IPing，它將職責委托給Eureka來去定服務端是否已經啟動 。在客戶端負載均衡中，所有客戶端節(jié)點都維護著自己要訪問的服務端清單，而這些服務端的清單來自于服務注冊中心（比如Eureka） 。在客戶端負載均衡中也需要心跳去維護服務端清單的健康性，只是這個步驟需要與服務注冊中心配合完成 。通過Spring Cloud 百思特網(wǎng)Ribbon的封裝，我們在微服務架構中使用客戶端負載均衡調用只需要如下兩步：
- 服務提供者只需要啟動多個服務實例并且注冊到一個注冊中心或是多個相關聯(lián)的服務注冊中心 。
- 服務消費者直接通過調用被@LoadBalanced注解修飾過的RestTemplate來實現(xiàn)面向服務的接口調用 。
Hystrix（熔斷保護器）熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力 。提供線程池不同的服務走不同的線程池，實現(xiàn)了不同服務調用的隔離，避免了服務器雪崩的問題 。在微服務架構中，存在著那么多的服務單元，若一個單元出現(xiàn)故障，就很容易因依賴關系而引發(fā)故障的蔓延，最終導致整個系統(tǒng)的癱瘓，這樣的架構相較傳統(tǒng)架構更加不穩(wěn)定 。為了解決這樣的問題，產生了斷路器等一系列的服務保護機制 。在分布式架構中，當某個服務單元發(fā)生故障之后，通過斷路器的故障監(jiān)控，向調用方返回一個錯誤響應，而不是長時間的等待 。這樣就不會使得線程因調用故障服務被長時間占用不釋放，避免了故障在分布式系統(tǒng)中的蔓延 。Hystrix具備服務降級、服務熔斷、線程和信號隔離、請求緩存、請求合并以及服務監(jiān)控等強大功能 。Hystrix使用艙壁模式實現(xiàn)線程池的隔離，它會為每一個依賴服務創(chuàng)建一個獨立的線程池，這樣就算某個依賴服務出現(xiàn)延遲過高的情況，也只是對該依賴服務的調用產生影響，而不會拖慢其他的依賴服務 。
Feign（REST轉換器）基于動態(tài)代理機制，根據(jù)注解和選擇的機器，拼接請求url地址，發(fā)起請求 。Feign的關鍵機制是使用了動態(tài)代理：
- 首先，對某個接口定義了@FeignClient注解，F(xiàn)eign就會針對這個接口創(chuàng)建一個動態(tài)代理；
- 接著調用接口的時候，本質就是調用Feign創(chuàng)建的動態(tài)代理；
- Feign的動態(tài)代理會根據(jù)在接口上的@RequestMapping等注解，來動態(tài)構造要請求的服務的地址；
- 針對這個地址，發(fā)起請求、解析響應 。
- 首先Ribbon會從Eureka Client里獲取到對應的服務注冊表，也就知道了所有的服務都部署在了哪些機器上，在監(jiān)聽哪些端口；
- 然后Ribbon就可以使用默認的Round Robin算法，從中選擇一臺機器；
- Feign就會針對這臺機器，構造并發(fā)起請求 。
Config（分布式配置）配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集群配置，目前支持本地存儲、Git以及Subversion 。
注冊中心與API網(wǎng)關的分析微服務網(wǎng)關更多是在前后端分離，或者說涉及到獨立的類似手機APP等前端應用的時候使用的最多，即把內部各個微服務組件模塊的API接口能力統(tǒng)一注冊和接入到網(wǎng)關，對于APP也只需要訪問網(wǎng)關暴露的接口即可，同時通過網(wǎng)關還可以進一步的實現(xiàn)安全隔離 。也就是說在這種場景下，網(wǎng)關更多的是實現(xiàn)了接口服務的代理和路由轉發(fā)能力，更多的是向外的一種能力發(fā)布 。
- 一個獨立的開發(fā)團隊，為保證獨立自治，以及內部多個微服務模塊間的交互集成，最好啟用獨立的服務注冊中心實現(xiàn)服務注冊，發(fā)現(xiàn)能力 。即開發(fā)團隊內部多個微服務模塊間的集成，不需要通過網(wǎng)關，只需要通過服務注冊中心進行集成即可 。
- 開發(fā)團隊需要暴露能力給外部，包括暴露能力給其它的開發(fā)團隊，需要考慮將該API接口注冊到外部的網(wǎng)關上 。在這里建議是拆分兩個獨立網(wǎng)關，一個是內部API網(wǎng)關，一個是放置到DMZ區(qū)面對公網(wǎng)訪問的API網(wǎng)關 。對于服務如果同時涉及到內部和外部使用，則兩邊注冊 。建議不要通過兩次網(wǎng)關去路由，一個是影響性能，一個是不方便后續(xù)問題排查 。
- 構建在開發(fā)團隊之外的API網(wǎng)關必須具備負載均衡能力，可以配置多個IP地址 。通過該API網(wǎng)關也最好具備和Docker容器擴展后的服務自動注冊和地址加入擴展能力 。
Eureka 的競品分析：Nacos、ZooKeeper、etcd服務發(fā)現(xiàn)是一個古老的話題，當應用開始脫離單機運行和訪問時，服務發(fā)現(xiàn)就誕生了 。目前的網(wǎng)絡架構是每個主機都有一個獨立的IP地址，那么服務發(fā)現(xiàn)基本上都是通過某種方式獲取到服務所部署的IP地址 。DNS協(xié)議是最早將一個網(wǎng)絡名稱翻譯為網(wǎng)絡IP的協(xié)議，在最初的架構選型中，DNS LVS Nginx基本可以滿足所有的RESTful服務的發(fā)現(xiàn)，此時服務的IP列表通常配置在Nginx或者LVS 。后來出現(xiàn)了RPC服務，服務的上下線更加頻繁，人們開始尋求一種能夠支持動態(tài)上下線并且推送IP列表變化的注冊中心產品 。
Eureka
- Spring Cloud Eureka所選擇的是AP，采用的是去中心化結構，放棄了強一致性 。也就是說Eureka集群中的各個結點都是平等的，沒有主從的概念 。通過互相注冊的方式來進行消息同步和保證高可用 。并且一個Eureka Server結點掛掉了，還有其他同等的結點來提供服務，并不會引發(fā)服務的中斷 。
- Eureka只能當注冊中心，想搞配置中心的話，還得搭配Spring Cloud Config Spring Cloud Bus 。其中后者支持Rabbiimq和Kafka兩種模式 。
- 使用Java語言來開發(fā)的，并且也是Spring Cloud的子項目，所以可以直接通過引入jar包的方式來集成Eureka，這點非常方便 。
ZooKeeper這是一款經典的服務注冊中心產品（雖然它最初的定位并不在于此），在很長一段時間里，它是國人在提起RPC服務注冊中心時心里想到的唯一選擇，這很大程度上與Dubbo在中國的普及程度有關 。
- Apache Zookeeper所選擇的是CP，也就百思特網(wǎng)是放棄了高可用性 。Zookeeper集群在進行消息同步的時候，必須有一半以上結點完成了同步才會返回；而當Master結點掛了或者集群中有過半的結點不能工作了，此時就會觸發(fā)故障恢復，重新進行Master選舉 。在這個過程中，整個Zookeeper集群無法對外提供服務，從而實去了A（可用性） 。
- 為了達到C，Zookeeper采用的是自己的ZAB協(xié)議 。
- Nacos一大特性是即支持CP，也支持AP ?？梢愿鶕?jù)需要靈活選擇 。
- Nacos除了注冊中心之外，也能充當配置中心的作用 。且配置中心可以按照namespace，group等維度來進行數(shù)據(jù)隔離，來達到不同環(huán)境之間配置隔離的功能 。
ConsulConsul是HashiCorp公司推出的一個開源工具 。
- Consul是用Go語言編寫的，所以無法像Eureka那樣直接引入jar包就能集成，它還需要去服務器中進行額外的安裝 。
- 除了注冊中心的功能之外，Consul還能起到配置中心的作用 。Consul它保證的是CP，使用Raft協(xié)議，要求必須有過半的結點都寫入成功才算是注冊成功了，并且它也有Master和Follower的概念，在Master掛掉后，也需要自己內部進行 。
etcd（待續(xù)）對比Spring Cloud，Kubernetes也提供完整的分布式微服務管理框架，幾乎所有組件都有對應的產品，其中etcd也可以提供類似Eureka的注冊中心 。在Go生態(tài)中，還可以選擇基于etcd作為注冊中心，etcd是由CoreOS團隊維護的、高可用分布式鍵值存儲數(shù)據(jù)庫，可用于為集群提供配置和服務發(fā)現(xiàn)功能，Google開源的容器管理工具Kuberbetes就是基于etcd的 。和Consul一樣，etcd也是基于Raft協(xié)議作為分布式一致性算法來解決領導者選舉和日志復制問題，同樣也是基于Go語言編寫 。etcd也支持代理模式（Proxy），只不過在etcd中，代理模式和Consul的客戶端代理模式類似，安裝在部署服務的節(jié)點上，用來轉發(fā)請求到etcd集群，本身不存儲任何數(shù)據(jù)，etcd集群相當于Consul中以服務端模式運行的Consul集群，通常要求配置三個及以上節(jié)點（不要太多，3~5就夠了，以便可用性和性能上達到平衡），負責真正的請求處理——服務注冊與發(fā)現(xiàn) 。在目前最新版本的etcd v3中，通過網(wǎng)關模式（Gateway）取代了V2版本中的代理模式（Proxy） 。從服務發(fā)現(xiàn)的實現(xiàn)原理上來說，Consul和etcd的基本設計思路是一致的，etcd更簡單，Consul則更像一個全棧的解決方案，功能比etcd要更豐富，比如支持可視化的Web UI管理界面、支持多數(shù)據(jù)庫中心、安全層面除了HTTPS外還支持ACL、更加全面的健康檢查功能、內置DNS Server等，這些都是etcd所不具備的，但是更全面的功能往往意味著更高的復雜性，針對微服務的服務注冊和發(fā)現(xiàn)場景，etcd完全夠用了 。
Spring Cloud全家桶的簡介
- Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集群配置，目前支持本地存儲、Git以及Subversion 。
- Spring Cloud Bus：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態(tài)變化，可與Spring Cloud Config聯(lián)合實現(xiàn)熱部署 。
- Eureka：云端服務發(fā)現(xiàn)，一個基于REST的服務，用于定位服務，以實現(xiàn)云端中間層服務發(fā)現(xiàn)和故障轉移 。
- Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力 。
- Zuul：Zuul是在云平臺上提供動態(tài)路由，監(jiān)控，彈性，安全等邊緣服務的框架 。Zuul相當于是設備和Netflix流應用的Web網(wǎng)站后端所有請求的前門 。
- Archaius：配置管理API，包含一系列配置管理API，提供動態(tài)類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能 。
- Consul：封裝了Consul操作，Consul是一個服務發(fā)現(xiàn)與配置工具，與Docker容器可以無縫集成 。
- Spring Cloud for Cloud Foundry：通過Oauth2協(xié)議綁定服務到Cloud Foundry，Cloud Foundry是VMware推出的開源PaaS云平臺 。
- Spring Cloud Sleuth：日志收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作，為Spring Cloud應用實現(xiàn)了一種分布式追蹤解決方案 。
- Spring Cloud Data Flow：大數(shù)據(jù)操作工具，作為Spring XD的替代產品，它是一個混合計算模型，結合了流數(shù)據(jù)與批量數(shù)據(jù)的處理方式 。
- Spring Cloud Security：基于Spring Security的安全工具包，為你的應用程序添加安全控制 。
- Spring Cloud ZooKeeper：操作ZooKeeper的工具包，用于使用ZooKeeper方式的服務發(fā)現(xiàn)和配置管理 。
- Spring Cloud Stream：數(shù)據(jù)流操作開發(fā)包，封裝了與Redis、Rabbit、Kafka等發(fā)送接收消息 。
- Spring Cloud CLI：基于Spring Boot CLI，可以讓你以命令行方式快速建立云組件 。
- Ribbon：提供云端負載均衡，有多種負載均衡策略可供選擇，可配合服務發(fā)現(xiàn)和斷路器使用 。
- Turbine：Turbine是聚合服務器百思特網(wǎng)發(fā)送事件流數(shù)據(jù)的一個工具，用來監(jiān)控集群下Hystrix的Metrics情況 。
- Feign：Feign是一種聲明式、模板化的HTTP客戶端 。
- Spring Cloud Task：提供云端計劃任務管理、任務調度 。
- Spring Cloud Connectors：便于云端應用程序在各種PaaS平臺連接到后端，如：數(shù)據(jù)庫和消息代理服務 。
- Spring Cloud Cluster：提供Leadership選舉，如：ZooKeeper，Redis，Hazelcast，Consul等常見狀態(tài)模式的抽象和實現(xiàn) 。
- Spring Cloud Starters：Spring Boot式的啟動項目，為Spring Cloud提供開箱即用的依賴管理 。
推薦閱讀
- 中國最好的十大經典史書，你都讀過幾部？
- 世界上最貴的書多少錢：食典委萊斯特共72頁，價值3080美元
- 世界十大提高情商的書：《溝通的藝術》上榜
- 野生刺猬是保護動物嗎，人工養(yǎng)殖的刺猬是保護動物
- 人際交往必讀的十本書：《人性的弱點》上榜
- 十大重生小說前十名：《重生之賊行天下》第一名
- 十大靈異小說排行榜：《撞鈴》排第一，冤鬼路排第二
- 倭瓜是什么瓜
- 冰箱尺寸一般是多少