微服務(wù)如何保障穩(wěn)定性？
點擊關(guān)注公眾號，Java干貨及時送達(dá)
作者：fredalxin
地址：https://fredal.xin/talking-msa-msa-stability
當(dāng)一個單體應(yīng)用改造成多個微服務(wù)之后，在請求調(diào)用過程中往往會出現(xiàn)更多的問題，通信過程中的每一個環(huán)節(jié)都可能出現(xiàn)問題。而在出現(xiàn)問題之后，如果不加處理，還會出現(xiàn)鏈?zhǔn)椒磻?yīng)導(dǎo)致服務(wù)雪崩。服務(wù)治理功能就是用來處理此類問題的。
我們將從微服務(wù)的三個角色:注冊中心、服務(wù)消費者以及服務(wù)提供者一一說起。
注冊中心如何保障穩(wěn)定性
這一節(jié)，我們著重講的并不是注冊中心自身可用性保證，而更多的是與節(jié)點狀態(tài)相關(guān)的部分。
節(jié)點信息的保障
我們說過，當(dāng)注冊中心完全宕機后，微服務(wù)框架仍然需要有正常工作的能力。這得益于框架內(nèi)處理節(jié)點狀態(tài)的一些機制。
本機內(nèi)存
首先服務(wù)消費者會將節(jié)點狀態(tài)保持在本機內(nèi)存中。一方面由于節(jié)點狀態(tài)不會變更得那么頻繁，放在內(nèi)存中可以減少網(wǎng)絡(luò)開銷。另一方面，當(dāng)注冊中心宕機后，服務(wù)消費者仍能從本機內(nèi)存中找到服務(wù)節(jié)點列表從而發(fā)起調(diào)用。
本地快照
我們說，注冊中心宕機后，服務(wù)消費者仍能從本機內(nèi)存中找到服務(wù)節(jié)點列表。那么如果服務(wù)消費者重啟了呢？這時候我們就需要一份本地快照了，即我們保存一份節(jié)點狀態(tài)到本地文件，每次重啟之后會恢復(fù)到本機內(nèi)存中。
服務(wù)節(jié)點的摘除
現(xiàn)在無論注冊中心工作與否，我們都能順利拿到服務(wù)節(jié)點了。但是不是所有的服務(wù)節(jié)點都是正確可用的呢？在實際應(yīng)用中，這是需要打問號的。如果我們不校驗服務(wù)節(jié)點的正確性，很有可能就調(diào)用到了一個不正常的節(jié)點上。所以我們需要進行必要的節(jié)點管理。
對于節(jié)點管理來說，我們有兩種手段，主要是去摘除不正確的服務(wù)節(jié)點。
注冊中心摘除機制
一是通過注冊中心來進行摘除節(jié)點。服務(wù)提供者會與注冊中心保持心跳，而一旦超出一定時間收不到心跳包，注冊中心就認(rèn)為該節(jié)點出現(xiàn)了問題，會把節(jié)點從服務(wù)列表中摘除，并通知到服務(wù)消費者，這樣服務(wù)消費者就不會調(diào)用到有問題的節(jié)點上。
服務(wù)消費者摘除機制
二是在服務(wù)消費者這邊拆除節(jié)點。因為服務(wù)消費者自身是最知道節(jié)點是否可用的角色，所以在服務(wù)消費者這邊做判斷更合理，如果服務(wù)消費者調(diào)用出現(xiàn)網(wǎng)絡(luò)異常，就將該節(jié)點從內(nèi)存緩存列表中摘除。當(dāng)然調(diào)用失敗多少次之后才進行摘除，以及摘除恢復(fù)的時間等等細(xì)節(jié)，其實都和客戶端熔斷類似，可以結(jié)合起來做。
一般來說，對于大流量應(yīng)用，服務(wù)消費者摘除的敏感度會高于注冊中心摘除，兩者之間也不用刻意做同步判斷，因為過一段時間后注冊中心摘除會自動覆蓋服務(wù)消費者摘除。
服務(wù)節(jié)點是可以隨便摘除/變更的么
上一節(jié)我們講可以摘除問題節(jié)點，從而避免流量調(diào)用到該節(jié)點上。但節(jié)點是可以隨便摘除的么？同時，這也包含"節(jié)點是可以隨便更新的么？"疑問。
頻繁變動
增量更新
同樣是由于頻繁變動可能引起的網(wǎng)絡(luò)風(fēng)暴問題，一個可行的方案是進行增量更新，注冊中心只會推送那些變化的節(jié)點信息而不是全部，從而在頻繁變動的時候避免網(wǎng)絡(luò)風(fēng)暴。
可用節(jié)點過少
當(dāng)網(wǎng)絡(luò)抖動，并進行節(jié)點摘除過后，很可能出現(xiàn)可用節(jié)點過少的情況。這時候過大的流量分配給過少的節(jié)點，導(dǎo)致剩下的節(jié)點難堪重負(fù)，罷工不干，引起惡化。而實際上，可能節(jié)點大多數(shù)是可用的，只不過由于網(wǎng)絡(luò)問題與注冊中心未能及時保持心跳而已。
這時候，就需要在服務(wù)消費者這邊設(shè)置一個開關(guān)比例閾值，當(dāng)注冊中心通知節(jié)點摘除，但緩存列表中剩下的節(jié)點數(shù)低于一定比例后（與之前一段時間相比），不再進行摘除，從而保證有足夠的節(jié)點提供正常服務(wù)。
這個值其實可以設(shè)置的高一些，例如百分之70，因為正常情況下不會有頻繁的網(wǎng)絡(luò)抖動。當(dāng)然，如果開發(fā)者確實需要下線多數(shù)節(jié)點，可以關(guān)閉該開關(guān)。
服務(wù)消費者如何保障穩(wěn)定性
一個請求失敗了，最直接影響到的是服務(wù)消費者，那么在服務(wù)消費者這邊，有什么可以做的呢？
超時
如果調(diào)用一個接口，但遲遲沒有返回響應(yīng)的時候，我們往往需要設(shè)置一個超時時間，以防自己被遠(yuǎn)程調(diào)用拖死。超時時間的設(shè)置也是有講究的，設(shè)置的太長起的作用就小，自己被拖垮的風(fēng)險就大，設(shè)置的太短又有可能誤判一些正常請求，大幅提升錯誤率。
在實際使用中，我們可以取該應(yīng)用一段時間內(nèi)的P999的值，或者取p95的值*2。具體情況需要自行定奪。
在超時設(shè)置的時候，對于同步與異步的接口也是有區(qū)分的。對于同步接口，超時設(shè)置的值不僅需要考慮到下游接口，還需要考慮上游接口。而對于異步來說，由于接口已經(jīng)快速返回，可以不用考慮上游接口，只需考慮自身在異步線程里的阻塞時長，所以超時時間也放得更寬一些。
容錯機制
請求調(diào)用永遠(yuǎn)不能保證成功，那么當(dāng)請求失敗時候，服務(wù)消費者可以如何進行容錯呢？通常容錯機制分為以下這些:
FailTry：失敗重試。就是指最常見的重試機制，當(dāng)請求失敗后視圖再次發(fā)起請求進行重試。這樣從概率上講，失敗率會呈指數(shù)下降。對于重試次數(shù)來說，也需要選擇一個恰當(dāng)?shù)闹担绻卦嚧螖?shù)太多，就有可能引起服務(wù)惡化。另外，結(jié)合超時時間來說，對于性能有要求的服務(wù)，可以在超時時間到達(dá)前的一段提前量就發(fā)起重試，從而在概率上優(yōu)化請求調(diào)用。當(dāng)然，重試的前提是冪等操作。 FailOver：失敗切換。和上面的策略類似，只不過FailTry會在當(dāng)前實例上重試。而FailOver會重新在可用節(jié)點列表中根據(jù)負(fù)載均衡算法選擇一個節(jié)點進行重試。 FailFast：快速失敗。請求失敗了就直接報一個錯，或者記錄在錯誤日志中，這沒什么好說的。
另外，還有很多形形色色的容錯機制，大多是基于自己的業(yè)務(wù)特性定制的，主要是在重試上做文章，例如每次重試等待時間都呈指數(shù)增長等。
第三方框架也都會內(nèi)置默認(rèn)的容錯機制，例如Ribbon的容錯機制就是由retry以及retry next組成，即重試當(dāng)前實例與重試下一個實例。這里要多說一句，ribbon的重試次數(shù)與重試下一個實例次數(shù)是以笛卡爾乘積的方式提供的噢！
Spring Boot 學(xué)習(xí)教程推薦：https://github.com/javastacks/spring-boot-best-practice
熔斷
上一節(jié)將的容錯機制，主要是一些重試機制，對于偶然因素導(dǎo)致的錯誤比較有效，例如網(wǎng)絡(luò)原因。但如果錯誤的原因是服務(wù)提供者自身的故障，那么重試機制反而會引起服務(wù)惡化。
這時候我們需要引入一種熔斷的機制，即在一定時間內(nèi)不再發(fā)起調(diào)用，給予服務(wù)提供者一定的恢復(fù)時間，等服務(wù)提供者恢復(fù)正常后再發(fā)起調(diào)用。這種保護機制大大降低了鏈?zhǔn)疆惓Ｒ鸬姆?wù)雪崩的可能性。
在實際應(yīng)用中，熔斷器往往分為三種狀態(tài)，打開、半開以及關(guān)閉。引用一張martinfowler畫的原理圖:
在普通情況下，斷路器處于關(guān)閉狀態(tài)，請求可以正常調(diào)用。當(dāng)請求失敗達(dá)到一定閾值條件時，則打開斷路器，禁止向服務(wù)提供者發(fā)起調(diào)用。當(dāng)斷路器打開后一段時間，會進入一個半開的狀態(tài)，此狀態(tài)下的請求如果調(diào)用成功了則關(guān)閉斷路器，如果沒有成功則重新打開斷路器，等待下一次半開狀態(tài)周期。
斷路器的實現(xiàn)中比較重要的一點是失敗閾值的設(shè)置。可以根據(jù)業(yè)務(wù)需求設(shè)置失敗的條件為連續(xù)失敗的調(diào)用次數(shù)，也可以是時間窗口內(nèi)的失敗比率，失敗比率通過一定的滑動窗口算法進行計算。另外，針對斷路器的半開狀態(tài)周期也可以做一些花樣，一種常見的計算方法是周期長度隨著失敗次數(shù)呈指數(shù)增長。
具體的實現(xiàn)方式可以根據(jù)具體業(yè)務(wù)指定，也可以選擇第三方框架例如Hystrix。Hystrix理論+實戰(zhàn)推薦看下。
隔離
隔離往往和熔斷結(jié)合在一起使用，還是以Hystrix為例，它提供了兩種隔離方式：
信號量隔離：使用信號量來控制隔離線程，你可以為不同的資源設(shè)置不同的信號量以控制并發(fā)，并相互隔離。當(dāng)然實際上，使用原子計數(shù)器也沒什么不一樣。 線程池隔離：通過提供相互隔離的線程池的方式來隔離資源，相對來說消耗資源更多，但可以更好地應(yīng)對突發(fā)流量。
降級
降級同樣大多和熔斷結(jié)合在一起使用，當(dāng)服務(wù)調(diào)用者這方斷路器打開后，無法再對服務(wù)提供者發(fā)起調(diào)用了，這時候可以通過返回降級數(shù)據(jù)來避免熔斷造成的影響。
降級往往用于那些錯誤容忍度較高的業(yè)務(wù)。同時降級的數(shù)據(jù)如何設(shè)置也是一門學(xué)問。一種方法是為每個接口預(yù)先設(shè)置好可接受的降級數(shù)據(jù)，但這種靜態(tài)降級的方法適用性較窄。還有一種方法，是去線上日志系統(tǒng)/流量錄制系統(tǒng)中撈取上一次正確的返回數(shù)據(jù)作為本次降級數(shù)據(jù)，但這種方法的關(guān)鍵是提供可供穩(wěn)定抓取請求的日志系統(tǒng)或者流量采樣錄制系統(tǒng)。
另外，針對降級我們往往還會設(shè)置操作開關(guān)，對于一些影響不大的采取自動降級，而對于一些影響較大的則需進行人為干預(yù)降級。
服務(wù)提供者如何保障穩(wěn)定性
限流
限流就是限制服務(wù)請求流量，服務(wù)提供者可以根據(jù)自身情況(容量)給請求設(shè)置一個閾值，當(dāng)超過這個閾值后就丟棄請求，這樣就保證了自身服務(wù)的正常運行。
閾值的設(shè)置可以針對兩個方面考慮，一是QPS即每秒請求數(shù)，二是并發(fā)線程數(shù)。從實踐來看，我們往往會選擇后者，因為QPS高往往是由于處理能力高，并不能反映出系統(tǒng)"不堪重負(fù)"。
除此之外，我們還有許多針對限流的算法。例如令牌桶算法以及漏桶算法，主要針對突發(fā)流量的狀況做了優(yōu)化。第三方的實現(xiàn)中例如guava rateLimiter就實現(xiàn)了令牌桶算法。在此就不就細(xì)節(jié)展開了。
重啟與回滾
限流更多的起到一種保障的作用，但如果服務(wù)提供者已經(jīng)出現(xiàn)問題了，這時候該怎么辦呢？
這時候就會出現(xiàn)兩種狀況。一是本身代碼有bug，這時候一方面需要服務(wù)消費者做好熔斷降級等操作，一方面服務(wù)提供者這邊結(jié)合DevOps需要有快速回滾到上一個正確版本的能力。
更多的時候，我們可能僅僅碰到了與代碼無強關(guān)聯(lián)的單機故障，一個簡單粗暴的辦法就是自動重啟。例如觀察到某個接口的平均耗時超出了正常范圍一定程度，就將該實例進行自動重啟。當(dāng)然自動重啟需要有很多注意事項，例如重啟時間是否放在晚上，以及自動重啟引起的與上述節(jié)點摘除一樣的問題，都需要考慮和處理。
在事后復(fù)盤的時候，如果當(dāng)時沒有保護現(xiàn)場，就很難定位到問題原因。所以往往在一鍵回滾或者自動重啟之前，我們往往需要進行現(xiàn)場保護。現(xiàn)場保護可以是自動的，例如一開始就給jvm加上打印gc日志的參數(shù)-XX:+PrintGCDetails，或者輸出oom文件-XX:+HeapDumpOnOutOfMemoryError，也可以配合DevOps自動腳本完成，當(dāng)然手動也可以。一般來說我們會如下操作:
打印堆棧信息， jstak -l 'java進程PID'打印內(nèi)存鏡像， jmap -dump:format=b,file=hprof 'java進程PID'保留gc日志，保留業(yè)務(wù)日志
調(diào)度流量
除了以上這些措施，通過調(diào)度流量來避免調(diào)用到問題節(jié)點上也是非常常用的手段。
當(dāng)服務(wù)提供者中的一臺機器出現(xiàn)問題，而其他機器正常時，我們可以結(jié)合負(fù)載均衡算法迅速調(diào)整該機器的權(quán)重至0，避免流量流入，再去機器上進行慢慢排查，而不用著急第一時間重啟。
如果服務(wù)提供者分了不同集群/分組，當(dāng)其中一個集群出現(xiàn)問題時，我們也可以通過路由算法將流量路由到正常的集群中。這時候一個集群就是一個微服務(wù)分組。
而當(dāng)機房炸了、光纜被偷了等IDC故障時，我們又部署了多IDC，也可以通過一些方式將流量切換到正常的IDC，以供服務(wù)繼續(xù)正常運行。切換流量同樣可以通過微服務(wù)的路由實現(xiàn)，但這時候一個IDC對應(yīng)一個微服務(wù)分組了。除此之外，使用DNS解析進行流量切換也是可以的，將對外域名的VIP從一個IDC切換到另一個IDC。
最后，關(guān)注公眾號Java技術(shù)棧，在后臺回復(fù)：面試，可以獲取我整理的 Java、微服務(wù)系列面試題和答案，非常齊全。
關(guān)注Java技術(shù)棧看更多干貨
