前言： 之前我們已經(jīng)了解了「什么是微服務(wù)？」，現(xiàn)在我們開始了解「微服務(wù)」關(guān)鍵字下比較熱門的「Spring Cloud」...

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

部分引用自：從架構(gòu)演進(jìn)的角度聊聊Spring Cloud都做了些什么？ - 純潔的微笑

單體架構(gòu)

單體架構(gòu)在小微企業(yè)比較常見，典型代表就是一個(gè)應(yīng)用、一個(gè)數(shù)據(jù)庫(kù)、一個(gè)web容器就可以跑起來(lái)。

在兩種情況下可能會(huì)選擇單體架構(gòu)：一是在企業(yè)發(fā)展的初期，為了保證快速上線，采用此種方案較為簡(jiǎn)單靈活；二是傳統(tǒng)企業(yè)中垂直度較高，訪問(wèn)壓力較小的業(yè)務(wù)。在這種模式下對(duì)技術(shù)要求較低，方便各層次開發(fā)人員接手，也能滿足客戶需求。

下面是單體架構(gòu)的架構(gòu)圖：

在單體架構(gòu)中，技術(shù)選型非常靈活，優(yōu)先滿足快速上線的要求，也便于快速跟進(jìn)市場(chǎng)。

垂直架構(gòu)

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

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

下面是垂直架構(gòu)的架構(gòu)圖：

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

如果公司進(jìn)一步的做大，垂直子系統(tǒng)會(huì)變的越來(lái)越多，系統(tǒng)和系統(tǒng)之間的調(diào)用關(guān)系呈指數(shù)上升的趨勢(shì)。在這樣的背景下，很多公司都會(huì)考慮服務(wù)的 SOA 化。SOA 代表面向服務(wù)的架構(gòu)，將應(yīng)用程序根據(jù)不同的職責(zé)劃分為不同的模塊，不同的模塊直接通過(guò)特定的協(xié)議和接口進(jìn)行交互。這樣使整個(gè)系統(tǒng)切分成很多單個(gè)組件服務(wù)來(lái)完成請(qǐng)求，當(dāng)流量過(guò)大時(shí)通過(guò)水平擴(kuò)展相應(yīng)的組件來(lái)支撐，所有的組件通過(guò)交互來(lái)滿足整體的業(yè)務(wù)需求。

SOA服務(wù)化的優(yōu)點(diǎn)是，它可以根據(jù)需求通過(guò)網(wǎng)絡(luò)對(duì)松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署、組合和使用。服務(wù)層是SOA的基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。

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

下面是服務(wù)化架構(gòu)圖：

在這個(gè)階段可以使用 WebService 或者 Dubbo 來(lái)服務(wù)治理。

我們發(fā)現(xiàn)從單體架構(gòu)到服務(wù)化架構(gòu)，應(yīng)用數(shù)量都在不斷的增加，慢慢的下沉的就成了基礎(chǔ)組建，上浮的就成為業(yè)務(wù)系統(tǒng)。從上述也可以看出架構(gòu)的本質(zhì)就是不斷的拆分重構(gòu)：分的過(guò)程是把系統(tǒng)拆分為各個(gè)子系統(tǒng)/模塊/組件，拆的時(shí)候，首先要解決每個(gè)組件的定位問(wèn)題，然后才能劃分彼此的邊界，實(shí)現(xiàn)合理的拆分。合就是根據(jù)最終要求，把各個(gè)分離的組件有機(jī)整合在一起。拆分的結(jié)果使開發(fā)人員能夠做到業(yè)務(wù)聚焦、技能聚焦，實(shí)現(xiàn)開發(fā)敏捷，合的結(jié)果是系統(tǒng)變得柔性，可以因需而變，實(shí)現(xiàn)業(yè)務(wù)敏捷。

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

