利用Netflix所打造的組件及各類大家熟知的工具，我們完全可以順利應(yīng)對由微服務(wù)以及分布式計(jì)算所帶來的技術(shù)挑戰(zhàn)。

在過去一年當(dāng)中，微服務(wù)已經(jīng)成為軟件架構(gòu)領(lǐng)域一個(gè)炙手可熱的新名詞，而且我們也能輕松舉出由其帶來的諸多比較優(yōu)勢。然而，我們必須清醒意識到的是，一旦開始遵循微服務(wù)思路而對現(xiàn)有架構(gòu)體系進(jìn)行拆分，就意味著我們將不可避免地進(jìn)入分布式系統(tǒng)領(lǐng)域。在之前的文章中我們曾經(jīng)探討過分布式計(jì)算的八大認(rèn)識誤區(qū)*，由此可見此類系統(tǒng)本身充滿著風(fēng)險(xiǎn)，而且一旦犯下這八種錯(cuò)誤中的任何一種、我們都將面對災(zāi)難性的后果。

在我個(gè)人看來，如果要將這些誤區(qū)總結(jié)成一句觀點(diǎn)，那就是：對于一套分布式系統(tǒng)來說，任何關(guān)于一致性或者可靠性的表達(dá)都毫無保障可言。我們需要假定系統(tǒng)當(dāng)中的各種行為以及組件位置始終處于不斷變化狀態(tài)。由此產(chǎn)生的后果主要有兩點(diǎn)：組件有時(shí)候會導(dǎo)致糟糕的服務(wù)質(zhì)量甚至令服務(wù)直接離線，我們則只能將其統(tǒng)稱為“故障”、而很難具體闡明到底是哪里出了問題。一旦沒能得到妥善處理，此類故障將引中斷與停機(jī)，這意味著系統(tǒng)將無法按照既定設(shè)計(jì)方案為用戶提供服務(wù)項(xiàng)目。

有鑒于此，為了享受微服務(wù)所帶來的諸多優(yōu)勢(包括松散耦合、自治服務(wù)、分散化治理以及易于持續(xù)交付等等)，我們必須避免由單一故障依次遞進(jìn)而最終導(dǎo)致系統(tǒng)崩潰的恐怖狀況。關(guān)于這一點(diǎn)，Erlang語言之父Joe Armstrong曾經(jīng)在題為《如何構(gòu)建永遠(yuǎn)運(yùn)行、自我修復(fù)且可擴(kuò)展的系統(tǒng)》一文中作出過透徹的表述。在他看來，此類系統(tǒng)看起來與我們所說的微服務(wù)架構(gòu)非常相近，但其著重強(qiáng)調(diào)的是其作為自我修復(fù)系統(tǒng)的容錯(cuò)能力。那么對我們來說，如何才能建立起這樣一套堅(jiān)實(shí)可靠的系統(tǒng)方案?

Netflix公司在微服務(wù)架構(gòu)的實(shí)施與推動方面一直扮演著先行者的角色。作為其業(yè)務(wù)構(gòu)建的原則性方針之一，Netflix公司認(rèn)為系統(tǒng)方案必須要能夠承受任意組件的突發(fā)性故障，而整體系統(tǒng)仍能繼續(xù)正常運(yùn)轉(zhuǎn)(這意味著我們?nèi)匀荒軌蛟谠撈脚_上觀看電影，而Netflix也可以繼續(xù)記錄用戶的觀看喜好)。在嘗試建立這樣一套系統(tǒng)時(shí)，我們遭遇到以下這些常見的技術(shù)挑戰(zhàn)：

• 由于需要將系統(tǒng)拆分成多個(gè)分布式進(jìn)程，我們要如何在保證一致性與可靠性的前提下將這些配置分發(fā)至這些進(jìn)程當(dāng)中?
• 當(dāng)這些配置方案需要加以修改時(shí)，我們該如何在無需重新部署全部進(jìn)程的前提下對配置內(nèi)容進(jìn)行更新?
• 在這樣一套系統(tǒng)當(dāng)中，特別是對于部署于云環(huán)境內(nèi)的系統(tǒng)，各個(gè)進(jìn)程不僅內(nèi)容經(jīng)常變動、所在位置亦會不斷轉(zhuǎn)換(特別是在進(jìn)行故障轉(zhuǎn)移的情況下)。我們要如何準(zhǔn)確判斷那些需要進(jìn)行協(xié)同的進(jìn)程的具體位置?
• 一旦我們檢測到了當(dāng)前進(jìn)程關(guān)聯(lián)性的幾種可能位置，我們該如何選擇接下來要進(jìn)行通信的進(jìn)程實(shí)例?
• 假設(shè)在選定一個(gè)進(jìn)程實(shí)例并與該實(shí)例進(jìn)行通信的過程當(dāng)中該實(shí)例出現(xiàn)了故障，我們該如何防止由此引發(fā)的連鎖故障?
• 在系統(tǒng)綜合運(yùn)作行為不斷給自治服務(wù)帶來演進(jìn)拓?fù)浣Y(jié)構(gòu)的情況下，我們要如何對其狀態(tài)保持可視化監(jiān)控、從而作出有針對性的準(zhǔn)確調(diào)整?

