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

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的開(kāi)發(fā)便利性巧妙地簡(jiǎn)化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開(kāi)發(fā)，如服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用 Spring Boot 的開(kāi)發(fā)風(fēng)格做到一鍵啟動(dòng)和部署。

Spring 并沒(méi)有重復(fù)制造輪子，它只是將目前各家公司(主要是 Netflix )開(kāi)發(fā)的比較成熟、經(jīng)得起實(shí)際考驗(yàn)的服務(wù)框架組合起來(lái)，通過(guò) Spring Boot 風(fēng)格進(jìn)行再封裝屏蔽掉了復(fù)雜的配置和實(shí)現(xiàn)原理，最終給開(kāi)發(fā)者留出了一套簡(jiǎn)單易懂、易部署和易維護(hù)的分布式系統(tǒng)開(kāi)發(fā)工具包。

Spring Cloud 的核心組件

1. Eureka（注冊(cè)中心）

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

• Eureka 服務(wù)端：也稱服務(wù)注冊(cè)中心，同其他服務(wù)注冊(cè)中心一樣，支持高可用配置。如果 Eureka 以集群模式部署，當(dāng)集群中有分片出現(xiàn)故障時(shí)，那么 Eureka 就轉(zhuǎn)入自我保護(hù)模式。它允許在分片故障期間繼續(xù)提供服務(wù)的發(fā)現(xiàn)和注冊(cè)，當(dāng)故障分片恢復(fù)運(yùn)行時(shí)，集群中其他分片會(huì)把它們的狀態(tài)再次同步回來(lái)

• Eureka 客戶端：主要處理服務(wù)的注冊(cè)與發(fā)現(xiàn)。客戶端服務(wù)通過(guò)注解和參數(shù)配置的方式，嵌入在客戶端應(yīng)用程序的代碼中，在應(yīng)用程序運(yùn)行時(shí)，Eureka 客戶端想注冊(cè)中心注冊(cè)自身提供的服務(wù)并周期性地發(fā)送心跳來(lái)更新它的服務(wù)租約。同時(shí)，它也能從服務(wù)端查詢當(dāng)前注冊(cè)的服務(wù)信息并把它們緩存到本地并周期性地刷新服務(wù)狀態(tài)

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

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

Zuul 網(wǎng)關(guān)負(fù)責(zé)轉(zhuǎn)發(fā)請(qǐng)求給對(duì)應(yīng)的服務(wù)，這個(gè)組件是負(fù)責(zé)網(wǎng)絡(luò)路由的。

Spring Cloud Zuul 通過(guò)與 Spring Cloud Eureka 進(jìn)行整合，將自身注冊(cè)為 Eureka 服務(wù)治理下的應(yīng)用，同時(shí)從 Eureka 中獲得了所有其他微服務(wù)的實(shí)例信息

對(duì)于路由規(guī)則的維護(hù)，Zuul 默認(rèn)會(huì)將通過(guò)以服務(wù)名作為 ContextPath 的方式來(lái)創(chuàng)建路由映射

Zuul 提供了一套過(guò)濾器機(jī)制，可以支持在 API 網(wǎng)關(guān)無(wú)附上進(jìn)行統(tǒng)一調(diào)用來(lái)對(duì)微服務(wù)接口做前置過(guò)濾，已實(shí)現(xiàn)對(duì)微服務(wù)接口的攔截和校驗(yàn)

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

提供云端負(fù)載均衡，有多種負(fù)載均衡策略可供選擇，可配合服務(wù)發(fā)現(xiàn)和斷路器使用。

Ribbon 是一個(gè)基于 HTTP 和 TCP 的客戶端負(fù)載均衡器，它可以在通過(guò)客戶端中配置的 ribbonServerList 服務(wù)端列表去輪詢?cè)L問(wèn)以達(dá)到服務(wù)均衡的作用。

當(dāng) Ribbon 和 Eureka 聯(lián)合使用時(shí)，Ribbon 的服務(wù)實(shí)例清單 RibbonServerList 會(huì)被 DiscoveryEnabledNIWSServerList 重寫，擴(kuò)展成從 Eureka 注冊(cè)中心中獲取服務(wù)端列表。同時(shí)它也會(huì)用 NIWSDiscoveryPing 來(lái)取代 IPing，它將職責(zé)委托給 Eureka 來(lái)去定服務(wù)端是否已經(jīng)啟動(dòng)