微服務(wù)是一種軟件架構(gòu)風(fēng)格，它是以專注于單一責(zé)任與功能的小型功能區(qū)塊為基礎(chǔ)，利用模組化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語(yǔ)言無(wú)關(guān)的 API（例如 REST）集相互通訊，且每個(gè)服務(wù)可以被單獨(dú)部署，它具備以下三個(gè)核心特點(diǎn)：

• 微服務(wù)為大型系統(tǒng)而生。隨著業(yè)務(wù)的快速增長(zhǎng)，會(huì)帶來(lái)系統(tǒng)流量壓力和復(fù)雜度的上升，系統(tǒng)的可維護(hù)性和可擴(kuò)展性成為架構(gòu)設(shè)計(jì)的主要考慮因素，微服務(wù)架構(gòu)設(shè)計(jì)理念通過(guò)小而美的業(yè)務(wù)拆分，通過(guò)分而自治來(lái)實(shí)現(xiàn)復(fù)雜系統(tǒng)的優(yōu)雅設(shè)計(jì)實(shí)現(xiàn)。
• 微服務(wù)架構(gòu)是面向結(jié)果的。微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格的產(chǎn)生并非是出于學(xué)術(shù)或?yàn)闃?biāo)準(zhǔn)而標(biāo)準(zhǔn)的設(shè)計(jì)，而是在軟件架構(gòu)設(shè)計(jì)領(lǐng)域不斷演進(jìn)過(guò)程中，面對(duì)實(shí)際工業(yè)界所遇到問(wèn)題，而出現(xiàn)的面向解決實(shí)際問(wèn)題的架構(gòu)設(shè)計(jì)風(fēng)格。
• 專注于服務(wù)的可替代性來(lái)設(shè)計(jì)。微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格核心要解決的問(wèn)題之一便是如何便利地在大型系統(tǒng)中進(jìn)行系統(tǒng)組件的維護(hù)和替換，且不影響整體系統(tǒng)穩(wěn)定性。

SOA 與 微服務(wù) 的不同在于：

• 服務(wù)拆分粒度更細(xì)。微服務(wù)可以說(shuō)是更細(xì)維度的服務(wù)化，小到一個(gè)子子模塊，只要該模塊依賴的資源與其他模塊都沒(méi)有關(guān)系，那么就可以拆分成一個(gè)微服務(wù)。
• 服務(wù)獨(dú)立部署。每個(gè)服務(wù)都嚴(yán)格遵循獨(dú)立打包部署的準(zhǔn)則，互不影響。比如一臺(tái)物理機(jī)上可以部署多個(gè) Docker 實(shí)例，每個(gè) Docker 實(shí)例可以部署一個(gè)微服務(wù)的代碼。
• 服務(wù)獨(dú)立維護(hù)。每個(gè)微服務(wù)都可以交由一個(gè)小團(tuán)隊(duì)甚至個(gè)人來(lái)開發(fā)、測(cè)試、發(fā)布和運(yùn)維，并對(duì)整個(gè)生命周期負(fù)責(zé)。
• 服務(wù)治理能力要求高。因?yàn)椴鸱譃槲⒎?wù)之后，服務(wù)的數(shù)量變多，因此需要有統(tǒng)一的服務(wù)治理平臺(tái)，來(lái)對(duì)各個(gè)服務(wù)進(jìn)行管理。

二、引入 Spring Cloud

什么是 Spring Cloud?

Spring 全家桶在 Java 開發(fā)中擁有舉足輕重的地位，其中的一系列產(chǎn)品不僅僅大大簡(jiǎn)化和方便了 Java 的開發(fā)，其中的 AOP 和 IoC 等一系列的理念也深刻地影響著 Java 程序員們。

Spring 全家桶產(chǎn)品眾多，總結(jié)起來(lái)大概就是：

