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

Spring Cloud解決的第一個問題就是：服務(wù)與服務(wù)之間的解耦。很多公司在業(yè)務(wù)高速發(fā)展的時候，服務(wù)組件也會相應(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ù)化組件的不斷增多，服務(wù)之間的調(diào)用關(guān)系成指數(shù)級別的增長，這樣最容易導(dǎo)致的情況就是牽一發(fā)而動全身。經(jīng)常出現(xiàn)由于某個服務(wù)更新而沒有通知到其它服務(wù)，導(dǎo)致上線后慘案頻發(fā)。這時候就應(yīng)該進行服務(wù)治理，將服務(wù)之間的直接依賴轉(zhuǎn)化為服務(wù)對服務(wù)中心的依賴。Spring Cloud 核心組件Eureka就是解決這類問題。

Eureka

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

用大白話講，Eureka就是一個服務(wù)中心，將所有的可以提供的服務(wù)都注冊到它這里來管理，其它各調(diào)用者需要的時候去注冊中心獲取，然后再進行調(diào)用，避免了服務(wù)之間的直接調(diào)用，方便后續(xù)的水平擴展、故障轉(zhuǎn)移等。如下圖：

當(dāng)然服務(wù)中心這么重要的組件一但掛掉將會影響全部服務(wù)，因此需要搭建Eureka集群來保持高可用性，生產(chǎn)中建議最少兩臺。隨著系統(tǒng)的流量不斷增加，需要根據(jù)情況來擴展某個服務(wù)，Eureka內(nèi)部已經(jīng)提供均衡負(fù)載的功能，只需要增加相應(yīng)的服務(wù)端實例既可。那么在系統(tǒng)的運行期間某個實例掛了怎么辦？Eureka內(nèi)容有一個心跳檢測機制，如果某個實例在規(guī)定的時間內(nèi)沒有進行通訊則會自動被剔除掉，避免了某個實例掛掉而影響服務(wù)。

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

Hystrix

在微服務(wù)架構(gòu)中通常會有多個服務(wù)層調(diào)用，基礎(chǔ)服務(wù)的故障可能會導(dǎo)致級聯(lián)故障，進而造成整個系統(tǒng)不可用的情況，這種現(xiàn)象被稱為服務(wù)雪崩效應(yīng)。服務(wù)雪崩效應(yīng)是一種因“服務(wù)提供者”的不可用導(dǎo)致“服務(wù)消費者”的不可用,并將不可用逐漸放大的過程。

如下圖所示：A作為服務(wù)提供者，B為A的服務(wù)消費者，C和D是B的服務(wù)消費者。A不可用引起了B的不可用，并將不可用像滾雪球一樣放大到C和D時，雪崩效應(yīng)就形成了。

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

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

Hystrix Dashboard和Turbine

當(dāng)熔斷發(fā)生的時候需要迅速的響應(yīng)來解決問題，避免故障進一步擴散，那么對熔斷的監(jiān)控就變得非常重要。熔斷的監(jiān)控現(xiàn)在有兩款工具：Hystrix-dashboard和Turbine

Hystrix-dashboard是一款針對Hystrix進行實時監(jiān)控的工具，通過Hystrix Dashboard我們可以直觀地看到各Hystrix Command的請求響應(yīng)時間, 請求成功率等數(shù)據(jù)。但是只使用Hystrix Dashboard的話, 你只能看到單個應(yīng)用內(nèi)的服務(wù)信息, 這明顯不夠. 我們需要一個工具能讓我們匯總系統(tǒng)內(nèi)多個服務(wù)的數(shù)據(jù)并顯示到Hystrix Dashboard上, 這個工具就是Turbine. 監(jiān)控的效果圖如下：

配置中心

隨著微服務(wù)不斷的增多，每個微服務(wù)都有自己對應(yīng)的配置文件。在研發(fā)過程中有測試環(huán)境、UAT環(huán)境、生產(chǎn)環(huán)境，因此每個微服務(wù)又對應(yīng)至少三個不同環(huán)境的配置文件。這么多的配置文件，如果需要修改某個公共服務(wù)的配置信息，如：緩存、數(shù)據(jù)庫等，難免會產(chǎn)生混亂，這個時候就需要引入Spring Cloud另外一個組件：Spring Cloud Config。

Spring Cloud Config

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

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

如果服務(wù)運行期間改變配置文件，服務(wù)是不會得到最新的配置信息，需要解決這個問題就需要引入Refresh?？梢栽诜?wù)的運行期間重新加載配置文件。

當(dāng)所有的配置文件都存儲在配置中心的時候，配置中心就成為了一個非常重要的組件。如果配置中心出現(xiàn)問題將會導(dǎo)致災(zāi)難性的后果，因此在生產(chǎn)中建議對配置中心做集群，來支持配置中心高可用性。

Spring Cloud Bus

上面的Refresh方案雖然可以解決單個微服務(wù)運行期間重載配置信息的問題，但是在真正的實踐生產(chǎn)中，可能會有N多的服務(wù)需要更新配置，如果每次依靠手動Refresh將是一個巨大的工作量，這時候Spring Cloud提出了另外一個解決方案：Spring Cloud Bus

Spring Cloud Bus通過輕量消息代理連接各個分布的節(jié)點。這會用在廣播狀態(tài)的變化（例如配置變化）或者其它的消息指令中。Spring Cloud Bus的一個核心思想是通過分布式的啟動器對Spring Boot應(yīng)用進行擴展，也可以用來建立一個或多個應(yīng)用之間的通信頻道。目前唯一實現(xiàn)的方式是用AMQP消息代理作為通道。

Spring Cloud Bus是輕量級的通訊組件，也可以用在其它類似的場景中。有了Spring Cloud Bus之后，當(dāng)我們改變配置文件提交到版本庫中時，會自動的觸發(fā)對應(yīng)實例的Refresh，具體的工作流程如下：

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

在微服務(wù)架構(gòu)模式下，后端服務(wù)的實例數(shù)一般是動態(tài)的，對于客戶端而言很難發(fā)現(xiàn)動態(tài)改變的服務(wù)實例的訪問地址信息。因此在基于微服務(wù)的項目中為了簡化前端的調(diào)用邏輯，通常會引入API Gateway作為輕量級網(wǎng)關(guān)，同時API Gateway中也會實現(xiàn)相關(guān)的認(rèn)證邏輯從而簡化內(nèi)部服務(wù)之間相互調(diào)用的復(fù)雜度。

Spring Cloud體系中支持API Gateway落地的技術(shù)就是Zuul。Spring Cloud Zuul路由是微服務(wù)架構(gòu)中不可或缺的一部分，提供動態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。Zuul是Netflix出品的一個基于JVM路由和服務(wù)端的負(fù)載均衡器。

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

鏈路跟蹤

隨著服務(wù)的越來越多，對調(diào)用鏈的分析會越來越復(fù)雜，如服務(wù)之間的調(diào)用關(guān)系、某個請求對應(yīng)的調(diào)用鏈、調(diào)用之間消費的時間等，對這些信息進行監(jiān)控就成為一個問題。在實際的使用中我們需要監(jiān)控服務(wù)和服務(wù)之間通訊的各項指標(biāo)，這些數(shù)據(jù)將是我們改進系統(tǒng)架構(gòu)的主要依據(jù)。因此分布式的鏈路跟蹤就變的非常重要，Spring Cloud也給出了具體的解決方案：Spring Cloud Sleuth和Zipkin

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

Zipkin是Twitter的一個開源項目，允許開發(fā)者收集 Twitter 各個服務(wù)上的監(jiān)控數(shù)據(jù)，并提供查詢接口。源碼來源