在客戶端負(fù)載均衡中，所有客戶端節(jié)點(diǎn)都維護(hù)著自己要訪問(wèn)的服務(wù)端清單，而這些服務(wù)端的清單來(lái)自于服務(wù)注冊(cè)中心（比如 Eureka）。在客戶端負(fù)載均衡中也需要心跳去維護(hù)服務(wù)端清單的健康性，只是這個(gè)步驟需要與服務(wù)注冊(cè)中心配合完成。

通過(guò) Spring Cloud Ribbon 的封裝，我們?cè)谖⒎?wù)架構(gòu)中使用客戶端負(fù)載均衡調(diào)用只需要如下兩步：

• 服務(wù)提供者只需要啟動(dòng)多個(gè)服務(wù)實(shí)例并且注冊(cè)到一個(gè)注冊(cè)中心或是多個(gè)相關(guān)聯(lián)的服務(wù)注冊(cè)中心

• 服務(wù)消費(fèi)者直接通過(guò)調(diào)用被 @LoadBalanced 注解修飾過(guò)的 RestTemplate 來(lái)實(shí)現(xiàn)面向服務(wù)的接口調(diào)用

4. Hystrix（熔斷保護(hù)器）

熔斷器，容錯(cuò)管理工具，旨在通過(guò)熔斷機(jī)制控制服務(wù)和第三方庫(kù)的節(jié)點(diǎn),從而對(duì)延遲和故障提供更強(qiáng)大的容錯(cuò)能力。提供線程池不同的服務(wù)走不同的線程池，實(shí)現(xiàn)了不同服務(wù)調(diào)用的隔離，避免了服務(wù)器雪崩的問(wèn)題。

在微服務(wù)架構(gòu)中，存在著那么多的服務(wù)單元，若一個(gè)單元出現(xiàn)故障，就很容易因依賴關(guān)系而引發(fā)故障的蔓延，最終導(dǎo)致整個(gè)系統(tǒng)的癱瘓，這樣的架構(gòu)相較傳統(tǒng)架構(gòu)更加不穩(wěn)定。為了解決這樣的問(wèn)題，產(chǎn)生了斷路器等一系列的服務(wù)保護(hù)機(jī)制

在分布式架構(gòu)中，當(dāng)某個(gè)服務(wù)單元發(fā)生故障之后，通過(guò)斷路器的故障監(jiān)控，向調(diào)用方返回一個(gè)錯(cuò)誤響應(yīng)，而不是長(zhǎng)時(shí)間的等待。這樣就不會(huì)使得線程因調(diào)用故障服務(wù)被長(zhǎng)時(shí)間占用不釋放，避免了故障在分布式系統(tǒng)中的蔓延

Hystrix 具備服務(wù)降級(jí)、服務(wù)熔斷、線程和信號(hào)隔離、請(qǐng)求緩存、請(qǐng)求合并以及服務(wù)監(jiān)控等強(qiáng)大功能

Hystrix 使用艙壁模式實(shí)現(xiàn)線程池的隔離，它會(huì)為每一個(gè)依賴服務(wù)創(chuàng)建一個(gè)獨(dú)立的線程池，這樣就算某個(gè)依賴服務(wù)出現(xiàn)延遲過(guò)高的情況，也只是對(duì)該依賴服務(wù)的調(diào)用產(chǎn)生影響，而不會(huì)拖慢其他的依賴服務(wù)

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

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

• 首先，對(duì)某個(gè)接口定義了 @FeignClient 注解，F(xiàn)eign 就會(huì)針對(duì)這個(gè)接口創(chuàng)建一個(gè)動(dòng)態(tài)代理

• 接著調(diào)用接口的時(shí)候，本質(zhì)就是調(diào)用 Feign 創(chuàng)建的動(dòng)態(tài)代理

• Feign 的動(dòng)態(tài)代理會(huì)根據(jù)在接口上的 @RequestMapping 等注解，來(lái)動(dòng)態(tài)構(gòu)造要請(qǐng)求的服務(wù)的地址

• 針對(duì)這個(gè)地址，發(fā)起請(qǐng)求、解析響應(yīng)

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

• 首先 Ribbon 會(huì)從 Eureka Client 里獲取到對(duì)應(yīng)的服務(wù)注冊(cè)表，也就知道了所有的服務(wù)都部署在了哪些機(jī)器上，在監(jiān)聽(tīng)哪些端口