• Spring 通常指 Spring IOC。
• Spring Framework 包含了 Spring IOC，同時(shí)包含了 Spring AOP，并實(shí)現(xiàn)與其它 J2EE 框架的整合。
• Spring Boot 是對(duì) Spring Framework 的補(bǔ)充，讓框架的集成變得更簡(jiǎn)單，致力于快速開發(fā) 獨(dú)立的 Spring 應(yīng)用。
• Spring Cloud 是基于 Spring Boot 設(shè)計(jì)的一套微服務(wù)規(guī)范，并增強(qiáng)了應(yīng)用上下文。

我們也不妨來(lái)看看官網(wǎng)的介紹：

總結(jié)起來(lái)就是： Spring Cloud 是一系列框架的有序集合。我們能夠使用基于 Spring Boot 設(shè)計(jì)的 Spring Cloud 方便快速的搭建起自己的可靠、協(xié)調(diào)一致的分布式系統(tǒng)。

為什么是 Spring Cloud？

微服務(wù)的框架那么多比如：Dubbo、Kubernetes，為什么就要使用 Spring Cloud 的呢？

• 產(chǎn)出于 Spring 大家族，Spring 在企業(yè)級(jí)開發(fā)框架中無(wú)人能敵，來(lái)頭很大，可以保證后續(xù)的更新、完善。比如 Dubbo 現(xiàn)在就差不多死了
• 有 Spring Boot 這個(gè)獨(dú)立干將可以省很多事，大大小小的活 Spring Boot 都搞的挺不錯(cuò)。
• 作為一個(gè)微服務(wù)治理的大家伙，考慮的很全面，幾乎服務(wù)治理的方方面面都考慮到了，方便開發(fā)開箱即用。
• Spring Cloud 活躍度很高，教程很豐富，遇到問(wèn)題很容易找到解決方案。
• 輕輕松松幾行代碼就完成了熔斷、均衡負(fù)載、服務(wù)中心的各種平臺(tái)功能。

三、Spring Cloud 能夠幫我們做什么？

前面我們說(shuō)到了，「Spring Cloud」是一系列框架的集合，可以幫助我們解決分布式/微服務(wù)的各種問(wèn)題，那么「Spring Cloud」究竟能幫助我們做什么呢？

SpringCloud的基礎(chǔ)功能包括：

• 服務(wù)治理： Spring Cloud Eureka
• 客戶端負(fù)載均衡： Spring Cloud Ribbon
• 服務(wù)容錯(cuò)保護(hù)： Spring Cloud Hystrix
• 聲明式服務(wù)調(diào)用： Spring Cloud Feign
• API網(wǎng)關(guān)服務(wù)： Spring Cloud Zuul
• 分布式配置中心： Spring Cloud Config

當(dāng)然 Spring Cloud 還包括一些高級(jí)的功能：

• 消息總線： Spring Cloud Bus
• 消息驅(qū)動(dòng)的微服務(wù)： Spring Cloud Stream
• 分布式服務(wù)跟蹤： Spring Cloud Sleuth

服務(wù)治理：Eureka

微服務(wù)很重要的一點(diǎn)就是「無(wú)狀態(tài)」，也就是說(shuō)每一個(gè)服務(wù)之間應(yīng)該是獨(dú)立的，所以當(dāng)微服務(wù)架構(gòu)搭起來(lái)之后各個(gè)獨(dú)立的「微服務(wù)」之間應(yīng)該如何通訊成了首要的問(wèn)題。

假設(shè)我們的 A服務(wù) 需要訪問(wèn) B服務(wù)，那么我們首先需要知道對(duì)方的 ip地址，所以我們調(diào)用起來(lái)可能就像：

似乎并沒(méi)有什么問(wèn)題，但是如果 B服務(wù) 的 ip地址 變更了，那么我們就只能手動(dòng)的去更改 A服務(wù) 的配置，如果我們的服務(wù)有很多，并且不止 A服務(wù) 調(diào)用了 B服務(wù)，那么手動(dòng)更改這些配置將會(huì)是一場(chǎng)噩夢(mèng)。

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

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

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

