1.熔斷

在微服務(wù)領(lǐng)域，熔斷機(jī)制是從消費(fèi)端保護(hù)微服務(wù)提供者的措施，當(dāng)微服務(wù)的運(yùn)行質(zhì)量低于某個(gè)臨界值時(shí)，啟動(dòng)熔斷機(jī)制，暫停微服務(wù)調(diào)用一段時(shí)間，以保障后端的微服務(wù)不會(huì)因?yàn)槌掷m(xù)過負(fù)荷而宕機(jī)。

?

2.降級(jí)

服務(wù)降級(jí)主要包括容錯(cuò)降級(jí)和屏蔽降級(jí)

屏蔽降級(jí)：1）throw null 不發(fā)起遠(yuǎn)程調(diào)用，直接返回空

? ? ? ? ?2）throw exception 不發(fā)起遠(yuǎn)程調(diào)用，直接拋出指定異常

? ? ? ? ?3）execute bean 不發(fā)起遠(yuǎn)程調(diào)用，直接執(zhí)行本地模擬接口實(shí)現(xiàn)?

服務(wù)降級(jí)是可逆操作，當(dāng)系統(tǒng)壓力恢復(fù)到一定值不需要降級(jí)服務(wù)時(shí)，要重新發(fā)起遠(yuǎn)程調(diào)用，服務(wù)狀態(tài)改為正常

?

容錯(cuò)降級(jí)：非核心服務(wù)不可調(diào)用時(shí)，可以對(duì)故障服務(wù)做業(yè)務(wù)放通，保證主流程不受影響

1）RPC異常：通常指超時(shí)、消息解碼異常、流控異常、系統(tǒng)擁塞保護(hù)異常等

2）Service異常 eg登錄校驗(yàn)異常、數(shù)據(jù)庫操作失敗異常等

?

容錯(cuò)降級(jí)和屏蔽降級(jí)的區(qū)別在于：

1）觸發(fā)條件不同：屏蔽降級(jí)往往是人工根據(jù)系統(tǒng)的運(yùn)行，手動(dòng)設(shè)置

? ? ? ? ? ? ? ? 容錯(cuò)降級(jí)是根據(jù)服務(wù)調(diào)用返回的結(jié)果，結(jié)合當(dāng)前的服務(wù)級(jí)別，自動(dòng)匹配觸發(fā)

2）作用不同：容錯(cuò)降級(jí)是服務(wù)不可用時(shí)，讓消費(fèi)者執(zhí)行業(yè)務(wù)放通

? ? ? ? ? ? 屏蔽降級(jí)主要目的是將原屬于降級(jí)業(yè)務(wù)的資源調(diào)配出來供核心業(yè)務(wù)使用

3）調(diào)用機(jī)制不同，一個(gè)發(fā)起遠(yuǎn)程服務(wù)調(diào)用，一個(gè)只做本地調(diào)用

?

3.流量控制

當(dāng)資源成為瓶頸時(shí)，服務(wù)框架需要對(duì)消費(fèi)者做限流，啟動(dòng)流控保護(hù)機(jī)制。流量控制有多種策略，比較常用的有：針對(duì)訪問速率的靜態(tài)流控、針對(duì)資源占用的動(dòng)態(tài)流控等。

在實(shí)踐中，各種流量控制策略需要綜合使用才能起到較好的效果。

動(dòng)態(tài)流控

動(dòng)態(tài)流控的最終目標(biāo)是為了保命，并不是對(duì)流量或者訪問速度做精確控制。當(dāng)系統(tǒng)負(fù)載壓力非常大時(shí)，系統(tǒng)進(jìn)入過負(fù)載狀態(tài)，可能是CPU、內(nèi)存資源已經(jīng)過載，也可能是應(yīng)用進(jìn)程內(nèi)部的資源幾乎耗盡，如果繼續(xù)全量處理業(yè)務(wù)，可能會(huì)導(dǎo)致消息嚴(yán)重積壓或者應(yīng)用進(jìn)程宕機(jī)。