• 然后 Ribbon 就可以使用默認(rèn)的 Round Robin 算法，從中選擇一臺(tái)機(jī)器

• Feign 就會(huì)針對(duì)這臺(tái)機(jī)器，構(gòu)造并發(fā)起請(qǐng)求

6. Config（分布式配置）

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

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

微服務(wù)網(wǎng)關(guān)更多是在前后端分離，或者說(shuō)涉及到獨(dú)立的類似手機(jī) APP 等前端應(yīng)用的時(shí)候使用的最多，即把內(nèi)部各個(gè)微服務(wù)組件模塊的 API 接口能力統(tǒng)一注冊(cè)和接入到網(wǎng)關(guān)，對(duì)于 APP 也只需要訪問(wèn)網(wǎng)關(guān)暴露的接口即可，同時(shí)通過(guò)網(wǎng)關(guān)還可以進(jìn)一步的實(shí)現(xiàn)安全隔離。

也就是說(shuō)在這種場(chǎng)景下，網(wǎng)關(guān)更多的是實(shí)現(xiàn)了接口服務(wù)的代理和路由轉(zhuǎn)發(fā)能力，更多的是向外的一種能力發(fā)布。

1. 一個(gè)獨(dú)立的開(kāi)發(fā)團(tuán)隊(duì)，為保證獨(dú)立自治，以及內(nèi)部多個(gè)微服務(wù)模塊間的交互集成，最好啟用獨(dú)立的服務(wù)注冊(cè)中心實(shí)現(xiàn)服務(wù)注冊(cè)，發(fā)現(xiàn)能力。即開(kāi)發(fā)團(tuán)隊(duì)內(nèi)部多個(gè)微服務(wù)模塊間的集成，不需要通過(guò)網(wǎng)關(guān)，只需要通過(guò)服務(wù)注冊(cè)中心進(jìn)行集成即可。

2. 開(kāi)發(fā)團(tuán)隊(duì)需要暴露能力給外部，包括暴露能力給其它的開(kāi)發(fā)團(tuán)隊(duì)，需要考慮將該 API 接口注冊(cè)到外部的網(wǎng)關(guān)上。在這里建議是拆分兩個(gè)獨(dú)立網(wǎng)關(guān)，一個(gè)是內(nèi)部 API 網(wǎng)關(guān)，一個(gè)是放置到 DMZ 區(qū)面對(duì)公網(wǎng)訪問(wèn)的 API 網(wǎng)關(guān)。對(duì)于服務(wù)如果同時(shí)涉及到內(nèi)部和外部使用，則兩邊注冊(cè)。建議不要通過(guò)兩次網(wǎng)關(guān)去路由，一個(gè)是影響性能，一個(gè)是不方便后續(xù)問(wèn)題排查。

3. 構(gòu)建在開(kāi)發(fā)團(tuán)隊(duì)之外的 API 網(wǎng)關(guān)必須具備負(fù)載均衡能力，可以配置多個(gè) IP 地址。通過(guò)該 API 網(wǎng)關(guān)也最好具備和 Docker 容器擴(kuò)展后的服務(wù)自動(dòng)注冊(cè)和地址加入擴(kuò)展能力。

Eureka 的競(jìng)品分析：Nacos、ZooKeeper、Etcd

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

Eureka

• Spring Cloud Eureka 所選擇的是 AP，采用的是去中心化結(jié)構(gòu)，放棄了強(qiáng)一致性。也就是說(shuō) Eureka 集群中的各個(gè)結(jié)點(diǎn)都是平等的，沒(méi)有主從的概念。通過(guò)互相注冊(cè)的方式來(lái)進(jìn)行消息同步和保證高可用。并且一個(gè) Eureka Server 結(jié)點(diǎn)掛掉了，還有其他同等的結(jié)點(diǎn)來(lái)提供服務(wù)，并不會(huì)引發(fā)服務(wù)的中斷

• Eureka 只能當(dāng)注冊(cè)中心，想搞配置中心的話，還得搭配 Spring Cloud Config+Spring Cloud Bus。其中后者支持 Rabbiimq 和 Kafka 兩種模式。

• 使用 Java 語(yǔ)言來(lái)開(kāi)發(fā)的，并且也是 Spring Cloud 的子項(xiàng)目，所以可以直接通過(guò)引入 jar 包的方式來(lái)集成 Eureka，這點(diǎn)非常方便

1. ZooKeeper

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

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

