???在學(xué)習(xí)一個(gè)技術(shù)之前，首先我們要了解它是做什么的，我們?yōu)槭裁匆盟?。不然看再多資料都理解不了，因此我們先來講解下Spring Cloud

Spring Cloud是一套微服務(wù)治理框架，幾乎考慮到了微服務(wù)治理的方方面面。那么接下來具體說下 Spring Cloud在微服務(wù)框架中都起到了什么作用，提供了什么便利。

首先我們來看看互聯(lián)網(wǎng)架構(gòu)的發(fā)展過程：

傳統(tǒng)架構(gòu)發(fā)展史

單體架構(gòu)

單體結(jié)構(gòu)在微小企業(yè)比較常見，典型代表就是一個(gè)應(yīng)用，一個(gè)數(shù)據(jù)庫、一個(gè)Web就可以跑起來了

以下情況可能會(huì)選用單體架構(gòu)：

1.在企業(yè)發(fā)展初期，為了保證快速上線，采用此方案較為簡單靈活。

2.傳統(tǒng)企業(yè)中垂直度較高，訪問壓力小的業(yè)務(wù)。這種模式下對技術(shù)要求較低，方便各層次開發(fā)人員接手，也能滿足客戶需求。

單體架構(gòu)中，技術(shù)選型靈活，優(yōu)先滿足快速上線的要求

垂直架構(gòu)

在單體架構(gòu)發(fā)展一段時(shí)間后，公司的業(yè)務(wù)模式得到了認(rèn)可，交易量也慢慢的變大了，這時(shí)候企業(yè)為了應(yīng)對更大的流量，就會(huì)對原有業(yè)務(wù)進(jìn)行拆分，比如說：后臺(tái)系統(tǒng)，前端系統(tǒng)，交易系統(tǒng)等

在這個(gè)階段往往會(huì)將系統(tǒng)分為不同層級，每個(gè)層級有對應(yīng)的職責(zé)，UI層負(fù)責(zé)和用戶進(jìn)行交互，業(yè)務(wù)邏輯層負(fù)責(zé)具體業(yè)務(wù)功能，數(shù)據(jù)庫層負(fù)責(zé)和上層進(jìn)行數(shù)據(jù)交換和存儲(chǔ)

這個(gè)階段其實(shí)就是我們常說的三層，UI層、業(yè)務(wù)邏輯層、數(shù)據(jù)層

服務(wù)化架構(gòu)

隨著公司再進(jìn)一步的做大，垂直子系統(tǒng)會(huì)越來越多，系統(tǒng)和系統(tǒng)之間的調(diào)用關(guān)系不斷上升

這種情況下，很多公司都會(huì)考慮服務(wù)的SOA（Service Oriented Architecture）化。

SOA代表面向服務(wù)的架構(gòu)，將應(yīng)用程序按照不同的職責(zé)劃分為不同的模塊，不同的模塊直接通過特定的協(xié)議和接口進(jìn)行交互。

這樣將整個(gè)系統(tǒng)切分成很多單個(gè)組件服務(wù)來完成請求，當(dāng)流量過大時(shí)通過水平擴(kuò)展相應(yīng)的組件來支撐，所有組件通過交互來滿足整體的業(yè)務(wù)需求。

服務(wù)化架構(gòu)是一套松耦合的架構(gòu)，服務(wù)的拆分原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。

這個(gè)階段一般使用Web Service或者Dubbo來服務(wù)治理。

SOA和微服務(wù)的區(qū)別

服務(wù)化架構(gòu)已經(jīng)可以解決大部分企業(yè)的需求了，那么為什么我們還要研究微服務(wù)呢？

它們的區(qū)別有如下幾點(diǎn)：

1.微服務(wù)架構(gòu)強(qiáng)調(diào)業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化，一個(gè)組件就是一個(gè)產(chǎn)品，可以單獨(dú)對外提供服務(wù)

2.微服務(wù)不再強(qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重要的ESB企業(yè)服務(wù)總線

3.微服務(wù)強(qiáng)調(diào)每個(gè)微服務(wù)都有自己獨(dú)立的運(yùn)行空間，包括數(shù)據(jù)庫資源。

4.微服務(wù)架構(gòu)本身來源于互聯(lián)網(wǎng)的思路，因此組件對外發(fā)布的服務(wù)強(qiáng)調(diào)HTTP Rest API的方法進(jìn)行

5.微服務(wù)的切分粒度會(huì)更小。

總結(jié)：微服務(wù)架構(gòu)是SOA架構(gòu)思想的一種擴(kuò)展，更加強(qiáng)調(diào)服務(wù)個(gè)體的獨(dú)立性、拆分粒度更小

所以說了這么多，為什么用Spring Cloud呢？

因?yàn)镾pring Cloud不能說是微服務(wù)框架里最好的技術(shù)，也能說是最周全的技術(shù)了