因此使用了Eureka就自動(dòng)具有了注冊(cè)中心、負(fù)載均衡、故障轉(zhuǎn)移的功能。如果想對(duì)Eureka進(jìn)一步了解可以參考這篇文章：注冊(cè)中心Eureka

客戶端負(fù)載均衡： Ribbon

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

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

• 實(shí)戰(zhàn)：

Spring Cloud構(gòu)建微服務(wù)架構(gòu)（二）服務(wù)消費(fèi)者 - http://blog.didispace.com/springcloud2/

服務(wù)容錯(cuò)保護(hù)： Hystrix

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

如下圖所示：A作為服務(wù)提供者，B為A的服務(wù)消費(fèi)者，C和D是B的服務(wù)消費(fèi)者。A不可用引起了B的不可用，并將不可用像滾雪球一樣放大到C和D時(shí)，雪崩效應(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ù)。

繼續(xù)了解Hystrix可以參考：熔斷器Hystrix

Hystrix Dashboard 和 Turbine

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

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

想了解具體都監(jiān)控了哪些指標(biāo)，以及如何監(jiān)控可以參考這篇文章：熔斷監(jiān)控Hystrix Dashboard和Turbine

聲明式服務(wù)調(diào)用：Feign

上面我們介紹了 Ribbon 和 Hystrix 了，可以發(fā)現(xiàn)：這兩個(gè)可以作為基礎(chǔ)工具類廣泛的嵌入到各個(gè)微服務(wù)中。為了簡(jiǎn)化我們的開發(fā)，Spring Cloud Feign 出現(xiàn)了！它基于 Netflix Feign 實(shí)現(xiàn)，整合了 Spring Cloud Ribbon 與 Spring Cloud Hystrix, 除了整合這兩者的強(qiáng)大功能之外，它還提供了聲明式的服務(wù)調(diào)用(不再通過(guò)RestTemplate)。

Feign 是一種聲明式、模板化的HTTP客戶端。在 Spring Cloud 中使用 Feign, 我們可以做到使用HTTP請(qǐng)求遠(yuǎn)程服務(wù)時(shí)能與調(diào)用本地方法一樣的編碼體驗(yàn)，開發(fā)者完全感知不到這是遠(yuǎn)程方法，更感知不到這是個(gè) HTTP 請(qǐng)求。

下面就簡(jiǎn)單看看Feign是怎么優(yōu)雅地實(shí)現(xiàn)遠(yuǎn)程調(diào)用的：

服務(wù)綁定：

// value --->指定調(diào)用哪個(gè)服務(wù)
// fallbackFactory--->熔斷器的降級(jí)提示
@FeignClient(value = "MICROSERVICECLOUD-DEPT", fallbackFactory = DeptClientServiceFallbackFactory.class)
public interface DeptClientService {

    // 采用Feign我們可以使用SpringMVC的注解來(lái)對(duì)服務(wù)進(jìn)行綁定！
    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    public Dept get(@PathVariable("id") long id);

    @RequestMapping(value = "/dept/list", method = RequestMethod.GET)
    public List<Dept> list();

    @RequestMapping(value = "/dept/add", method = RequestMethod.POST)
    public boolean add(Dept dept);
}

Feign 中使用熔斷器：

/**
 * Feign中使用斷路器
 * 這里主要是處理異常出錯(cuò)的情況(降級(jí)/熔斷時(shí)服務(wù)不可用，fallback就會(huì)找到這里來(lái))
 */
@Component // 不要忘記添加，不要忘記添加
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService> {
    @Override
    public DeptClientService create(Throwable throwable) {
        return new DeptClientService() {
            @Override
            public Dept get(long id) {
                return new Dept().setDeptno(id).setDname("該ID：" + id + "沒(méi)有沒(méi)有對(duì)應(yīng)的信息,Consumer客戶端提供的降級(jí)信息,此刻服務(wù)Provider已經(jīng)關(guān)閉")
                        .setDb_source("no this database in MySQL");
            }

            @Override
            public List<Dept> list() {
                return null;
            }

            @Override
            public boolean add(Dept dept) {
                return false;
            }
        };
    }
}