• 為了達(dá)到 C，Zookeeper 采用的是自己的 ZAB 協(xié)議。

2. Nacos

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

• Nacos 一大特性是即支持 CP，也支持 AP?？梢愿鶕?jù)需要靈活選擇。

• Nacos 除了注冊(cè)中心之外，也能充當(dāng)配置中心的作用。且配置中心可以按照 namespace，group 等維度來(lái)進(jìn)行數(shù)據(jù)隔離，來(lái)達(dá)到不同環(huán)境之間配置隔離的功能。

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

3. Consul

Consul 是 HashiCorp 公司推出的一個(gè)開(kāi)源工具。

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

• 除了注冊(cè)中心的功能之外，Consul 還能起到配置中心的作用。

  Consul 它保證的是 CP，使用 raft 協(xié)議，要求必須有過(guò)半的結(jié)點(diǎn)都寫入成功才算是注冊(cè)成功了，并且它也有 Master 和 Follower 的概念，在 Master 掛掉后，也需要自己內(nèi)部進(jìn)行

4. Etcd（待續(xù)）

對(duì)比 SpringCloud，Kubernetes 也提供完整的分布式微服務(wù)管理框架，幾乎所有組件都有對(duì)應(yīng)的產(chǎn)品，其中 Etcd 也可以提供類似 Eureka 的注冊(cè)中心。

在 Go 生態(tài)中，還可以選擇基于 Etcd 作為注冊(cè)中心，Etcd 是由 CoreOS 團(tuán)隊(duì)維護(hù)的、高可用分布式鍵值存儲(chǔ)數(shù)據(jù)庫(kù)，可用于為集群提供配置和服務(wù)發(fā)現(xiàn)功能，Google 開(kāi)源的容器管理工具 Kuberbetes 就是基于 Etcd 的。

和 Consul 一樣，Etcd 也是基于 Raft 協(xié)議作為分布式一致性算法來(lái)解決領(lǐng)導(dǎo)者選舉和日志復(fù)制問(wèn)題，同樣也是基于 Go 語(yǔ)言編寫。

Etcd 也支持代理模式（proxy），只不過(guò)在 Etcd 中，代理模式和 Consul 的客戶端代理模式類似，安裝在部署服務(wù)的節(jié)點(diǎn)上，用來(lái)轉(zhuǎn)發(fā)請(qǐng)求到 Etcd 集群，本身不存儲(chǔ)任何數(shù)據(jù)，Etcd 集群相當(dāng)于 Consul 中以服務(wù)端模式運(yùn)行的 Consul 集群，通常要求配置三個(gè)及以上節(jié)點(diǎn)（不要太多，3~5 就夠了，以便可用性和性能上達(dá)到平衡），負(fù)責(zé)真正的請(qǐng)求處理 —— 服務(wù)注冊(cè)與發(fā)現(xiàn)。

在目前最新版本的 Etcd v3 中，通過(guò)網(wǎng)關(guān)模式（gateway）取代了 V2 版本中的代理模式（proxy）。

從服務(wù)發(fā)現(xiàn)的實(shí)現(xiàn)原理上來(lái)說(shuō)，Consul 和 Etcd 的基本設(shè)計(jì)思路是一致的，Etcd 更簡(jiǎn)單，Consul 則更像一個(gè)全棧的解決方案，功能比 Etcd 要更豐富，比如支持可視化的 Web UI 管理界面、支持多數(shù)據(jù)庫(kù)中心、安全層面除了 HTTPS 外還支持 ACL、更加全面的健康檢查功能、內(nèi)置 DNS Server 等，這些都是 Etcd 所不具備的，但是更全面的功能往往意味著更高的復(fù)雜性，針對(duì)微服務(wù)的服務(wù)注冊(cè)和發(fā)現(xiàn)場(chǎng)景，Etcd 完全夠用了。

Spring Cloud 全家桶的簡(jiǎn)介

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

• Spring Cloud Bus：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態(tài)變化，可與 Spring Cloud Config 聯(lián)合實(shí)現(xiàn)熱部署。

• Eureka：云端服務(wù)發(fā)現(xiàn)，一個(gè)基于 REST 的服務(wù)，用于定位服務(wù)，以實(shí)現(xiàn)云端中間層服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移。

• Hystrix：熔斷器，容錯(cuò)管理工具，旨在通過(guò)熔斷機(jī)制控制服務(wù)和第三方庫(kù)的節(jié)點(diǎn),從而對(duì)延遲和故障提供更強(qiáng)大的容錯(cuò)能力。