動(dòng)態(tài)流控檢測(cè)的資源包括：

• CPU使用率。
• 內(nèi)存使用率（對(duì)于Java，主要是JVM內(nèi)存使用率）。
• 隊(duì)列積壓率。

靜態(tài)流控

靜態(tài)流控主要針對(duì)客戶端訪問速率進(jìn)行控制，它通常根據(jù)服務(wù)質(zhì)量等級(jí)協(xié)定（SLA）中約定的QPS做全局流量控制，例如計(jì)費(fèi)服務(wù)的靜態(tài)流控閾值為200 QPS，則無論集群有多少個(gè)計(jì)費(fèi)服務(wù)實(shí)例，它們總的處理速率之和不能超過200 QPS。

由于微服務(wù)具備彈性伸縮、動(dòng)態(tài)上線和下線等特性，因此集群中某個(gè)微服務(wù)實(shí)例的節(jié)點(diǎn)個(gè)數(shù)是動(dòng)態(tài)變化的，采用傳統(tǒng)的平均分配制無法做到精準(zhǔn)的控制。

在實(shí)踐中，比較成熟的集群靜態(tài)流控策略是動(dòng)態(tài)配額申請(qǐng)制，它的工作原理如下：

系統(tǒng)部署的時(shí)候，根據(jù)微服務(wù)節(jié)點(diǎn)數(shù)和靜態(tài)流控QPS閾值，拿出一定比例的配額做初始分配，剩余的配額放在配額資源池中。

哪個(gè)微服務(wù)節(jié)點(diǎn)使用完了配額，就主動(dòng)向服務(wù)注冊(cè)中心申請(qǐng)配額。配額的申請(qǐng)策略：如果流控周期為T，則將周期T分成更小的周期T/N（N為經(jīng)驗(yàn)值，默認(rèn)值為10），當(dāng)前的服務(wù)節(jié)點(diǎn)數(shù)為M個(gè)，則申請(qǐng)的配額為 （總QPS配額 - 已經(jīng)分配的QPS配額）/M * T/N。

總的配額如果被申請(qǐng)完，則返回0配額給各個(gè)申請(qǐng)配額的服務(wù)節(jié)點(diǎn)，服務(wù)節(jié)點(diǎn)對(duì)新接入的請(qǐng)求消息進(jìn)行流控。

用戶自定義流控機(jī)制

不同的業(yè)務(wù)，存在不同的流控策略，例如基于微服務(wù)優(yōu)先級(jí)的流控、基于節(jié)假日的流控、基于業(yè)務(wù)字段的流控等。底層的服務(wù)框架無法實(shí)現(xiàn)所有業(yè)務(wù)級(jí)的定制流控策略，因此，過于業(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ù)的定制工作量。

?

4.隔離

?

由于大部分微服務(wù)采用同步接口調(diào)用，而且多個(gè)領(lǐng)域相關(guān)的微服務(wù)會(huì)部署在同一個(gè)進(jìn)程中，很容易發(fā)生“雪崩效應(yīng)”，即某個(gè)微服務(wù)提供者故障，導(dǎo)致調(diào)用該微服務(wù)的消費(fèi)者、或者與故障微服務(wù)合設(shè)在同一個(gè)進(jìn)程中的其它微服務(wù)發(fā)生級(jí)聯(lián)故障，最終導(dǎo)致系統(tǒng)崩潰。

為了避免“雪崩效應(yīng)”的發(fā)生，需要支持多種維度的依賴和故障隔離，以實(shí)現(xiàn)微服務(wù)的HA。

通信鏈路隔離

由于網(wǎng)絡(luò)通信本身通常不是系統(tǒng)的瓶頸，因此大部分服務(wù)框架會(huì)采用多線程+單個(gè)通信鏈路的方式進(jìn)行通信，原理如下所示：

　　　　　　　　　　　　　　多線程-單鏈路P2P通信模式

