微服务可靠性设计--转
原文地址：http://www.infoq.com/cn/articles/micro-service-reliability-design?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage
微服務(wù)可靠性設(shè)計(jì)
1. 背景
微服務(wù)化之后，系統(tǒng)分布式部署，傳統(tǒng)單個流程的本地API調(diào)用被拆分成多個微服務(wù)之間的跨網(wǎng)絡(luò)調(diào)用，由于引入了網(wǎng)絡(luò)通信、序列化和反序列化等操作，系統(tǒng)發(fā)生故障的概率提高了很多。
微服務(wù)故障，有些是由于業(yè)務(wù)自身設(shè)計(jì)或者編碼不當(dāng)導(dǎo)致，有些是底層的微服務(wù)化框架容錯能力不足導(dǎo)致。在實(shí)際項(xiàng)目中，需要從業(yè)務(wù)和平臺兩方面入手，提升微服務(wù)的可靠性。
1.1. 無處不在的故障
1.1.1. 分布式部署和調(diào)用
傳統(tǒng)單體架構(gòu)一個完整的業(yè)務(wù)流程往往在同一個進(jìn)程內(nèi)部完成處理，不需要進(jìn)行分布式協(xié)作，它的工作原理如下所示：
圖1-1 傳統(tǒng)單體架構(gòu)本地方法調(diào)用
微服務(wù)化之后，不同的微服務(wù)采用分布式集群部署方式，服務(wù)的消費(fèi)者和提供者通常運(yùn)行在不同的進(jìn)程中，需要跨網(wǎng)絡(luò)做RPC調(diào)用，它的工作原理如下所示：
圖1-2 微服務(wù)分布式RPC調(diào)用
分布式調(diào)用之后，相比于傳統(tǒng)單體架構(gòu)的本地方法調(diào)用，主要引入了如下潛在故障點(diǎn)：
- 序列化與反序列化：微服務(wù)的請求和應(yīng)答都需要經(jīng)過序列化和反序列化，做消息的跨網(wǎng)絡(luò)通信，由于數(shù)據(jù)結(jié)構(gòu)不一致、不支持的數(shù)據(jù)類型、對方編解碼錯誤等都會導(dǎo)致序列化和反序列化失敗，進(jìn)而導(dǎo)致微服務(wù)調(diào)用失敗。
- 網(wǎng)絡(luò)問題：常見的包括網(wǎng)絡(luò)超時、網(wǎng)絡(luò)閃斷、網(wǎng)絡(luò)單通、網(wǎng)絡(luò)擁塞等，都可能會導(dǎo)致微服務(wù)遠(yuǎn)程調(diào)用的失敗。
1.1.2. 大型系統(tǒng)微服務(wù)進(jìn)程內(nèi)合設(shè)
理想情況下，每個微服務(wù)都獨(dú)立打包和部署，微服務(wù)之間天然就支持進(jìn)程級隔離，但事實(shí)上，對于一個大規(guī)模的企業(yè)IT系統(tǒng)、或者大型網(wǎng)站，是由成百上千個微服務(wù)組成的，在實(shí)踐中，微服務(wù)通常是不可能做到百分之百獨(dú)立部署的，原因如下：
不同的微服務(wù)合設(shè)在同一個進(jìn)程之中，就會引入一系列潛在的故障點(diǎn)，例如：
- 處理較慢的微服務(wù)會阻塞其它微服務(wù)
- 某個微服務(wù)故障蔓延，可能導(dǎo)致整個進(jìn)程不可用
- 低優(yōu)先級的微服務(wù)，搶占高優(yōu)先級微服務(wù)的資源
1.1.3. 微服務(wù)健康度
傳統(tǒng)情況下，往往使用服務(wù)注冊中心檢測微服務(wù)的狀態(tài)，當(dāng)檢測到服務(wù)提供者不可用時，會將故障的服務(wù)信息廣播到集群所有節(jié)點(diǎn)，消費(fèi)者接收到服務(wù)故障通知消息之后，根據(jù)故障信息中的服務(wù)名稱、IP地址等信息，對故障節(jié)點(diǎn)進(jìn)行隔離。它的工作原理如下所示：
圖1-3 微服務(wù)狀態(tài)檢測
使用基于心跳或者會話的微服務(wù)狀態(tài)檢測，可以發(fā)現(xiàn)微服務(wù)所在進(jìn)程宕機(jī)、網(wǎng)絡(luò)故障等問題，但在實(shí)際業(yè)務(wù)中，微服務(wù)并非“非死即活”，它可能處于“亞健康狀態(tài)”，服務(wù)調(diào)用失敗率很高，但又不是全部失敗。或者微服務(wù)已經(jīng)處于過負(fù)荷流控狀態(tài)，業(yè)務(wù)質(zhì)量受損，但是又沒有全部中斷。
使用簡單的微服務(wù)狀態(tài)檢測，很難應(yīng)對上述這些場景。通過對微服務(wù)的運(yùn)行質(zhì)量建模，利用微服務(wù)健康度模型，根據(jù)采集的各種指標(biāo)對微服務(wù)健康度實(shí)時打分，依據(jù)打分結(jié)果采取相應(yīng)的可靠性對策，可以更有針對性的保障系統(tǒng)的可靠性。
1.1.4. 同步的I/O操作
在整個微服務(wù)調(diào)用過程中，主要會涉及到三類I/O操作：
- 網(wǎng)絡(luò)I/O操作，涉及到網(wǎng)絡(luò)讀寫
- 磁盤I/O操作，主要是記錄日志、話單、寫本地文件等
- 數(shù)據(jù)庫訪問，例如Java使用JDBC驅(qū)動進(jìn)行數(shù)據(jù)庫操作
圖1-4 微服務(wù)涉及的主要I/O操作
凡是涉及到I/O操作的，如果I/O操作是同步阻塞模式，例如Java的BIO、文件File的讀寫操作、數(shù)據(jù)庫訪問的JDBC接口等，都是同步阻塞的。只要訪問的網(wǎng)絡(luò)、磁盤或者數(shù)據(jù)庫實(shí)例比較慢，都會導(dǎo)致調(diào)用方線程的阻塞。由于線程是Java虛擬機(jī)比較重要的資源，當(dāng)大量微服務(wù)調(diào)用線程被阻塞之后，系統(tǒng)的吞吐量將嚴(yán)重下降。
1.1.5. 第三方SDK API調(diào)用
在微服務(wù)中，調(diào)用第三方SDK API，也可能會引入新的故障點(diǎn)，例如通過FTP客戶端訪問遠(yuǎn)端的FTP服務(wù)，或者使用MQ客戶端訪問MQ服務(wù)，如果這些客戶端API的容錯性設(shè)計(jì)不好，也會導(dǎo)致調(diào)用方的級聯(lián)故障，這些故障是潛在和隱性的，在設(shè)計(jì)的時候往往容易被忽視，但它帶來的風(fēng)險(xiǎn)和危害是巨大的。
1.2. 微服務(wù)可靠性
軟件可靠性是指在給定時間內(nèi)，特定環(huán)境下軟件無錯運(yùn)行的概率。軟件可靠性包含了以下三個要素：
1) 規(guī)定的時間：軟件可靠性只是體現(xiàn)在其運(yùn)行階段，所以將運(yùn)行時間作為規(guī)定的時間的度量。運(yùn)行時間包括軟件系統(tǒng)運(yùn)行后工作與掛起(啟動但空閑)的累計(jì)時間。由于軟件運(yùn)行的環(huán)境與程序路徑選取的隨機(jī)性，軟件的失效為隨機(jī)事件，所以運(yùn)行時間屬于隨機(jī)變量。
2) 規(guī)定的環(huán)境條件:環(huán)境條件指軟件的運(yùn)行環(huán)境。它涉及軟件系統(tǒng)運(yùn)行時所需的各種支持要素，如支持硬件、操作系統(tǒng)、其它支持軟件、輸入數(shù)據(jù)格式和范圍以及操作規(guī)程等。
3) 規(guī)定的功能:軟件可靠性還與規(guī)定的任務(wù)和功能有關(guān)。由于要完成的任務(wù)不同，則調(diào)用的子模塊就不同(即程序路徑選擇不同)，其可靠性也就可能不同。所以要準(zhǔn)確度量軟件系統(tǒng)的可靠性必須首先明確它的任務(wù)和功能。
1.2.1. 關(guān)鍵的可靠性因素
微服務(wù)的運(yùn)行質(zhì)量，除了自身的可靠性因素之外，還受到其它因素的影響，包括網(wǎng)絡(luò)、數(shù)據(jù)庫訪問、其它相關(guān)聯(lián)的微服務(wù)運(yùn)行質(zhì)量等。微服務(wù)的可靠性設(shè)計(jì)，需要考慮上述綜合因素，總結(jié)如下：
圖1-5 微服務(wù)可靠性設(shè)計(jì)模型
2. 異步I/O操作
2.1. 網(wǎng)絡(luò)I/O
2.1.1. 使用同步阻塞I/O的問題
以Java為例，在JDK 1.4推出JAVA NIO1.0之前，基于JAVA的所有Socket通信都采用了同步阻塞模式（BIO），這種一請求一應(yīng)答的通信模型簡化了上層的應(yīng)用開發(fā)，但是在可靠性和性能方面存在巨大的弊端：
2-1 傳統(tǒng)Java 同步阻塞I/O模型
采用BIO通信模型的服務(wù)端，通常由一個獨(dú)立的Acceptor線程負(fù)責(zé)監(jiān)聽客戶端的連接，接收到客戶端連接之后為客戶端連接創(chuàng)建一個新的線程處理請求消息，處理完成之后，返回應(yīng)答消息給客戶端，線程銷毀，這就是典型的一請求一應(yīng)答模型。該架構(gòu)最大的問題就是不具備彈性伸縮能力，當(dāng)并發(fā)訪問量增加后，服務(wù)端的線程個數(shù)和并發(fā)訪問數(shù)成線性正比，由于線程是JAVA虛擬機(jī)非常寶貴的系統(tǒng)資源，當(dāng)線程數(shù)膨脹之后，系統(tǒng)的性能急劇下降，隨著并發(fā)量的繼續(xù)增加，可能會發(fā)生句柄溢出、線程堆棧溢出等問題，并導(dǎo)致服務(wù)器最終宕機(jī)。
2.1.2. 使用非阻塞I/O通信
微服務(wù)進(jìn)行遠(yuǎn)程通信時，通過使用非阻塞I/O，可以解決由于網(wǎng)絡(luò)時延大、高并發(fā)接入等導(dǎo)致的服務(wù)端線程數(shù)膨脹或者線程被阻塞等問題。
以Java為例，從JDK1.4開始，JDK提供了一套專門的類庫支持非阻塞I/O，可以在java.nio包及其子包中找到相關(guān)的類和接口。JDK1.7之后，又提供了NIO2.0類庫，支持異步I/O操作。
利用JDK的異步非阻塞I/O，可以實(shí)現(xiàn)一個I/O線程同時處理多個客戶端鏈路，讀寫操作不會因?yàn)榫W(wǎng)絡(luò)原因被阻塞，I/O線程可以高效的并發(fā)處理多個客戶端鏈路，實(shí)現(xiàn)I/O多路復(fù)用，它的工作原理如下所示：
2-2 Java非阻塞I/O模型
使用非阻塞I/O進(jìn)行通信，以Java語言為例，建議策略如下：
1) TCP私有協(xié)議：建議直接基于Netty開發(fā)。
2) HTTP/Restful/SOAP等：選擇支持非阻塞I/O的Web框架。也可以選擇基于Netty構(gòu)建的開源應(yīng)用層協(xié)議棧框架，例如支持異步Restful的RestExpress。
2.2. 磁盤I/O
微服務(wù)對磁盤I/O的操作分為兩類：
- 直接文件操作：例如調(diào)用File的open、write、read等接口，進(jìn)行文件操作。
- 間接文件操作：例如調(diào)用日志類庫寫日志，雖然微服務(wù)并沒有直接操作日志文件，但是日志類庫底層還是會進(jìn)行文件的讀寫等操作。
在實(shí)際項(xiàng)目中，最容易被忽視的就是日志操作。不同的日志類庫，寫日志的機(jī)制不同，以Log4j 1.2.X版本為例，當(dāng)日志隊(duì)列滿之后，有多種策略：
- 同步等待，直到新的日志消息能夠入隊(duì)列，它會阻塞當(dāng)前業(yè)務(wù)線程。
- 丟棄當(dāng)前的日志消息，不會阻塞當(dāng)前業(yè)務(wù)線程。
- 不入隊(duì)列，由當(dāng)前調(diào)用寫日志的業(yè)務(wù)線程執(zhí)行日志I/O操作，如果此時磁盤I/O寫入速度慢，則會阻塞當(dāng)前業(yè)務(wù)線程。
在實(shí)際生產(chǎn)環(huán)境中，我們就遇到過類似問題，在某些時段，磁盤WIO達(dá)到10+持續(xù)幾秒鐘-10幾秒鐘，然后又恢復(fù)正常。WIO較高的時段，需要寫接口日志、話單等，由于系統(tǒng)默認(rèn)采用的是同步等待策略，結(jié)果導(dǎo)致通信I/O線程、微服務(wù)調(diào)度線程等都被阻塞，最終鏈路因?yàn)樾奶瑫r被強(qiáng)制關(guān)閉、微服務(wù)被大量阻塞在消息隊(duì)列中導(dǎo)致內(nèi)存居高不小、響應(yīng)超時等。
由于偶現(xiàn)的WIO高導(dǎo)致同步寫日志被阻塞，繼而引起通信線程、微服務(wù)調(diào)用線程級聯(lián)故障，定位起來非常困難，平時Code Review也很難被注意到。所以，隱性的磁盤I/O操作，更需要格外關(guān)注。
要解決上面的問題，有三種策略：
- 使用非阻塞I/O,對文件進(jìn)行異步讀寫操作。
- 業(yè)務(wù)層面封裝一個異步的I/O操作，最簡單的策略就是由一個獨(dú)立的線程或者線程池來執(zhí)行磁盤I/O操作。
- 選擇支持非阻塞方式調(diào)用的I/O類庫，例如使用log4j的異步日志API。
以JDK1.7為例，它提供了異步的文件I/O操作類庫，基于該類庫，就不需要擔(dān)心磁盤I/O操作被阻塞：
2-3 JDK1.7異步非阻塞文件接口
自己在上層封裝異步I/O操作，也比較簡單，它的優(yōu)點(diǎn)是可以實(shí)現(xiàn)磁盤I/O操作與微服務(wù)之間的線程隔離，但是底層仍然使用的是同步阻塞I/O，如果此時磁盤的I/O比較高，依然會阻塞寫磁盤的I/O線程。它的原理如下所示：
2-4 應(yīng)用層封裝的異步文件操作
將文件I/O操作封裝成一個Task或者Event，投遞到文件I/O線程池的消息隊(duì)列中，根據(jù)投遞結(jié)果，構(gòu)造I/O操作相關(guān)聯(lián)的Future對象給微服務(wù)調(diào)用線程。通過向Future對象注冊Listener并實(shí)現(xiàn)callback接口，可以實(shí)現(xiàn)異步回調(diào)通知，這樣微服務(wù)和文件I/O操作就實(shí)現(xiàn)了線程隔離。文件I/O操作耗時，并不會阻塞微服務(wù)調(diào)度線程。
當(dāng)使用第三方文件I/O操作類庫時，需要注意下相關(guān)API，盡量使用支持異步非阻塞接口的API，如果沒有，則需要考慮是否做上層的異步封裝。
2.3. 數(shù)據(jù)庫操作
部分?jǐn)?shù)據(jù)庫訪問支持非阻塞方式，例如Oracle的OCI，它支持non-blocking模式和blocking模式：阻塞方式就是當(dāng)調(diào)用 OCI操作時，必須等到此OCI操作完成后服務(wù)器才返回客戶端相應(yīng)的信息，不管是成功還是失敗。非阻塞方式是當(dāng)客戶端提交OCI操作給服務(wù)器后，服務(wù)器立即返回OCI_STILL_EXECUTING信息，而并不等待服務(wù)端的操作完成。對于non-blocking方式，應(yīng)用程序若收到一個OCI函數(shù)的返回值為OCI_STILL_EXECUTING時必須再次對每一個OCI函數(shù)的返回值進(jìn)行判斷，判斷其成功與否。 可通過設(shè)置服務(wù)器屬性為OCI_ATTR_NONBLOCKING_MODE來實(shí)現(xiàn)。
對于Java語言而言，由于JDK本身提供了數(shù)據(jù)庫連接驅(qū)動相關(guān)的接口定義，JDBC驅(qū)動本身就是同步API接口，因此，Java語言的開源ORM框架也都是同步阻塞的，例如MyBatis、Hibernate等。
盡管大部分?jǐn)?shù)據(jù)庫訪問接口是同步阻塞的，但是由于數(shù)據(jù)庫中間件的超時控制機(jī)制都比較成熟，因此通過合理設(shè)置超時時間，可以避免微服務(wù)的數(shù)據(jù)庫訪問被長時間掛住。
也可以在應(yīng)用上層封裝異步數(shù)據(jù)庫操作層，實(shí)現(xiàn)微服務(wù)調(diào)度與數(shù)據(jù)庫操作的線程級隔離，原理2.2章節(jié)已經(jīng)介紹過，采用該方式同樣存在兩點(diǎn)不足：
- 排隊(duì)現(xiàn)象：如果某個數(shù)據(jù)庫操作非常耗時，超時時間配置的又比較大（例如30S），會導(dǎo)致后續(xù)的數(shù)據(jù)庫操作在隊(duì)列中排隊(duì)。
- 無法充分發(fā)揮數(shù)據(jù)庫效能：由于底層數(shù)據(jù)庫訪問采用同步阻塞的方式，所以不能高效發(fā)揮數(shù)據(jù)庫的效能。
3. 故障隔離
由于大部分微服務(wù)采用同步接口調(diào)用，而且多個領(lǐng)域相關(guān)的微服務(wù)會部署在同一個進(jìn)程中，很容易發(fā)生“雪崩效應(yīng)”，即某個微服務(wù)提供者故障，導(dǎo)致調(diào)用該微服務(wù)的消費(fèi)者、或者與故障微服務(wù)合設(shè)在同一個進(jìn)程中的其它微服務(wù)發(fā)生級聯(lián)故障，最終導(dǎo)致系統(tǒng)崩潰。
為了避免“雪崩效應(yīng)”的發(fā)生，需要支持多種維度的依賴和故障隔離，以實(shí)現(xiàn)微服務(wù)的HA。
3.1. 通信鏈路隔離
由于網(wǎng)絡(luò)通信本身通常不是系統(tǒng)的瓶頸，因此大部分服務(wù)框架會采用多線程+單個通信鏈路的方式進(jìn)行通信，原理如下所示：
3-1 多線程-單鏈路P2P通信模式
正如前面章節(jié)所述，由于微服務(wù)使用異步非阻塞通信，單個I/O線程可以同時并發(fā)處理多個鏈路的消息，而且網(wǎng)絡(luò)讀寫都是非阻塞的，因此采用多線程+單鏈路的方式進(jìn)行通信性能本身問題不大。但是從可靠性角度來看，只支持單鏈路本身又存在一些可靠性隱患，我們從下面的案例中看下問題所在。
某互聯(lián)網(wǎng)基地微服務(wù)架構(gòu)上線之后，發(fā)現(xiàn)在一些時段，經(jīng)常有業(yè)務(wù)超時，超時的業(yè)務(wù)沒有固定規(guī)律。經(jīng)定位發(fā)現(xiàn)當(dāng)有較多的批量內(nèi)容同步、語音和視頻類微服務(wù)調(diào)用時，系統(tǒng)的整體時延就增高了很多，而且存在較突出的時延毛刺。由于這些操作獲取的消息碼流往往達(dá)到數(shù)M到數(shù)十兆，微服務(wù)之間又采用單鏈路的方式進(jìn)行P2P通信，導(dǎo)致大碼流的傳輸影響了其它消息的讀寫效率，增大了微服務(wù)的響應(yīng)時延。
問題定位出來之后，對微服務(wù)之間的通信機(jī)制做了優(yōu)化，節(jié)點(diǎn)之間支持配置多鏈路，每個鏈路之間還可以實(shí)現(xiàn)不同策略的隔離，例如根據(jù)消息碼流大小、根據(jù)微服務(wù)的優(yōu)先級等策略，實(shí)現(xiàn)鏈路級的隔離，優(yōu)化之后的微服務(wù)通信機(jī)制：
圖3-2 支持多鏈路隔離
3.2. 調(diào)度資源隔離
3.2.1. 微服務(wù)之間隔離
當(dāng)多個微服務(wù)合設(shè)運(yùn)行在同一個進(jìn)程內(nèi)部時，可以利用線程實(shí)現(xiàn)不同微服務(wù)之間的隔離。
對于核心微服務(wù)，發(fā)布的時候可以獨(dú)占一個線程/線程池，對于非核心微服務(wù)，則可以共享同一個大的線程池，在實(shí)現(xiàn)微服務(wù)隔離的同時，避免線程過于膨脹：
圖3-3 微服務(wù)之間故障隔離
假如非核心服務(wù)3發(fā)生故障，長時間阻塞線程池1的工作線程，其它與其共用線程池消息隊(duì)列的非核心服務(wù)1和服務(wù)2只能在隊(duì)列中排隊(duì)等待，當(dāng)服務(wù)3釋放線程之后，排隊(duì)的服務(wù)1和服務(wù)2可能已經(jīng)超時，只能被丟棄掉，導(dǎo)致業(yè)務(wù)處理失敗。
采用線程池隔離的核心服務(wù)1和服務(wù)2，由于各自獨(dú)占線程池，擁有獨(dú)立的消息隊(duì)列，它的執(zhí)行不受發(fā)生故障的非核心服務(wù)1影響，因此可以繼續(xù)正常工作。通過獨(dú)立線程池部署核心服務(wù)，可以防止故障擴(kuò)散，保障核心服務(wù)的正常運(yùn)行。
3.2.2. 第三方依賴隔離
在微服務(wù)中通常會調(diào)用第三方中間件服務(wù)，例如分布式緩存服務(wù)、分布式消息隊(duì)列、NoSQL服務(wù)等。只要調(diào)用第三方服務(wù)，就會涉及跨網(wǎng)絡(luò)操作，由于客戶端SDK API的封裝，很多故障都是隱性的，因此，它的可靠性需要額外關(guān)注。
整體而言，第三方依賴隔離可以采用線程池 + 響應(yīng)式編程（例如RxJava）的方式實(shí)現(xiàn)，它的原理如下所示：
1) 對第三方依賴進(jìn)行分類，每種依賴對應(yīng)一個獨(dú)立的線程/線程池。
2) 微服務(wù)不直接調(diào)用第三方依賴的API，而是使用異步封裝之后的API接口。
3) 異步調(diào)用第三方依賴API之后，獲取Future對象。利用響應(yīng)式編程框架，可以訂閱后續(xù)的事件，接收響應(yīng)，針對響應(yīng)進(jìn)行編程。
利用Netflix開源的hystrix + RxJava，可以快速實(shí)現(xiàn)第三方依賴的隔離，后續(xù)章節(jié)我們會詳細(xì)介紹下如何使用。
3.3. 進(jìn)程級隔離
對于核心的微服務(wù)，例如商品購買、用戶注冊、計(jì)費(fèi)等，可以采用獨(dú)立部署的方式，實(shí)現(xiàn)高可用性。
3.3.1. 容器隔離
微服務(wù)鼓勵軟件開發(fā)者將整個軟件解耦為功能單一的服務(wù)，并且這些服務(wù)能夠獨(dú)立部署、升級和擴(kuò)容。如果微服務(wù)抽象的足夠好，那么微服務(wù)的這一優(yōu)點(diǎn)將能夠提升應(yīng)用的敏捷性和自治理能力。
利用Docker容器部署微服務(wù)，可以帶來如下幾個優(yōu)點(diǎn)：
- 高效：Docker容器的啟動和停止不需要幾分鐘，只要幾百毫秒就足夠了。使用Docker部署微服務(wù)，微服務(wù)的啟動和銷毀速度非常快，在高壓力時，可以實(shí)現(xiàn)秒級彈性伸縮。
- 高性能：Docker容器的性能接近裸的物理機(jī)，比VM平均高20%+。
- 隔離性：利用Docker，可以實(shí)現(xiàn)0.1 core的隔離。基于細(xì)粒度的資源隔離機(jī)制，可以實(shí)現(xiàn)高密度的部署微服務(wù)，同時實(shí)現(xiàn)它們之間的資源層隔離，保障微服務(wù)的可靠性。
- 可移植性：在基于虛擬機(jī)的解決方案中，應(yīng)用的可移植性通常來說會受到云提供商所提供的虛擬機(jī)格式限制。如果應(yīng)用程序需要部署到不同類型的虛擬機(jī)中，需要針對特定的虛擬機(jī)格式做鏡像文件，新增很多額外的開發(fā)和測試工作量。Docker容器的設(shè)計(jì)理念是“一次編寫，到處運(yùn)行”，這可以使開發(fā)者避免上面這種限制。
基于Docker容器部署微服務(wù)，實(shí)現(xiàn)物理資源層隔離示意圖如下所示：
圖3-4? 基于Docker容器的微服務(wù)隔離
3.3.2. VM隔離
除了Docker容器隔離，也可以使用VM對微服務(wù)進(jìn)行故障隔離，相比于Docker容器，使用VM進(jìn)行微服務(wù)隔離存在如下優(yōu)勢：
4. 集群容錯
當(dāng)微服務(wù)不可用時，需要根據(jù)預(yù)置的策略做容錯處理，大部分的容錯能力和策略是公共的，因此可以下沉到服務(wù)框架中實(shí)現(xiàn)。
4.1. 路由容錯
當(dāng)集群環(huán)境中微服務(wù)調(diào)用失敗之后，利用路由容錯機(jī)制，可以在底層實(shí)現(xiàn)微服務(wù)的自動容錯處理，提升系統(tǒng)的可靠性。
常用的容錯策略包括：
- 失敗自動切換機(jī)制：微服務(wù)調(diào)用失敗自動切換策略指的是當(dāng)發(fā)生服務(wù)調(diào)用異常時，重新選路，查找下一個可用的微服務(wù)提供者。微服務(wù)發(fā)布的時候，可以指定服務(wù)的集群容錯策略。消費(fèi)者可以覆蓋服務(wù)提供者的通用配置，實(shí)現(xiàn)個性化的容錯策略。
- 失敗回調(diào)機(jī)制：微服務(wù)調(diào)用失敗之后，提供異常回調(diào)接口，執(zhí)行微服務(wù)消費(fèi)者自定義的失敗處理邏輯。
- 快速失敗機(jī)制：在業(yè)務(wù)高峰期，對于一些非核心的服務(wù)，希望只調(diào)用一次，失敗也不再重試，為重要的核心服務(wù)節(jié)約寶貴的運(yùn)行資源。此時，快速失敗是個不錯的選擇。快速失敗策略的設(shè)計(jì)比較簡單，獲取到服務(wù)調(diào)用異常之后，直接忽略異常，記錄異常日志。
4.2. 服務(wù)降級
大促或者業(yè)務(wù)高峰時，為了保證核心服務(wù)的SLA，往往需要停掉一些不太重要的業(yè)務(wù)，例如商品評論、論壇或者粉絲積分等。
另外一種場景就是某些服務(wù)因?yàn)槟撤N原因不可用，但是流程不能直接失敗，需要本地Mock服務(wù)端實(shí)現(xiàn)，做流程放通。以圖書閱讀為例，如果用戶登錄余額鑒權(quán)服務(wù)不能正常工作，需要做業(yè)務(wù)放通，記錄消費(fèi)話單，允許用戶繼續(xù)閱讀，而不是返回失敗。
通過服務(wù)治理的服務(wù)降級功能，即可以滿足上述兩種場景的需求。
4.2.1. 強(qiáng)制降級
當(dāng)外界的觸發(fā)條件達(dá)到某個臨界值時，由運(yùn)維人員/開發(fā)人員決策，對某類或者某個服務(wù)進(jìn)行強(qiáng)制降級。
強(qiáng)制降級的常用策略：
4.2.2. 容錯降級
當(dāng)非核心服務(wù)不可用時，可以對故障服務(wù)做業(yè)務(wù)邏輯放通，以保障核心服務(wù)的運(yùn)行。
容錯降級與屏蔽降級的主要差異是：
容錯降級的常用策略如下：
4.2.3. 服務(wù)降級Portal
利用服務(wù)治理Portal，可以在線的動態(tài)修改微服務(wù)的降級策略，實(shí)時生效，它的界面如下所示：
圖4-1 服務(wù)降級配置界面
4.3. 熔斷機(jī)制
熔斷機(jī)制（Circuit Breaker），也叫自動停盤機(jī)制，是指當(dāng)股指波幅達(dá)到規(guī)定的熔斷點(diǎn)時，交易所為控制風(fēng)險(xiǎn)采取的暫停交易措施。
在微服務(wù)領(lǐng)域，熔斷機(jī)制是從消費(fèi)端保護(hù)微服務(wù)提供者的措施，當(dāng)微服務(wù)的運(yùn)行質(zhì)量低于某個臨界值時，啟動熔斷機(jī)制，暫停微服務(wù)調(diào)用一段時間，以保障后端的微服務(wù)不會因?yàn)槌掷m(xù)過負(fù)荷而宕機(jī)。
4.3.1. 工作原理
微服務(wù)的熔斷機(jī)制原理如下所示：
它的工作原理示意如下：
圖4-2 微服務(wù)熔斷器工作原理
熔斷器機(jī)制能保證微服務(wù)消費(fèi)者在微服務(wù)運(yùn)行狀態(tài)不佳時，快速返回結(jié)果，避免大量的同步等待。并且能在指定周期T后繼續(xù)偵測微服務(wù)是否可用, 以實(shí)現(xiàn)故障恢復(fù)之后的自動感知。
4.3.2. 微服務(wù)健康度
熔斷器開關(guān)的狀態(tài)取決于微服務(wù)的運(yùn)行質(zhì)量，微服務(wù)的運(yùn)行質(zhì)量通常由多種因素決定，具有多個衡量因子。通過對微服務(wù)健康度建模，可以實(shí)現(xiàn)對微服務(wù)運(yùn)行質(zhì)量的360°實(shí)時評估。
微服務(wù)健康度模型如下所示：
圖4-3 微服務(wù)健康度模型
微服務(wù)運(yùn)維體系通過分布式日志采集系統(tǒng)、告警系統(tǒng)、性能KPI數(shù)據(jù)采集等，利用在線大數(shù)據(jù)實(shí)時分析技術(shù)，通過健康度模型，對微服務(wù)的健康度按照周期進(jìn)行實(shí)時打分，同時將微服務(wù)的得分通過消息隊(duì)列訂閱發(fā)布出去，各個節(jié)點(diǎn)訂閱微服務(wù)的健康度得分，與熔斷器閾值進(jìn)行比較，修改熔斷器開關(guān)的狀態(tài)。
5. 流量控制
當(dāng)資源成為瓶頸時，服務(wù)框架需要對消費(fèi)者做限流，啟動流控保護(hù)機(jī)制。流量控制有多種策略，比較常用的有：針對訪問速率的靜態(tài)流控、針對資源占用的動態(tài)流控等。
在實(shí)踐中，各種流量控制策略需要綜合使用才能起到較好的效果。
5.1. 動態(tài)流控
動態(tài)流控的最終目標(biāo)是為了保命，并不是對流量或者訪問速度做精確控制。當(dāng)系統(tǒng)負(fù)載壓力非常大時，系統(tǒng)進(jìn)入過負(fù)載狀態(tài)，可能是CPU、內(nèi)存資源已經(jīng)過載，也可能是應(yīng)用進(jìn)程內(nèi)部的資源幾乎耗盡，如果繼續(xù)全量處理業(yè)務(wù)，可能會導(dǎo)致消息嚴(yán)重積壓或者應(yīng)用進(jìn)程宕機(jī)。
動態(tài)流控檢測的資源包括：
- CPU使用率。
- 內(nèi)存使用率（對于Java，主要是JVM內(nèi)存使用率）。
- 隊(duì)列積壓率。
主機(jī)CPU、內(nèi)存使用率采集算法非常多，例如使用java.lang.Process執(zhí)行top、sar等外部命令獲取系統(tǒng)資源使用情況，然后解析后計(jì)算獲得資源使用率。也可以直接讀取操作系統(tǒng)的系統(tǒng)文件獲取相關(guān)數(shù)據(jù)，需要注意的是，無論是執(zhí)行操作系統(tǒng)的本地命令，還是直接讀取操作系統(tǒng)的資源使用率文件，都是操作系統(tǒng)本地相關(guān)的，不同的操作系統(tǒng)和服務(wù)器，命令和輸出格式可能存在很大差異。在計(jì)算時需要首先判斷操作系統(tǒng)類型，然后調(diào)用相關(guān)操作系統(tǒng)的資源采集接口實(shí)現(xiàn)類，通過這種方式就可以支持跨平臺。
動態(tài)流控是分級別的，不同級別拒掉的消息比例不同，這取決于資源的負(fù)載使用情況。例如當(dāng)發(fā)生一級流控時，拒絕掉1/4的消息；發(fā)生二級流控時，拒絕掉1/2消息；發(fā)生三級流控時，所有的消息都被流控掉。
不同的級別有不同的流控閾值，系統(tǒng)上線后會提供默認(rèn)的；流控閾值，不同流控因子的流控閾值不同，業(yè)務(wù)上線之后通常會根據(jù)現(xiàn)場的實(shí)際情況做閾值調(diào)優(yōu)，因此流控閾值需要支持在線修改和動態(tài)生效。
需要指出的是為了防止系統(tǒng)波動導(dǎo)致的偶發(fā)性流控，無論是進(jìn)入流控狀態(tài)還是從流控狀態(tài)恢復(fù)，都需要連續(xù)采集N次并計(jì)算平均值，如果連續(xù)N次平均值大于流控閾值，則進(jìn)入流控狀態(tài)；同理，只有連續(xù)N次資源使用率平均值低于流控閾值，才能脫離流控恢復(fù)正常。
5.2. 靜態(tài)流控
靜態(tài)流控主要針對客戶端訪問速率進(jìn)行控制，它通常根據(jù)服務(wù)質(zhì)量等級協(xié)定（SLA）中約定的QPS做全局流量控制，例如計(jì)費(fèi)服務(wù)的靜態(tài)流控閾值為200 QPS，則無論集群有多少個計(jì)費(fèi)服務(wù)實(shí)例，它們總的處理速率之和不能超過200 QPS。
由于微服務(wù)具備彈性伸縮、動態(tài)上線和下線等特性，因此集群中某個微服務(wù)實(shí)例的節(jié)點(diǎn)個數(shù)是動態(tài)變化的，采用傳統(tǒng)的平均分配制無法做到精準(zhǔn)的控制。
在實(shí)踐中，比較成熟的集群靜態(tài)流控策略是動態(tài)配額申請制，它的工作原理如下：
5.3. 用戶自定義流控機(jī)制
不同的業(yè)務(wù)，存在不同的流控策略，例如基于微服務(wù)優(yōu)先級的流控、基于節(jié)假日的流控、基于業(yè)務(wù)字段的流控等。底層的服務(wù)框架無法實(shí)現(xiàn)所有業(yè)務(wù)級的定制流控策略，因此，過于業(yè)務(wù)化的流控往往由業(yè)務(wù)通過自定義流控機(jī)制定制實(shí)現(xiàn)。
服務(wù)框架提供服務(wù)調(diào)用入口的攔截點(diǎn)和切面接口，由業(yè)務(wù)實(shí)現(xiàn)自定義流控。也可以提供基礎(chǔ)的流控框架，供業(yè)務(wù)實(shí)現(xiàn)流控條件判斷、流控執(zhí)行策略等，簡化業(yè)務(wù)的定制工作量。
6. 使用Hystrix提升微服務(wù)可靠性
6.1. Hystrix簡介
Hystrix是Netflix開源的一個可靠性組件，主要用于分布式環(huán)境中的依賴解耦，Hystrix library通過添加延遲容忍和容錯邏輯來控制分布式服務(wù)之間的相互影響，通過服務(wù)之間訪問的隔離點(diǎn)阻止連鎖故障，并提供了失敗回調(diào)機(jī)制，來改進(jìn)系統(tǒng)的可靠性。
Hystrix提供如下機(jī)制來提升分布式系統(tǒng)的可靠性：
- 保護(hù)通過第三方客戶端API依賴訪問，控制其延遲和故障
- 阻止級聯(lián)故障和“雪崩效應(yīng)”
- 提供熔斷機(jī)制，快速失敗和恢復(fù)
- 失敗回調(diào)和優(yōu)雅降級機(jī)制
- 近實(shí)時檢測、報(bào)警和KPI指標(biāo)展示
6.2. Hystrix的核心功能
Hystrix提供了一些非常有價(jià)值、與具體微服務(wù)框架實(shí)現(xiàn)無關(guān)的特性，方便不同的分布式系統(tǒng)集成使用。
6.2.1. 依賴隔離
Hystrix使用命令模式HystrixCommand(Command)包裝依賴調(diào)用邏輯，每個命令在單獨(dú)線程/信號授權(quán)下執(zhí)行。依賴調(diào)用的超時時間可配置，如果超時，則則返回失敗或者執(zhí)行fallback邏輯。原理如下所示：
圖6-1 基于線程/信號的依賴隔離
6.2.2. 熔斷器
Hystrix會先經(jīng)過熔斷器，此時如果熔斷器的狀態(tài)是打開，則說明已經(jīng)熔斷，這時將直接進(jìn)行降級處理，不會繼續(xù)將請求發(fā)到線程池。
熔斷器的開關(guān)狀態(tài)由熔斷算法決定，它的原理如下：
- 判斷是否熔斷：根據(jù)bucket中記錄的次數(shù)，計(jì)算錯誤率。如果錯誤率達(dá)到熔斷預(yù)置的閾值，則開啟熔斷開關(guān)。
- 熔斷恢復(fù)：對于被熔斷的請求，暫停處理一段時間之后（HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()），允許單個請求通過，若請求成功，則取消熔斷，否則，繼續(xù)熔斷。
Hystrix熔斷器的工作原理如下所示：
圖6-2 Hystrix熔斷機(jī)制
6.2.3. 優(yōu)雅降級
當(dāng)微服務(wù)調(diào)用異常、超時，或者熔斷時，可以通過回調(diào)Fallback（）的方式實(shí)現(xiàn)業(yè)務(wù)的優(yōu)雅降級，它的原理如下所示：
圖6-3 Hystrix優(yōu)雅降級機(jī)制
6.2.4. Reactive編程
Hystrix支持響應(yīng)式編程，并提供了相關(guān)接口給用戶，如下所示：
利用響應(yīng)式編程，可以更加優(yōu)雅和靈活的實(shí)現(xiàn)異步回調(diào)邏輯的處理。
6.2.5. 信號量隔離
為了降低線程資源的開銷，Hystrix提供了信號量Semaphores，用于實(shí)現(xiàn)輕量級的依賴隔離。
開發(fā)者可以限制系統(tǒng)對某一個依賴的最高并發(fā)數(shù)，這個基本上等同于并發(fā)流控策略。每次微服務(wù)調(diào)用依賴時都會檢查一下是否到達(dá)信號量的限制值，如達(dá)到則拒絕。該隔離策略的優(yōu)點(diǎn)是不新起線程，減少上下文切換和線程數(shù)，缺點(diǎn)是無法配置斷路，每次都一定會去嘗試獲取信號量。
6.3. 集成Hystrix
由于Hystrix與特定的分布式系統(tǒng)、微服務(wù)框架無關(guān)，是個通用的分布式系統(tǒng)可靠性組件，可以通過類庫集成的方式方便的集成到已有的微服務(wù)架構(gòu)體系中。
6.3.1. 集成架構(gòu)
在已有微服務(wù)體系中集成Hystrix的策略如下：
集成架構(gòu)示例如下：
圖6-4? 集成Hystrix的微服務(wù)架構(gòu)
6.3.2. 集成Hystrix帶來的優(yōu)點(diǎn)
第三方依賴隔離具備一定的通用性，例如數(shù)據(jù)庫隔離、磁盤I/O隔離、第三方服務(wù)調(diào)用隔離等，如果各自構(gòu)建一套隔離機(jī)制，除了增加工作量之外，后續(xù)維護(hù)起來也比較麻煩。
另外，業(yè)務(wù)微服務(wù)自身也會引入第三方依賴，如果沒有通用的隔離機(jī)制，則業(yè)務(wù)需要自己構(gòu)建業(yè)務(wù)級的隔離體系，相應(yīng)的開發(fā)難度和工作量都較大，架構(gòu)上也很難統(tǒng)一。
集成Hystrix，可以快速的構(gòu)建微服務(wù)的隔離、熔斷、優(yōu)雅降級和響應(yīng)式編程體系，提升系統(tǒng)的可靠性。
另外，Hystrix非常成熟，在Netflix已經(jīng)經(jīng)歷過苛刻的生產(chǎn)環(huán)境考驗(yàn)，它的可靠性和成熟度完全能夠滿足大部分業(yè)務(wù)場景的需要。
7. 附錄
7.1. 參考文獻(xiàn)
Netflix Hystrix.
https://github.com/Netflix/Hystrix/wiki/How-To-Use
https://github.com/Netflix/Hystrix/wiki/How-it-Works
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/6840150.html
總結(jié)
以上是生活随笔為你收集整理的微服务可靠性设计--转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 预发环境与生产环境共享数据库时定时任务重
- 下一篇： 唯品会API网关设计与实践--转