• Zuul：Zuul 是在云平臺(tái)上提供動(dòng)態(tài)路由,監(jiān)控,彈性,安全等邊緣服務(wù)的框架。Zuul 相當(dāng)于是設(shè)備和 Netflix 流應(yīng)用的 Web 網(wǎng)站后端所有請(qǐng)求的前門。

• Archaius：配置管理 API，包含一系列配置管理 API，提供動(dòng)態(tài)類型化屬性、線程安全配置操作、輪詢框架、回調(diào)機(jī)制等功能。

• Consul：封裝了 Consul 操作，Consul 是一個(gè)服務(wù)發(fā)現(xiàn)與配置工具，與 Docker 容器可以無(wú)縫集成。

• Spring Cloud for Cloud Foundry：通過(guò) Oauth2 協(xié)議綁定服務(wù)到 CloudFoundry，CloudFoundry 是 VMware 推出的開(kāi)源 PaaS 云平臺(tái)。

• Spring Cloud Sleuth：日志收集工具包，封裝了 Dapper 和 log-based 追蹤以及 Zipkin 和 HTrace 操作，為 Spring Cloud 應(yīng)用實(shí)現(xiàn)了一種分布式追蹤解決方案。

• Spring Cloud Data Flow：大數(shù)據(jù)操作工具，作為 Spring XD 的替代產(chǎn)品，它是一個(gè)混合計(jì)算模型，結(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ù)流操作開(kāi)發(fā)包，封裝了與 Redis、Rabbit、Kafka 等發(fā)送接收消息。

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

• Ribbon：提供云端負(fù)載均衡，有多種負(fù)載均衡策略可供選擇，可配合服務(wù)發(fā)現(xiàn)和斷路器使用。

• Turbine：Turbine 是聚合服務(wù)器發(fā)送事件流數(shù)據(jù)的一個(gè)工具，用來(lái)監(jiān)控集群下 Hystrix 的 Metrics 情況。

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

• Spring Cloud Task：提供云端計(jì)劃任務(wù)管理、任務(wù)調(diào)度。

• Spring Cloud Connectors：便于云端應(yīng)用程序在各種 PaaS 平臺(tái)連接到后端，如：數(shù)據(jù)庫(kù)和消息代理服務(wù)。

• Spring Cloud Cluster：提供 Leadership 選舉，如：Zookeeper，Redis，Hazelcast，Consul 等常見(jiàn)狀態(tài)模式的抽象和實(shí)現(xiàn)。

• Spring Cloud Starters：Spring Boot 式的啟動(dòng)項(xiàng)目，為 Spring Cloud 提供開(kāi)箱即用的依賴管理。

本書(shū)適合具有一定 Java 基礎(chǔ)和 Spring MVC 基礎(chǔ)的人群以及希望往架構(gòu)師方向發(fā)展的開(kāi)發(fā)者閱讀。

書(shū)籍教程結(jié)構(gòu)

本書(shū)共分四部分，從基礎(chǔ)到實(shí)戰(zhàn)，講解了基于 Spring Cloud 的常用組件。

第一部分(基礎(chǔ)篇):第 1~4 章

第二部分(實(shí)戰(zhàn)篇):第 5~10 章

第三部分(高級(jí)篇):第 11~13 章

第四部分(部署篇):第 14~15 章

第一部分(基礎(chǔ)篇)

第 1 章微服務(wù)概述

我們要學(xué)習(xí)微服務(wù)架構(gòu)，就要了解它，本章將帶領(lǐng)大家初步了解微服務(wù)，為后面系統(tǒng)學(xué)習(xí)微服務(wù)架構(gòu)奠定良好的基礎(chǔ)。

第 2 章 Spring Boot 基礎(chǔ)

本書(shū)以實(shí)戰(zhàn)為導(dǎo)向，講解了如何使用 Spring Cloud 開(kāi)發(fā)微服務(wù)項(xiàng)目，而 Spring Cloud 基于 SpringBoot,所以本章先來(lái)初步了解如何使用 Spring Boot 搭建框架。

第 3 章 Spring Boot 核心原理