調(diào)用：

• 引用自：
  外行人都能看懂的 Spring Cloud - https://juejin.im/post/5b83466b6fb9a019b421cecc#heading-12

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

在微服務(wù)架構(gòu)模式下，后端服務(wù)的實(shí)例數(shù)一般是動(dòng)態(tài)的，對(duì)于客戶端而言很難發(fā)現(xiàn)動(dòng)態(tài)改變的服務(wù)實(shí)例的訪問(wèn)地址信息。因此在基于微服務(wù)的項(xiàng)目中為了簡(jiǎn)化前端的調(diào)用邏輯，通常會(huì)引入 API Gateway 作為輕量級(jí)網(wǎng)關(guān)，同時(shí) API Gateway 中也會(huì)實(shí)現(xiàn)相關(guān)的認(rèn)證邏輯從而簡(jiǎ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)一訪問(wèn)入口，同時(shí)也可以在網(wǎng)關(guān)做一些權(quán)限校驗(yàn)等類似的功能。

具體使用參考這篇文章：服務(wù)網(wǎng)關(guān)zuul

分布式配置中心：Config

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

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

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

如果服務(wù)運(yùn)行期間改變配置文件，服務(wù)是不會(huì)得到最新的配置信息，需要解決這個(gè)問(wèn)題就需要引入 Refresh?？梢栽诜?wù)的運(yùn)行期間重新加載配置文件，具體可以參考這篇文章：配置中心svn示例和refresh

當(dāng)所有的配置文件都存儲(chǔ)在配置中心的時(shí)候，配置中心就成為了一個(gè)非常重要的組件。如果配置中心出現(xiàn)問(wèn)題將會(huì)導(dǎo)致災(zāi)難性的后果，因此在生產(chǎn)中建議對(duì)配置中心做集群，來(lái)支持配置中心高可用性。具體參考：配置中心服務(wù)化和高可用

消息總線：Bus

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

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

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

也可以參考這篇文章來(lái)了解：配置中心和消息總線

消息驅(qū)動(dòng)的微服務(wù)：Stream

Spring Cloud Stream 是一個(gè)用來(lái)為微服務(wù)應(yīng)用構(gòu)建消息驅(qū)動(dòng)能力的框架。它可以基于 Spring Boot 來(lái)創(chuàng)建獨(dú)立的、可用于生產(chǎn)的 Spring 應(yīng)用程序。它通過(guò)使用 Spring Integration 來(lái)連接消息代理中間件以實(shí)現(xiàn)消息事件驅(qū)動(dòng)的微服務(wù)應(yīng)用。

下圖是官方文檔中對(duì)于 Spring Cloud Stream 應(yīng)用模型的結(jié)構(gòu)圖。從中我們可以看到，Spring Cloud Stream 構(gòu)建的應(yīng)用程序與消息中間件之間是通過(guò)綁定器 Binder 相關(guān)聯(lián)的，綁定器對(duì)于應(yīng)用程序而言起到了隔離作用，它使得不同消息中間件的實(shí)現(xiàn)細(xì)節(jié)對(duì)應(yīng)用程序來(lái)說(shuō)是透明的。所以對(duì)于每一個(gè) Spring Cloud Stream 的應(yīng)用程序來(lái)說(shuō)，它不需要知曉消息中間件的通信細(xì)節(jié)，它只需要知道 Binder 對(duì)應(yīng)用程序提供的概念去實(shí)現(xiàn)即可。如下圖案例，在應(yīng)用程序和 Binder 之間定義了兩條輸入通道和三條輸出通道來(lái)傳遞消息，而綁定器則是作為這些通道和消息中間件之間的橋梁進(jìn)行通信。