Spring Cloud的特性

1.分布式/版本化配置

2.服務(wù)注冊和發(fā)現(xiàn)

3.路由

4.服務(wù)和服務(wù)之間的調(diào)用

5.負(fù)載均衡

6.斷路器

7.分布式消息傳遞

這些特性都是由不同的組件來完成

微服務(wù)架構(gòu)

Spring Cloud解決的第一個(gè)問題就是：服務(wù)與服務(wù)之間的解耦。公司在業(yè)務(wù)高速發(fā)展的同時(shí)，服務(wù)組件也會(huì)相應(yīng)的不斷增加。

服務(wù)和服務(wù)之間有著復(fù)雜的互相調(diào)用關(guān)系，經(jīng)常有服務(wù)A調(diào)用服務(wù)B，服務(wù)B調(diào)用服務(wù)C和服務(wù)D。。。。，隨著服務(wù)化組件越來越多，它們之間的調(diào)用關(guān)系也在成指數(shù)級別增長，極端情況下如下圖：

這樣最容易導(dǎo)致的情況就是牽一發(fā)而動(dòng)全身，經(jīng)常出現(xiàn)由于某個(gè)服務(wù)更新而沒有通知到其他服務(wù)，導(dǎo)致上線后慘案頻發(fā)。

這時(shí)就應(yīng)該進(jìn)行服務(wù)治理，將服務(wù)之間的直接依賴轉(zhuǎn)化為服務(wù)對服務(wù)中心的依賴。

Spring Cloud核心組件 Eureka就可以解決這類問題。

Eureka

Eureka是Netflix開源的一款提供服務(wù)注冊和發(fā)現(xiàn)的產(chǎn)品，它提供了完整的Service Registry和Service Discovery實(shí)現(xiàn)。它也是Spring Cloud體系中最重要的核心組件之一。

簡單來說，Eureka就是一個(gè)服務(wù)中心，將所有的可以提供的服務(wù)都注冊到它這里來管理，調(diào)用者需要的時(shí)候去注冊中心獲取，然后再進(jìn)行調(diào)用，避免了服務(wù)之間的直接調(diào)用，方便后續(xù)的水平擴(kuò)展、故障轉(zhuǎn)移等。

當(dāng)然如果服務(wù)中心掛掉了，那就是影響全部服務(wù)，因此需要搭建Eureka集群來保持高可用性，生存中建議最少兩臺(tái)。

隨著系統(tǒng)的流量不斷增加，需要根據(jù)情況來擴(kuò)展某個(gè)服務(wù)，Eureka內(nèi)部已經(jīng)提供了均衡負(fù)載的功能，只需要增加相應(yīng)的服務(wù)端實(shí)例即可。

那么系統(tǒng)運(yùn)行中某個(gè)實(shí)例掛了怎么辦？

Eureka內(nèi)容有一個(gè)心跳檢測機(jī)制，如果某個(gè)實(shí)例在規(guī)定時(shí)間內(nèi)沒有進(jìn)行通訊則自動(dòng)被剔除掉，避免了某個(gè)實(shí)例掛掉而影響服務(wù)。

因此使用Eureka就自動(dòng)具備了注冊中心、負(fù)載均衡、故障轉(zhuǎn)移等功能。

Hystrix

在微服務(wù)的架構(gòu)中通常會(huì)有多個(gè)服務(wù)層調(diào)用，一個(gè)服務(wù)的故障可能會(huì)導(dǎo)致級聯(lián)故障，最終造成整個(gè)系統(tǒng)不可用的情況，這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng)。

服務(wù)雪崩效應(yīng)是一種因 “服務(wù)提供者” 的不可用導(dǎo)致 “服務(wù)消費(fèi)者” 的不可用，并將不可用逐步擴(kuò)大的過程

例如：A是服務(wù)提供者，B是A的服務(wù)消費(fèi)者，C和D是B的服務(wù)消費(fèi)者。A不可用引發(fā)了B的不可用，B又引發(fā)了C和D的不可用，然后就像滾雪球一樣，雪崩效應(yīng)就形成了。

