[[339932]]

本文轉(zhuǎn)載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉(zhuǎn)載本文請聯(lián)系腦子進煎魚了公眾號。   

“微服務(wù)的戰(zhàn)爭” 是一個關(guān)于微服務(wù)設(shè)計思考的系列題材，主要是針對在微服務(wù)化后所出現(xiàn)的一些矛盾/沖突點，不涉及具體某一個知識點深入。如果你有任何問題或建議，歡迎隨時交流。

在《微服務(wù)的戰(zhàn)爭：統(tǒng)一且標(biāo)準(zhǔn)化》中，經(jīng)過好幾周與不同業(yè)務(wù)組不同事業(yè)部的跨部門討論后，終于把初始的標(biāo)準(zhǔn)化方案給定下來了。

大家歡快的使用起了內(nèi)部的統(tǒng)一框架，瘋狂的創(chuàng)建起了新服務(wù)，沒隔多久服務(wù)調(diào)用鏈就變成了下圖：

服務(wù)間存在多次內(nèi)部調(diào)用，服務(wù) A =》服務(wù) B =》服務(wù) C =》服務(wù)D，而 服務(wù) E =》 服務(wù) B，服務(wù) F =》服務(wù) E，也就是存在著多個流量入口，且依賴相同的服務(wù)。

背景

服務(wù)與服務(wù)中，總存在業(yè)務(wù)服務(wù)，公共服務(wù)，基礎(chǔ)服務(wù)等類型。但在某一個夜晚，突然發(fā)現(xiàn) BFF 調(diào)用后端服務(wù)開始逐漸不正常，客戶給你截圖反饋問題，你發(fā)現(xiàn)有點問題：

單從表現(xiàn)來看，你發(fā)現(xiàn)是 BFF 調(diào)用服務(wù) A 極度緩慢，也不知道怎么了...正當(dāng)以為是服務(wù) A 出問題，想著萬能重啟一下時。你在日志平臺和鏈路追蹤系統(tǒng)一看，發(fā)現(xiàn)了大量的錯誤日志和緩慢，讓你略微震驚，一時間不知道從何下手。

這可怎么辦?

級聯(lián)故障和雪崩

實際上這是一次很經(jīng)典的級聯(lián)故障，最終導(dǎo)致系統(tǒng)雪崩的情景再現(xiàn)。單從上述拓?fù)鋪砜?，問題點之一在于服務(wù) B：

服務(wù) B 本身作為服務(wù) A 和服務(wù) F 的兩個流量入口必經(jīng)之處，想必至少是一個公共服務(wù)，但他也依賴了其他多個服務(wù)。因此若服務(wù) C 和服務(wù) D 其中一個有問題，在沒有熔斷措施的情況下，就出現(xiàn)級聯(lián)故障，系統(tǒng)逐漸崩盤，最后雪崩：

服務(wù) D 所依賴的外部接口出現(xiàn)了故障，而他并沒有做任何的控制，因此擴散到了所有調(diào)用到他的服務(wù)，自然也就包含服務(wù) B，因此最終出現(xiàn)系統(tǒng)雪崩。

這種最經(jīng)典的是出現(xiàn)在默認(rèn) Go http client 調(diào)用沒有設(shè)置 Timeout，從而只要出現(xiàn)一次故障，就足矣讓記住這類 “坑”，畢竟崩的 ”慢“，錯誤日志還多。

解決方法

常見的方式是根據(jù)特定的規(guī)則/規(guī)律進行熔斷和降級，避免請求發(fā)生堆積：

• 超時時間控制。
• 慢調(diào)用比例。
• 錯誤比例。
• 自適應(yīng)(例如：負(fù)載情況等)。

當(dāng)然，這也只是壯士斷腕，后續(xù)措施還包含監(jiān)控告警，通知對應(yīng)的開發(fā)人員來處理。且需提前對被降級的模塊進行業(yè)務(wù)邏輯進行處理等等，這樣才能夠比較柔和且快速地度過這一次危機。

總結(jié)

在分布式應(yīng)用中，級聯(lián)故障和雪崩是非常常見的，一些開發(fā)同學(xué)在模塊設(shè)計時可能并沒有意識到這塊的問題，在微服務(wù)化后會一個不留神就碰到，因為其調(diào)用鏈變得特別的長且多。因此建議配套設(shè)施和限流熔斷措施都應(yīng)該及時跟上，否則面對一大堆的錯誤日志還是很無奈的。