Spring Cloud Stream 為一些供應(yīng)商的消息中間件產(chǎn)品提供了個(gè)性化的自動(dòng)化配置實(shí)現(xiàn)，并且引入了發(fā)布-訂閱、消費(fèi)組以及消息分區(qū)這三個(gè)核心概念。簡(jiǎn)單的說(shuō)，Spring Cloud Stream 本質(zhì)上就是整合了 Spring Boot 和 Spring Integration，實(shí)現(xiàn)了一套輕量級(jí)的消息驅(qū)動(dòng)的微服務(wù)框架。通過(guò)使用 Spring Cloud Stream，可以有效地簡(jiǎn)化開發(fā)人員對(duì)消息中間件的使用復(fù)雜度，讓系統(tǒng)開發(fā)人員可以有更多的精力關(guān)注于核心業(yè)務(wù)邏輯的處理。由于 Spring Cloud Stream 基于 Spring Boot 實(shí)現(xiàn)，所以它秉承了 Spring Boot 的優(yōu)點(diǎn)，實(shí)現(xiàn)了自動(dòng)化配置的功能幫忙我們可以快速的上手使用，但是目前為止 Spring Cloud Stream 只支持 RabbitMQ 和 Kafka 兩個(gè)著名的消息中間件的自動(dòng)化配置：

• 實(shí)戰(zhàn)：
  Spring Cloud構(gòu)建微服務(wù)架構(gòu)：消息驅(qū)動(dòng)的微服務(wù)（入門）【Dalston版】 - http://blog.didispace.com/spring-cloud-starter-dalston-7-1/

分布式服務(wù)跟蹤：Sleuth

隨著服務(wù)的越來(lái)越多，對(duì)調(diào)用鏈的分析會(huì)越來(lái)越復(fù)雜，如服務(wù)之間的調(diào)用關(guān)系、某個(gè)請(qǐng)求對(duì)應(yīng)的調(diào)用鏈、調(diào)用之間消費(fèi)的時(shí)間等，對(duì)這些信息進(jìn)行監(jiān)控就成為一個(gè)問(wè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)用提供鏈路追蹤。通過(guò) Sleuth 可以很清楚的了解到一個(gè)服務(wù)請(qǐng)求經(jīng)過(guò)了哪些服務(wù)，每個(gè)服務(wù)處理花費(fèi)了多長(zhǎng)時(shí)間。從而讓我們可以很方便的理清各微服務(wù)間的調(diào)用關(guān)系。

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

分布式鏈路跟蹤需要 Sleuth + Zipkin 結(jié)合來(lái)實(shí)現(xiàn)，具體操作參考這篇文章：分布式鏈路跟蹤(Sleuth)

總結(jié)

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

從上圖可以看出 Spring Cloud 各個(gè)組件相互配合，合作支持了一套完整的微服務(wù)架構(gòu)。

• 其中 Eureka 負(fù)責(zé)服務(wù)的注冊(cè)與發(fā)現(xiàn)，很好將各服務(wù)連接起來(lái)
• 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ù)去獲取最新的配置信息
• 所有對(duì)外的請(qǐng)求和服務(wù)，我們都通過(guò) Zuul 來(lái)進(jìn)行轉(zhuǎn)發(fā)，起到 API 網(wǎng)關(guān)的作用
• 最后我們使用 Sleuth + Zipkin 將所有的請(qǐng)求數(shù)據(jù)記錄下來(lái)，方便我們進(jìn)行后續(xù)分析

Spring Cloud 從設(shè)計(jì)之初就考慮了絕大多數(shù)互聯(lián)網(wǎng)公司架構(gòu)演化所需的功能，如服務(wù)發(fā)現(xiàn)注冊(cè)、配置中心、消息總線、負(fù)載均衡、斷路器、數(shù)據(jù)監(jiān)控等。這些功能都是以插拔的形式提供出來(lái)，方便我們系統(tǒng)架構(gòu)演進(jìn)的過(guò)程中，可以合理的選擇需要的組件進(jìn)行集成，從而在架構(gòu)演進(jìn)的過(guò)程中會(huì)更加平滑、順利。