在這種情況下就需要整個(gè)服務(wù)機(jī)構(gòu)具有故障隔離的功能，避免某一個(gè)服務(wù)掛掉影響全局。在Spring Cloud中Hystrix組件就扮演了這個(gè)角色

Hystrix會(huì)在某個(gè)服務(wù)連續(xù)調(diào)用N次沒有響應(yīng)的情況下，立刻通知調(diào)用端調(diào)用失敗，避免調(diào)用端持續(xù)等待而影響了整體服務(wù)。Hystrix間隔時(shí)間會(huì)再次檢查此服務(wù)，如果服務(wù)恢復(fù)將繼續(xù)提供服務(wù)。

這種機(jī)制被稱為服務(wù)隔離或服務(wù)熔斷。

當(dāng)熔斷發(fā)生時(shí)需要迅速的響應(yīng)來解決問題，避免故障進(jìn)一步擴(kuò)散，那么對熔斷的監(jiān)視就變得非常重要。

熔斷的監(jiān)視現(xiàn)在有兩款工具：Hystrix-dashboard和Turbine。

Hystrix-dashboard是一款針對Hystrix進(jìn)行實(shí)時(shí)監(jiān)控的工具，通過Hystrix Dashboard 我們可以直觀地看到各個(gè)Hystrix Command的請求響應(yīng)時(shí)間，請求成功率等數(shù)據(jù)。

但是只使用Hystrix Dashboard的話，你只能看到單個(gè)應(yīng)用內(nèi)的服務(wù)信息，這是不夠的。

這時(shí)我們需要一個(gè)匯總系統(tǒng)內(nèi)多個(gè)服務(wù)數(shù)據(jù)，并顯示的Hystrix Dashboard上，這個(gè)工具就是Turbine。

效果如下：

配置中心

隨著微服務(wù)不斷的增多，每個(gè)微服務(wù)都有自己對應(yīng)的配置文件。在研發(fā)過程中有測試環(huán)境、UAT環(huán)境、生產(chǎn)環(huán)境，因此每個(gè)微服務(wù)至少三個(gè)環(huán)境的配置文件。

這么多的配置文件，如果需要修改某個(gè)公共服務(wù)的配置信息，如：緩存、數(shù)據(jù)庫等，難免會(huì)產(chǎn)生混亂，這個(gè)時(shí)候就需要引入Spring Cloud 另一個(gè)組件：Spring Cloud Config。

Spring Cloud Config

Spring Cloud Config 是一個(gè)解決分布式系統(tǒng)的配置管理系統(tǒng)。它包含了Client和Server兩個(gè)部分，Server提供配置文件的存儲(chǔ)、以接口的方式將配置文件的內(nèi)容提供出去，Client通過接口獲取數(shù)據(jù)，并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。

具體實(shí)現(xiàn)是Server端將所有配置文件服務(wù)化，需要配置文件的服務(wù)實(shí)例去Config Server獲取對應(yīng)的數(shù)據(jù)。將所有配置文件統(tǒng)一整理，避免了配置文件碎片化。

如果服務(wù)運(yùn)行期間改變配置文件，服務(wù)不會(huì)得到最新配置信息，需要解決這個(gè)問題就要引入Refresh。它可以在服務(wù)的運(yùn)行期間重新加載配置文件

當(dāng)所有的配置文件都存儲(chǔ)在配置中心時(shí)，配置中心就變成了一個(gè)非常重要的組件。如果配置中心出問題就會(huì)導(dǎo)致很嚴(yán)重的后果，因此在生產(chǎn)中建議對配置中心做集群，來支持配置中心高可用性。

Spring Cloud Bus

上面的Refresh方案雖然可以解決單個(gè)微服務(wù)運(yùn)行期間重載配置信息的問題，但是在真正的實(shí)踐生產(chǎn)中，可能會(huì)有N多個(gè)服務(wù)需要重新配置。

每次都手動(dòng)Refresh將是一個(gè)巨大的工作量，這時(shí)就需要另一個(gè)解決方案 Spring Cloud Bus

Spring Cloud Bus 是通過輕量消息代理連接各個(gè)分布的節(jié)點(diǎn)。一般會(huì)用在廣播狀態(tài)變化（例如配置變化）或者其他的消息指令中

Spring Cloud Bus 的一個(gè)核心思想是通過分布式的啟動(dòng)器對Spring Boot應(yīng)用進(jìn)行擴(kuò)展，也可以用來創(chuàng)建一個(gè)或多個(gè)應(yīng)用之間的通信頻道。目前唯一實(shí)現(xiàn)的方式是用AMQP消息代理作為通道