通過(guò)第 2 章的學(xué)習(xí)，讀者應(yīng)該對(duì) Spring Boot 有了一個(gè)大致的認(rèn)識(shí)，利用 Spring Boot 可以極大地簡(jiǎn)化應(yīng)用程序的開(kāi)發(fā)，這都?xì)w功于 Spring Boot 的四大核心原理:起步依賴、自動(dòng)配置、Actuator 和 Spring Boot 命令行。本章中，我們將深入探討 Spring Boot 的核心原理，以便讀者能更好地學(xué)習(xí)和使用 Spring Boot。

第 4 章 Spring Cloud 概述

從本章開(kāi)始，我們將正式踏上探索 Spring Cloud 秘密的旅程。學(xué)完本書(shū)后，讀者將學(xué)會(huì)搭建一個(gè)完整的分布式架構(gòu)，從而向架構(gòu)師的目標(biāo)靠近。

第二部分(實(shí)戰(zhàn)篇)

資料已經(jīng)準(zhǔn)備好了需要資料的伙伴們點(diǎn)擊資料獲取方式 即可獲取

第 5 章 項(xiàng)目準(zhǔn)備階段

本章中，我 將開(kāi)始 個(gè)大型實(shí)戰(zhàn)項(xiàng)目一一博客網(wǎng)站。通過(guò)“以戰(zhàn)代練”的方式來(lái)學(xué)習(xí)如何構(gòu)建 Spring loud 微服務(wù)架構(gòu)，讓讀者走出理論的叢林，在實(shí)踐中玩轉(zhuǎn)微服務(wù)架構(gòu)。

第 6 章 公共模塊封裝

從本章開(kāi)始，我們將學(xué)習(xí)框架的搭建。由于代碼量巨大，本書(shū)不可能全部貼出，所以只展示一些核心代碼。全部源碼可以從本書(shū)配套源碼中查看。

第 7 章 注冊(cè)中心: Spring Cloud Netflix Eureka

通過(guò)前面的學(xué)習(xí)，我們可以總結(jié)出來(lái)，注冊(cè)中心是整套微服務(wù)架構(gòu)的核心，即系統(tǒng)的心臟，它能夠幫助我們管理所有的微服務(wù)，精確定位到具體的服務(wù)就是通過(guò)注冊(cè)中心來(lái)實(shí)現(xiàn)的。構(gòu)建注冊(cè)中心的好處也是不言而喻的，通過(guò)注冊(cè)中心，我們可以實(shí)現(xiàn)服務(wù)的負(fù)載均衡。配置的統(tǒng)-管理。服務(wù)間的通信等。目前。我們可以采用多種技術(shù)實(shí)現(xiàn)注冊(cè)中心，如 Eureka. ZooKeeper. Consul 等，本書(shū)采用 SpringCloud 默認(rèn)集成的 Eureka 框架來(lái)構(gòu)建注冊(cè)中心。

第 8 章 配置中心: Spring Cloud Config

我們知道，一個(gè)微服務(wù)系統(tǒng)可能由成千上萬(wàn)的服務(wù)組成，每個(gè)服務(wù)都會(huì)有自己的配置，不同服務(wù)之間的有些配置是相同的，比如數(shù)據(jù)庫(kù)。如果對(duì)于每個(gè)服務(wù)，我們都復(fù)制相同的配置，一旦該配置發(fā)生了變化，那么每個(gè)服務(wù)都需要修改，代價(jià)可想而知。Spring Cloud 已經(jīng)考慮到了這一點(diǎn), 它為我們提供了一整套解決方案， 那就是強(qiáng)大的 Spring CloudConfig。

第 9 章 服務(wù)網(wǎng)關(guān): Spring Cloud Gateway

本將介紹的微服務(wù)的又一大組件一一服務(wù)網(wǎng)關(guān)。我們需要服務(wù)網(wǎng)關(guān)，還有一些很重要的因素，比如服務(wù)網(wǎng)關(guān)會(huì)對(duì)接口進(jìn)行統(tǒng)一攔截并做合法性校驗(yàn)，一個(gè)服務(wù)可以啟動(dòng)多個(gè)端口，利用服務(wù)網(wǎng)關(guān)進(jìn)行負(fù)載均衡處理等。目前市面上有很多產(chǎn)品可以實(shí)現(xiàn)服務(wù)網(wǎng)關(guān)這一功能， 如 Nginx. Apache. Zuul 以及 Spring CloudGateway 等。Spring Cloud 集成了 Zuul 和 Gateway,我們可以很方便地實(shí)現(xiàn)服務(wù)網(wǎng)關(guān)這一功能。

第 10 章 功能開(kāi)發(fā)