微服務(wù)架構(gòu)是一種趨勢(shì)，Spring Cloud 提供了標(biāo)準(zhǔn)化的、全站式的技術(shù)方案，意義可能會(huì)堪比當(dāng)前 Servlet 規(guī)范的誕生，有效推進(jìn)服務(wù)端軟件系統(tǒng)技術(shù)水平的進(jìn)步。

引用自：從架構(gòu)演進(jìn)的角度聊聊Spring Cloud都做了些什么？ - http://www.ityouknow.com/springcloud/2017/11/02/framework-and-springcloud.html

四、Spring Cloud 版本

剛接觸的「Spring Cloud」的童鞋可能會(huì)對(duì)它的版本感到奇怪，什么 Angle、Brixton、Finchley，這些都是啥??？「為什么會(huì)有這么多種看起來(lái)不同的 Spring Cloud？」

從上面我們可以知道：Spring Cloud 是一個(gè)擁有諸多子項(xiàng)目的大型綜合項(xiàng)目（功能不止上面的介紹），原則上其子項(xiàng)目也都維護(hù)著自己的發(fā)布版本號(hào)。那么每一個(gè)Spring Cloud的版本都會(huì)包含不同的子項(xiàng)目版本，為了要管理每個(gè)版本的子項(xiàng)目清單，避免版本名與子項(xiàng)目的發(fā)布號(hào)混淆，所以沒(méi)有采用版本號(hào)的方式，而是通過(guò)命名的方式。

這些版本名字采用了倫敦地鐵站的名字，根據(jù)字母表的順序來(lái)對(duì)應(yīng)版本時(shí)間順序，比如：最早的Release版本：Angel，第二個(gè)Release版本：Brixton，以此類推……

當(dāng)一個(gè)項(xiàng)目到達(dá)發(fā)布臨界點(diǎn)或者解決了一個(gè)嚴(yán)重的 BUG 后就會(huì)發(fā)布一個(gè) "service Release" 版本， 簡(jiǎn)稱 SR（X）版本，x 代表一個(gè)遞增數(shù)字。

• 引用自：
  聊聊Spring Cloud版本的那些事兒 - http://blog.didispace.com/springcloud-version/

Spring Cloud & Spring Boot 版本對(duì)照表

通過(guò)查閱官網(wǎng)：https://spring.io/projects/spring-cloud，我們可以看到一個(gè)「Release train Spring Boot compatibility」表：

上表可以看出，最新的「Spring Cloud」版本已經(jīng)出到了 Greenwich... 每個(gè)版本都能查閱到當(dāng)前版本所包含的子項(xiàng)目，以及子項(xiàng)目的版本號(hào)，我們可以通過(guò)此來(lái)決定需要選擇怎么樣的版本。

參考資料

1. 外行人都能看懂的SpringCloud，錯(cuò)過(guò)了血虧！ - https://juejin.im/post/5b83466b6fb9a019b421cecc#heading-19
2. 從架構(gòu)演進(jìn)的角度聊聊Spring Cloud都做了些什么？ - http://www.ityouknow.com/springcloud/2017/11/02/framework-and-springcloud.html
3. 聊聊Spring Cloud版本的那些事兒 - http://blog.didispace.com/springcloud-version/
4. Spring Cloud 從入門到精通 - http://blog.didispace.com/spring-cloud-learning/
5. Spring Cloud 中文網(wǎng) - https://springcloud.cc/

按照慣例黏一個(gè)尾巴：

歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)注明出處！
簡(jiǎn)書ID：@我沒(méi)有三顆心臟
github：wmyskxz
歡迎關(guān)注公眾微信號(hào)：wmyskxz
分享自己的學(xué)習(xí) & 學(xué)習(xí)資料 & 生活
想要交流的朋友也可以加qq群：3382693