正如前面章節(jié)所述，由于微服務(wù)使用異步非阻塞通信，單個(gè)I/O線程可以同時(shí)并發(fā)處理多個(gè)鏈路的消息，而且網(wǎng)絡(luò)讀寫都是非阻塞的，因此采用多線程+單鏈路的方式進(jìn)行通信性能本身問題不大。但是從可靠性角度來看，只支持單鏈路本身又存在一些可靠性隱患，我們從下面的案例中看下問題所在。

某互聯(lián)網(wǎng)基地微服務(wù)架構(gòu)上線之后，發(fā)現(xiàn)在一些時(shí)段，經(jīng)常有業(yè)務(wù)超時(shí)，超時(shí)的業(yè)務(wù)沒有固定規(guī)律。經(jīng)定位發(fā)現(xiàn)當(dāng)有較多的批量內(nèi)容同步、語音和視頻類微服務(wù)調(diào)用時(shí)，系統(tǒng)的整體時(shí)延就增高了很多，而且存在較突出的時(shí)延毛刺。由于這些操作獲取的消息碼流往往達(dá)到數(shù)M到數(shù)十兆，微服務(wù)之間又采用單鏈路的方式進(jìn)行P2P通信，導(dǎo)致大碼流的傳輸影響了其它消息的讀寫效率，增大了微服務(wù)的響應(yīng)時(shí)延。

問題定位出來之后，對(duì)微服務(wù)之間的通信機(jī)制做了優(yōu)化，節(jié)點(diǎn)之間支持配置多鏈路，每個(gè)鏈路之間還可以實(shí)現(xiàn)不同策略的隔離，例如根據(jù)消息碼流大小、根據(jù)微服務(wù)的優(yōu)先級(jí)等策略，實(shí)現(xiàn)鏈路級(jí)的隔離，優(yōu)化之后的微服務(wù)通信機(jī)制：

　　　　　　　　支持多鏈路隔離

?調(diào)度資源隔離

? ? 微服務(wù)之間隔離

當(dāng)多個(gè)微服務(wù)合設(shè)運(yùn)行在同一個(gè)進(jìn)程內(nèi)部時(shí)，可以利用線程實(shí)現(xiàn)不同微服務(wù)之間的隔離。

對(duì)于核心微服務(wù)，發(fā)布的時(shí)候可以獨(dú)占一個(gè)線程/線程池，對(duì)于非核心微服務(wù)，則可以共享同一個(gè)大的線程池，在實(shí)現(xiàn)微服務(wù)隔離的同時(shí)，避免線程過于膨脹：

圖3-3 微服務(wù)之間故障隔離

假如非核心服務(wù)3發(fā)生故障，長時(shí)間阻塞線程池1的工作線程，其它與其共用線程池消息隊(duì)列的非核心服務(wù)1和服務(wù)2只能在隊(duì)列中排隊(duì)等待，當(dāng)服務(wù)3釋放線程之后，排隊(duì)的服務(wù)1和服務(wù)2可能已經(jīng)超時(shí)，只能被丟棄掉，導(dǎo)致業(yè)務(wù)處理失敗。

采用線程池隔離的核心服務(wù)1和服務(wù)2，由于各自獨(dú)占線程池，擁有獨(dú)立的消息隊(duì)列，它的執(zhí)行不受發(fā)生故障的非核心服務(wù)1影響，因此可以繼續(xù)正常工作。通過獨(dú)立線程池部署核心服務(wù)，可以防止故障擴(kuò)散，保障核心服務(wù)的正常運(yùn)行。

?第三方依賴隔離

在微服務(wù)中通常會(huì)調(diào)用第三方中間件服務(wù)，例如分布式緩存服務(wù)、分布式消息隊(duì)列、NoSQL服務(wù)等。只要調(diào)用第三方服務(wù)，就會(huì)涉及跨網(wǎng)絡(luò)操作，由于客戶端SDK API的封裝，很多故障都是隱性的，因此，它的可靠性需要額外關(guān)注。

整體而言，第三方依賴隔離可以采用線程池 + 響應(yīng)式編程（例如RxJava）的方式實(shí)現(xiàn)，它的原理如下所示：