通過(guò)前幾章的學(xué)習(xí)，我們已經(jīng)搭建好了博客網(wǎng)站的基本框架。本章我們將正式開(kāi)始網(wǎng)站的功能開(kāi)發(fā)。

第三部分(高級(jí)篇)

SpringCloud 實(shí)戰(zhàn)演練文檔 K8S+實(shí)戰(zhàn)+筆記+項(xiàng)目教程轉(zhuǎn)發(fā)+評(píng)論，關(guān)注我私信回復(fù)"筆記"即可免費(fèi)獲取

第 11 章 服務(wù)間通信: Spring Cloud Netflix Ribbon 和 Spring Cloud OpenFeign

一個(gè)大型的 系統(tǒng)由多個(gè)微服務(wù)模塊組成，我們一-般 可以通過(guò)內(nèi)部接口調(diào)用的形式(服務(wù) A 提供一個(gè)接口，服務(wù) B 通過(guò) HTTP 請(qǐng)求調(diào)用服務(wù) A 的接口)實(shí)現(xiàn)各模塊之間的通信。為了簡(jiǎn)化開(kāi)發(fā)，SpringCloud 集成了 Spring Cloud Netlix Ribbon 和 Spring Cloud OpenFeign,兩個(gè)組件都支持通過(guò) HTTP 請(qǐng)求不同的服務(wù)。本書(shū)將簡(jiǎn)要介紹 Spring Cloud Netflix Ribbon,借此引出 Sping Cloud OpenFeign,并詳細(xì)介紹其用法。

第 12 章 服務(wù)鏈路追蹤: Spring Cloud Sleuth

我們知道,微服務(wù)之間通過(guò)網(wǎng)絡(luò)進(jìn)行通信,但在我們提供服務(wù)的同時(shí),不能保證網(wǎng)絡(luò)一定是暢通的。相反地，網(wǎng)絡(luò)是很脆弱的，網(wǎng)絡(luò)資源也有限，因此我們有必要追蹤每個(gè)網(wǎng)絡(luò)請(qǐng)求，了解它們經(jīng)過(guò)了哪些微服務(wù)，延遲多少，每個(gè)請(qǐng)求所耗費(fèi)的時(shí)間等。只有這樣才能更好地分析系統(tǒng)瓶頸，解決系統(tǒng)問(wèn)題。在 Spring Cloud 中，我們可以使用 Spring Cloud Sleuth 組件來(lái)實(shí)現(xiàn)微服務(wù)追蹤。

第 13 章 服務(wù)治理: Spring Cloud Consul 和 Spring Cloud ZooKeeper

在前面的章節(jié)中，讀者已經(jīng)接觸到了 Spring Cloud 默認(rèn)集成的服務(wù)治理框架 Spring Cloud NettlixEureka。在本章，我們將接觸到新的服務(wù)治理框架，以便讀者在實(shí)際應(yīng)用中有多種選擇。

第四部分(部署篇)

第 14 章系統(tǒng)發(fā)布上線

通過(guò)前幾章的學(xué)習(xí)，我們順利完成了應(yīng)用的開(kāi)發(fā)，僅僅完成框架搭建和功能開(kāi)發(fā)是不夠的，我們還需要將應(yīng)用發(fā)布到服務(wù)器上供客戶端訪問(wèn)。本章中，我們將開(kāi)始詳解應(yīng)用的發(fā)布。

第 15 章使用 Kubernetes 部署分布式集群

容器技術(shù)的出現(xiàn)帶給了我們新的思路。我們可以將服務(wù)打包成鏡像，放到容器中，通過(guò)容器來(lái)運(yùn)行服務(wù)，這樣可以很方便地進(jìn)行分布式管理，同樣的服務(wù)也可以很方便地進(jìn)行水平擴(kuò)展。Docker 是容器技術(shù)方面的佼佼者，它是一-個(gè)開(kāi)源容器，而 Kubernetes (以下簡(jiǎn)稱 K8S)是一個(gè)分布式集群方案的平臺(tái)，它和 Docker 就是天生的一對(duì)。 通過(guò) K8S 和 Docker 的配合，我們很容易搭建分布式集群環(huán)境。下面，我們就來(lái)看一下 Docker 和 K8S 的誘人之處。

好了，由于篇幅問(wèn)題就不多展示了，資料已經(jīng)準(zhǔn)備好了需要資料的伙伴們點(diǎn)擊資料獲取方式 即可?