事實(shí)上，大家可以部署多種樣板模式及開源工具來解決上述技術(shù)挑戰(zhàn)。Netflix公司就構(gòu)建出多種組件且加以開源，并在生產(chǎn)環(huán)境中進(jìn)行了一系列測試。從理論角度講，我們能夠利用這些工具來建立起有能力“永遠(yuǎn)運(yùn)行、自我修復(fù)且實(shí)現(xiàn)規(guī)?；瘮U(kuò)展”的系統(tǒng)。對剛剛著手建立分布式系統(tǒng)的朋友們來說，我們目前的第一要?jiǎng)?wù)在于理解這些實(shí)現(xiàn)模式、掌握Netflix組件并加以應(yīng)用，而后將這些組件部署、管理并集成至自己的系統(tǒng)當(dāng)中。由于采取任何新的技術(shù)依賴關(guān)系都會給軟件工程方案帶來前所未見的復(fù)雜性元素，因此我們建議大家最好直接采用Netflix的堆棧來盡可能減少此類潛在摩擦。

Spring工程技術(shù)團(tuán)隊(duì)從建立之初至今一直在努力打造出足以應(yīng)對Java復(fù)雜性的強(qiáng)大武器。我們的早期關(guān)注重點(diǎn)在于消除J2EE給企業(yè)級應(yīng)用程序開發(fā)者帶來的生產(chǎn)效率影響。而著眼于最近一段時(shí)間，我們的主要精力則轉(zhuǎn)移到了實(shí)現(xiàn)云-本地應(yīng)用程序構(gòu)建身上，而且這方面的大部分工作成果都被納入或者圍繞著Spring Cloud項(xiàng)目所展開。

Spring Cloud項(xiàng)目的既定目標(biāo)在于為Spring開發(fā)人員提供一整套易于使用的工具集，從而保證其輕松構(gòu)建起自己需要的分布式系統(tǒng)方案。為了實(shí)現(xiàn)這一目標(biāo)，Spring Cloud以Netflix OSS堆棧為基礎(chǔ)將大量實(shí)現(xiàn)堆棧加以整合并打包。這些堆棧而后可以通過大家所熟知的各類基于注釋的配置工具、Java配置工具以及基于模板的編程工具實(shí)現(xiàn)交付。下面就讓我們一起了解Spring Cloud當(dāng)中的幾類常見組件。

Spring Cloud Config Server

Spring Cloud Config Server能夠提供一項(xiàng)具備橫向擴(kuò)展能力的集中式配置服務(wù)。它所使用的數(shù)據(jù)被保存在一套可插拔庫層當(dāng)中，后者目前能夠支持本地存儲、Git以及Subversion。通過利用一套版本控制系統(tǒng)作為配置存儲方案，開發(fā)人員能夠輕松實(shí)現(xiàn)版本與審計(jì)配置的內(nèi)容調(diào)整。

圖一：Spring Cloud Config Server

配置內(nèi)容會以Java屬性或者YAML文件的形式體現(xiàn)。該Config Server會將這些文件合并為環(huán)境對象，其中包含易于理解的Spring屬性模型以及作為REST API存在的配置文件。任何應(yīng)用程序都能夠直接調(diào)用該REST API當(dāng)中所包含的配置數(shù)據(jù)，但我們也可以將智能客戶端綁定方案添加到Spring Boot應(yīng)用程序當(dāng)中，并由后者自動將接收自Config Server的配置信息分配至任意本地配置當(dāng)中。

Spring Cloud Bus