1) 對(duì)第三方依賴進(jìn)行分類，每種依賴對(duì)應(yīng)一個(gè)獨(dú)立的線程/線程池。

2) 微服務(wù)不直接調(diào)用第三方依賴的API，而是使用異步封裝之后的API接口。

3) 異步調(diào)用第三方依賴API之后，獲取Future對(duì)象。利用響應(yīng)式編程框架，可以訂閱后續(xù)的事件，接收響應(yīng)，針對(duì)響應(yīng)進(jìn)行編程。

利用Netflix開源的hystrix + RxJava，可以快速實(shí)現(xiàn)第三方依賴的隔離，后續(xù)章節(jié)我們會(huì)詳細(xì)介紹下如何使用。

進(jìn)程級(jí)隔離

對(duì)于核心的微服務(wù)，例如商品購買、用戶注冊(cè)、計(jì)費(fèi)等，可以采用獨(dú)立部署的方式，實(shí)現(xiàn)高可用性。

? 容器隔離

微服務(wù)鼓勵(lì)軟件開發(fā)者將整個(gè)軟件解耦為功能單一的服務(wù)，并且這些服務(wù)能夠獨(dú)立部署、升級(jí)和擴(kuò)容。如果微服務(wù)抽象的足夠好，那么微服務(wù)的這一優(yōu)點(diǎn)將能夠提升應(yīng)用的敏捷性和自治理能力。

利用Docker容器部署微服務(wù)，可以帶來如下幾個(gè)優(yōu)點(diǎn)：

• 高效：Docker容器的啟動(dòng)和停止不需要幾分鐘，只要幾百毫秒就足夠了。使用Docker部署微服務(wù)，微服務(wù)的啟動(dòng)和銷毀速度非?？?#xff0c;在高壓力時(shí)，可以實(shí)現(xiàn)秒級(jí)彈性伸縮。
• 高性能：Docker容器的性能接近裸的物理機(jī)，比VM平均高20%+。
• 隔離性：利用Docker，可以實(shí)現(xiàn)0.1 core的隔離。基于細(xì)粒度的資源隔離機(jī)制，可以實(shí)現(xiàn)高密度的部署微服務(wù)，同時(shí)實(shí)現(xiàn)它們之間的資源層隔離，保障微服務(wù)的可靠性。
• 可移植性：在基于虛擬機(jī)的解決方案中，應(yīng)用的可移植性通常來說會(huì)受到云提供商所提供的虛擬機(jī)格式限制。如果應(yīng)用程序需要部署到不同類型的虛擬機(jī)中，需要針對(duì)特定的虛擬機(jī)格式做鏡像文件，新增很多額外的開發(fā)和測(cè)試工作量。Docker容器的設(shè)計(jì)理念是“一次編寫，到處運(yùn)行”，這可以使開發(fā)者避免上面這種限制。

基于Docker容器部署微服務(wù)，實(shí)現(xiàn)物理資源層隔離示意圖如下所示：

圖3-4? 基于Docker容器的微服務(wù)隔離

VM隔離

除了Docker容器隔離，也可以使用VM對(duì)微服務(wù)進(jìn)行故障隔離，相比于Docker容器，使用VM進(jìn)行微服務(wù)隔離存在如下優(yōu)勢(shì)：

微服務(wù)的資源隔離性更好，CPU、內(nèi)存、網(wǎng)絡(luò)等可以實(shí)現(xiàn)完全的資源隔離。

對(duì)于已經(jīng)完成硬件虛擬化的遺留系統(tǒng)，可以直接使用已有的VM，而不需要在VM中重新部署Docker容器。

開源：

1.Hystrix - Latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.

2. Resilient HTTP - A smart HTTP client with super powers like fault tolerance, dynamic server discovery, auto balancing and reactive recovery, designed for distributed systems.

?

參考文獻(xiàn)：

【1】http://www.infoq.com/cn/articles/micro-service-reliability-design

?

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/9264919.html

總結(jié)

以上是生活随笔為你收集整理的微服务实践分享(8) 控制调用中心的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。