Spring Cloud Bus 是輕量級的通訊組件，也可以用在其他類似的場景中。有了Spring Cloud Bus之后，當(dāng)我們改變配置文件提交到版本庫中時(shí)，會(huì)自動(dòng)觸發(fā)對應(yīng)實(shí)例的Refresh?

服務(wù)網(wǎng)關(guān)

在微服務(wù)架構(gòu)模式下，后端服務(wù)的實(shí)例數(shù)一般是動(dòng)態(tài)的，對于客戶端而言很難發(fā)現(xiàn)動(dòng)態(tài)改變的服務(wù)實(shí)例的訪問地址信息。

因此在基于微服務(wù)的項(xiàng)目中為了簡化前端的調(diào)用邏輯，通常會(huì)引入API Gateway作為輕量級網(wǎng)管，同時(shí)API Gateway中也會(huì)實(shí)現(xiàn)相關(guān)的認(rèn)證邏輯，從而簡化了內(nèi)部服務(wù)之間相互調(diào)用的復(fù)雜度。

Spring Cloud 體系中支持API Gateway落地的技術(shù)就是Zuul。Spring Cloud Zuul路由是微軟服務(wù)架構(gòu)中不可或缺的一部分，提供動(dòng)態(tài)路由，監(jiān)控，彈性，安全等邊緣服務(wù)。

Zuul是Netflix出品的一個(gè)基于JVM路由的服務(wù)端的負(fù)載均衡。

他的具體作用就是服務(wù)轉(zhuǎn)發(fā)，接收并轉(zhuǎn)發(fā)所有內(nèi)外部的客戶端調(diào)用。使用Zuul可以作為資源的統(tǒng)一訪問入口，同時(shí)也可以在網(wǎng)關(guān)做一些權(quán)限校驗(yàn)等類似的功能。

鏈路跟蹤

隨著服務(wù)數(shù)量越來越多，對調(diào)用鏈的分析會(huì)越來越復(fù)雜，如服務(wù)之間的調(diào)用關(guān)系，某個(gè)請求對應(yīng)的調(diào)用鏈，調(diào)用之間消費(fèi)的時(shí)間等，對這些信息進(jìn)行監(jiān)控就成了問題

在實(shí)際的使用中，我們需要監(jiān)控服務(wù)和服務(wù)之間通訊的各項(xiàng)指標(biāo)，這些數(shù)據(jù)將是我們改進(jìn)系統(tǒng)架構(gòu)的主要依據(jù)。

因此分布式的鏈路跟蹤就變的非常重要，Spring Cloud也給出了具體的解決方案：Spring Cloud Sleuth和Zipkin。

Spring Cloud Sleuth 為服務(wù)之間調(diào)用提供鏈路跟蹤。通過Sleuth可以很清楚的了解到一個(gè)服務(wù)請求經(jīng)過了哪些服務(wù)，每個(gè)服務(wù)處理花費(fèi)了多長時(shí)間。從而讓我們可以很方便的理清各個(gè)微服務(wù)之間的調(diào)用關(guān)系。

Zipkin 是 Twitter 的一個(gè)開源項(xiàng)目，允許開發(fā)者收集Twitter各個(gè)服務(wù)上的監(jiān)控?cái)?shù)據(jù)，并提供查詢接口

總結(jié)

我們從整體上來看一下Spring Cloud各個(gè)組件如何來配套使用

• Eureka 負(fù)責(zé)服務(wù)的注冊與發(fā)現(xiàn)，很好地將各服務(wù)連接起來。

• Hystrix 負(fù)責(zé)監(jiān)控服務(wù)之間的調(diào)用情況，連續(xù)多次失敗進(jìn)行熔斷保護(hù)。

• Hystrix dashboard，Turbine 負(fù)責(zé)監(jiān)控 Hystrix 的熔斷情況，并給予圖形化的展示。

• Spring Cloud Config 提供了統(tǒng)一的配置中心服務(wù)。

• 當(dāng)配置文件發(fā)生變化的時(shí)候，Spring Cloud Bus 負(fù)責(zé)通知各服務(wù)去獲取最新的配置信息。

• 所有對外的請求和服務(wù)，我們都通過Zuul來進(jìn)行轉(zhuǎn)發(fā)，起到 API 網(wǎng)關(guān)的作用。

• 最后我們使用 Sleuth+Zipkin 將所有的請求數(shù)據(jù)記錄下來，方便我們進(jìn)行后續(xù)分析。