Spring Cloud Config Server是一套強(qiáng)大的配置分發(fā)機(jī)制，能夠在保障一致性的前提下將配置內(nèi)容分發(fā)到多個(gè)應(yīng)用程序?qū)嵗?dāng)中。然而根據(jù)其設(shè)計(jì)思路的限定，我們目前只能在應(yīng)用程序啟動時(shí)對其配置進(jìn)行更新。在向Git中的某一屬性發(fā)送新值時(shí)，我們需要以手動方式重啟每個(gè)應(yīng)用程序進(jìn)程，從而保證該值被切實(shí)納入應(yīng)用當(dāng)中。很明顯，大家需要能夠在無需重啟的前提下完成對應(yīng)用程序配置內(nèi)容的更新工作。

圖二: 配備Spring Cloud Bus的Spring Cloud Config Server

Spring Cloud Bus的任務(wù)正是為應(yīng)用程序?qū)嵗砑右惶坠芾肀嘲?。它目前依靠將一套客戶端綁定至一組AMQP交換與隊(duì)列當(dāng)中來實(shí)現(xiàn)，但這一后端在設(shè)計(jì)上也實(shí)現(xiàn)了可插拔特性。Spring Cloud Bus為我們的應(yīng)用程序帶來了更多管理端點(diǎn)。在圖二中，我們可以看到一個(gè)面向greeting屬性的值被發(fā)送至Git當(dāng)中，而后一條請求被發(fā)送至應(yīng)用A中的/bus/refresh端點(diǎn)。該請求會觸發(fā)以下三個(gè)事件：

1. 應(yīng)用A從Config Server處請求獲取最新版本的配置內(nèi)容。任意注明了@RefreshScope的Spring Bean都會被重新初始化并載入新的配置內(nèi)容。
2. 應(yīng)用A向AMQP交換機(jī)制發(fā)送一條消息，表明其已經(jīng)收到更新指示。
3. 通過監(jiān)聽AMQP隊(duì)列而被納入Cloud Bus的應(yīng)用B與應(yīng)用C會獲取到上述消息，并以與應(yīng)用A同樣的方式實(shí)現(xiàn)配置更新。

現(xiàn)在我們已經(jīng)有能力在無需重啟的情況下對應(yīng)用程序配置進(jìn)行更新了。

#p#

Spring Cloud Netflix

Spring Cloud Netflix針對多種Netflix組件提供打包方案，其中包括Eureka、Ribbon、Hystrix以及Zuul。接下來我將分別對它們作出講解。

Eureka是一套彈性服務(wù)注冊實(shí)現(xiàn)方案。其中服務(wù)注冊屬于服務(wù)發(fā)現(xiàn)模式的一種實(shí)現(xiàn)機(jī)制(如圖三所示)。

圖三：利用服務(wù)注冊實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)

Spring Cloud Netflix通過直接將spring-cloud-starter-eureka-server關(guān)聯(lián)性添加到Spring Boot應(yīng)用程序、隨后將該應(yīng)用程序的配置類與@EnableEurekaServer相整合的方式病嵌入式Eureka服務(wù)器的部署工作。

應(yīng)用程序能夠通過添加spring-cloud-starter-eureka關(guān)聯(lián)性并將其配置類與@EnableDiscoveryClient相整合的方式加入到服務(wù)發(fā)現(xiàn)流程當(dāng)中。通過整合，我們能夠?qū)⒔?jīng)過配置的適合DiscoveryClient實(shí)例注入至任意Spring Bean內(nèi)。在我們所列舉的實(shí)例中，DiscoveryClient作為服務(wù)發(fā)現(xiàn)的一種抽象機(jī)制恰好可以通過Eureka實(shí)現(xiàn)，不過大家也可以將其與Consul等其它備選堆棧相集成。DiscoveryClient能夠通過服務(wù)的邏輯標(biāo)識符提供位置信息(例如網(wǎng)絡(luò)地址)以及其它與已注冊至Eureka的服務(wù)實(shí)例相關(guān)的元數(shù)據(jù)。

Eureka提供的負(fù)載均衡機(jī)制僅支持單循環(huán)條件。而Ribbon提供的客戶端IPC庫則更為精巧，其同時(shí)具備可配置負(fù)載均衡機(jī)制與故障容錯(cuò)能力。Ribbon能夠通過獲取自Eureka服務(wù)器的動態(tài)服務(wù)器列表進(jìn)行內(nèi)容填充。Spring Cloud Netflix通過將spring-cloud-starter-ribbon關(guān)聯(lián)性添加至Spring Boot應(yīng)用程序的方式實(shí)現(xiàn)與Ribbon的集成。這套額外庫允許用戶將經(jīng)過適當(dāng)配置的LoadBalancerClient實(shí)例注入至Spring Bean當(dāng)中，從而實(shí)現(xiàn)客戶端負(fù)載均衡(如圖四所示)。

圖四：使用客戶端負(fù)載均衡機(jī)制

在此類任務(wù)當(dāng)中，我們可以利用Ribbon實(shí)現(xiàn)額外負(fù)載均衡算法，包括可用性過濾、加權(quán)響應(yīng)時(shí)間以及可用域親和等。

Spring Cloud Netflix還通過自動創(chuàng)建能夠被注入至任意Spring Bean的Ribbon強(qiáng)化型RestTemplate實(shí)例的方式進(jìn)一步改進(jìn)了Spring開發(fā)者的Ribbon使用方式。在此之后，開發(fā)人員能夠輕松將URL所提供的邏輯服務(wù)名稱遞交至RestTemplate：

@Autowired 
 
@LoadBalanced 
 
private RestTemplate restTemplate; 
 
@RequestMapping("/") 
 
public String consume() { 
 
ProducerResponse response = restTemplate.getForObject("http://producer", ProducerResponse.class); 
 
return String.format("{\"value\": %s}", response.getValue()); 
 
} 

Hystrix能夠?yàn)閿嗦菲饕约懊荛]閘門等分布式系統(tǒng)提供一套通用型故障容錯(cuò)實(shí)現(xiàn)模式。斷路器通常會被作為一臺狀態(tài)機(jī)使用，具體如圖五所示。

圖五：斷路器狀態(tài)機(jī)

斷路器能夠介于服務(wù)及其遠(yuǎn)程關(guān)聯(lián)性之間。如果該電路處于閉合狀態(tài)，則所有指向該關(guān)聯(lián)性的調(diào)用通常將直接通過。如果某一調(diào)用失敗，則故障將被計(jì)入計(jì)數(shù)。而一旦失敗次數(shù)達(dá)到可配置時(shí)間區(qū)間內(nèi)的閾值，該電路將被跳閘至斷開。在處于斷開狀態(tài)時(shí)，調(diào)用將不再被發(fā)往該關(guān)聯(lián)，而由此產(chǎn)生的結(jié)果將可自行定制(包括報(bào)告異常、返回虛假數(shù)據(jù)或者調(diào)用其它關(guān)聯(lián)等等)。

該狀態(tài)機(jī)會定期進(jìn)入所謂“半開”狀態(tài)，旨在檢測關(guān)聯(lián)性是否處于健康運(yùn)作狀態(tài)。在這種狀態(tài)下，請求一般仍將繼續(xù)得以通過。當(dāng)請求成功通過時(shí)，該設(shè)備會重新回歸閉合狀態(tài)。而如果請求失敗，則該設(shè)備會重新回歸斷開狀態(tài)。

#p#

Spring Cloud應(yīng)用程序能夠通過添加spring-cloud-starter-hystrix關(guān)聯(lián)性并將其配置類與@EnableCircuitBreaker相整合的方式利用Hystrix。在此之后，大家可以通過與@HystrixCommand整合的方式將斷路器機(jī)制納入到任意Spring Bean方法內(nèi)：

@HystrixCommand(fallbackMethod = "getProducerFallback") 
 
public ProducerResponse getValue() { 
 
return restTemplate.getForObject("http://producer", ProducerResponse.class); 
 
} 
 
以上實(shí)例中指定了一個(gè)名為getProducerFallback的備用方法。當(dāng)該斷路器處于斷開狀態(tài)時(shí)，此方法將替代getValue接受調(diào)用： 
 
private ProducerResponse getProducerFallback() { 
 
return new ProducerResponse(42); 
 
} 

除了實(shí)現(xiàn)狀態(tài)機(jī)機(jī)制之外，Hystrix還能夠提供來自各斷路機(jī)制的重要遙測指標(biāo)流，具體包括請求計(jì)量、響應(yīng)時(shí)間直方圖以及成功、失敗與短路請求數(shù)量等(如圖六所示)。

圖六：Hystrix儀表板

Zuul能夠處理全部指向Netflix邊緣服務(wù)的輸入請求。它能夠與Ribbon以及Hystrix等其它Netflix組件相結(jié)合，從而提供一個(gè)靈活且具有彈性的Netflix服務(wù)路由層。

Netflix公司在Zuul當(dāng)中加載動態(tài)過濾機(jī)制，從而實(shí)現(xiàn)以下各項(xiàng)功能：

• 驗(yàn)證與安全保障: 識別面向各類資源的驗(yàn)證要求并拒絕那些與要求不符的請求。
• 審查與監(jiān)控: 在邊緣位置追蹤有意義數(shù)據(jù)及統(tǒng)計(jì)結(jié)果，從而為我們帶來準(zhǔn)確的生產(chǎn)狀態(tài)結(jié)論。
• 動態(tài)路由: 以動態(tài)方式根據(jù)需要將請求路由至不同后端集群處。
• 壓力測試: 逐漸增加指向集群的負(fù)載流量，從而計(jì)算性能水平。
• 負(fù)載分配: 為每一種負(fù)載類型分配對應(yīng)容量，并棄用超出限定值的請求。
• 靜態(tài)響應(yīng)處理: 在邊緣位置直接建立部分響應(yīng)，從而避免其流入內(nèi)部集群。
• 多區(qū)域彈性: 跨越AWS區(qū)域進(jìn)行請求路由，旨在實(shí)現(xiàn)ELB使用多樣化并保證邊緣位置與使用者盡可能接近。

除此之外，Netflix公司還利用Zuul的功能通過金絲雀版本實(shí)現(xiàn)精確路由與壓力測試。

Spring Cloud已經(jīng)建立起一套嵌入式Zuul代理機(jī)制，從而簡化常見用例當(dāng)中UI應(yīng)用需要將調(diào)用代理至一項(xiàng)或者多項(xiàng)后端服務(wù)處的對應(yīng)開發(fā)流程。這項(xiàng)功能對于要求將用戶界面代理至后端服務(wù)的用例而言極為便捷，其避免了管理CORS(即跨域資源共享)以及為全部后端進(jìn)行獨(dú)立驗(yàn)證等復(fù)雜流程。Zuul代理機(jī)制的一類重要應(yīng)用在于實(shí)現(xiàn)API網(wǎng)關(guān)模式(如圖七所示)。

圖七：API網(wǎng)關(guān)模式

Spring Cloud對嵌入式Zuul代理進(jìn)行了強(qiáng)化，從而使其能夠自動實(shí)現(xiàn)文件上傳處理。而與Spring Cloud Security配合之后，其能夠輕松實(shí)現(xiàn)OAuth2 SSO以及將令牌傳遞至下游服務(wù)等工作。Zuul利用Ribbon作為其客戶端與全部出站請求的負(fù)載均衡機(jī)制。Ribbon的動態(tài)服務(wù)器列表內(nèi)容通常由Eureka負(fù)責(zé)填充，但Spring Cloud也能夠通過其它來源填充該列表。Spring Cloud Lattice項(xiàng)目就已經(jīng)能夠通過輪詢Cloud Foundry Diego的Receptor API填充Ribbon的服務(wù)器列表。

跨入微服務(wù)領(lǐng)域的決定意味著我們將正式迎接分布式系統(tǒng)所帶來的諸多挑戰(zhàn)，而分布式系統(tǒng)絕不是那種能夠“湊合使用”的方案。因此，我們必須假設(shè)系統(tǒng)內(nèi)各組件的行為及位置始終處于不斷變化當(dāng)中，甚至經(jīng)常表現(xiàn)出不可預(yù)知狀態(tài)。在今天的文章中，我們已經(jīng)談到了幾種能夠幫助大家解決此類挑戰(zhàn)的現(xiàn)成模式，而且這些模式已經(jīng)在Netflix OSS與Spring Cloud得到切實(shí)驗(yàn)證。我個(gè)人建議大家在著手建立理想中的“永遠(yuǎn)運(yùn)行、自我修復(fù)且具備可擴(kuò)展能力”的系統(tǒng)方案之前，首先對它們進(jìn)行一番嘗試與體驗(yàn)。

*備注：這八大誤區(qū)分別為：

1.網(wǎng)絡(luò)環(huán)境是可靠的

2.延遲水平為零

3.傳輸帶寬是無限的

4.網(wǎng)絡(luò)環(huán)境是安全的

5.拓?fù)浣Y(jié)構(gòu)不會變化

6.總會有管理員幫助解決問題

7.流量成本為零

8.網(wǎng)絡(luò)內(nèi)各組成部分擁有同質(zhì)性

原文標(biāo)題：Build self-healing distributed systems with Spring Cloud