朱晉君@君哥聊技術(shù)

 

我自己為了消化里邊的內(nèi)容，整理了一個腦圖，希望對你有幫助。

 

 

 

凌晨四點被公司的監(jiān)控告警叫醒了，告警的原因是生產(chǎn)環(huán)境跑批任務(wù)發(fā)生故障。即刻起床處理故障，但還是花了不少時間才解決。

這次故障是一次數(shù)據(jù)校驗的跑批任務(wù)，校驗前面跑批任務(wù)的數(shù)據(jù)是否正確。幸運的是，之前的核心任務(wù)已經(jīng)完成，并沒有影響到生產(chǎn)上的交易系統(tǒng)工作。

為什么我這里提到了交易工作呢？因為交易系統(tǒng)是整個系統(tǒng)業(yè)務(wù)流量的入口，如果交易系統(tǒng)發(fā)生故障，那會給公司帶來直接的收入損失。

今天我們聊的話題是服務(wù)治理，服務(wù)治理最終達(dá)到的結(jié)果就是系統(tǒng) 「7 * 24」 小時不間斷服務(wù)。

1 監(jiān)控告警

公司的這次生產(chǎn)告警很準(zhǔn)確，找到系統(tǒng)的直接維護(hù)人，并且通知到是哪個跑批任務(wù)出了故障。這次告警是通過監(jiān)控跑批任務(wù)中間件的任務(wù)執(zhí)行結(jié)果來觸發(fā)的。

一般情況下，告警有哪些類型呢？我們看下圖：

1.1 批處理效率

?

多數(shù)情況下批處理任務(wù)是不阻礙業(yè)務(wù)入口的，所以不需要監(jiān)控。

?

在阻礙業(yè)務(wù)入口的情況下，批處理任務(wù)必須要監(jiān)控。我舉兩個業(yè)務(wù)場景：

• 域名系統(tǒng)要通過dns信息和數(shù)據(jù)庫記錄來找出臟數(shù)據(jù)進(jìn)行交易補償，這期間客戶查詢域名信息可能是臟數(shù)據(jù)
• 銀行日終跑批期間是不允許實時交易的，這個「7 * 24」小時不間斷服務(wù)相違背

這些場景下批處理效率是非常重要的一個監(jiān)控指標(biāo)，必須配置超時閾值并進(jìn)行監(jiān)控。

1.2 流量監(jiān)控

常用的限流的指標(biāo)如下圖:

流量監(jiān)控我們需要注意幾點：

• 不同的系統(tǒng)，使用的監(jiān)控指標(biāo)是不同的，比如redis，可以用QPS指標(biāo)，對于交易系統(tǒng)，可以用TPS
• 通過測試和業(yè)務(wù)量的預(yù)估來配置合適的監(jiān)控閾值
• 監(jiān)控閾值需要考慮突發(fā)情況，比如秒殺、搶券等場景

1.3 異常監(jiān)控

異常監(jiān)控對于系統(tǒng)來說非常重要。在生產(chǎn)環(huán)境中很難保證程序不發(fā)生異常，配置合理的異常報警對快速定位和解決問題至關(guān)重要。比如開篇提到的跑批告警，告警信息中帶著異常，讓我很快就定位到了問題。

異常監(jiān)控需要注意下面幾個方面：

• 客戶端read timeout,這時要盡快從服務(wù)端找出原因
• 對客戶端收到響應(yīng)的時間設(shè)置一個閾值，比如1秒，超出后觸發(fā)告警
• 對業(yè)務(wù)異常一定要監(jiān)控，比如失敗響應(yīng)碼

1.4 資源使用率

生產(chǎn)環(huán)境配置系統(tǒng)資源時，一般要對系統(tǒng)資源的使用率有一個預(yù)測。比如redis在當(dāng)前的內(nèi)存增長速率下，多久會耗盡內(nèi)存，數(shù)據(jù)庫在當(dāng)前的增長速率下多久會用光磁盤。

系統(tǒng)資源需要設(shè)置一個閾值，比如70%，超過這個限制就要觸發(fā)告警。因為資源使用快要飽和時，處理效率也會嚴(yán)重下降。

配置資源使用率的閾值時，一定要考慮突增流量和突發(fā)業(yè)務(wù)的情況，提前預(yù)留額外的資源來應(yīng)對。

對核心服務(wù)要做好限流措施，防止突增流量把系統(tǒng)壓垮。

1.5 請求延遲

請求延遲并不是一個很容易統(tǒng)計的指標(biāo)，下圖是一個電商購物系統(tǒng)：

這個圖中，我們假設(shè)組合服務(wù)會并發(fā)地調(diào)用下面的訂單、庫存和賬戶服務(wù)。客戶端發(fā)出請求后，組合服務(wù)處理請求需要花費2秒的處理時間，賬戶服務(wù)需要花費3秒的處理時間，那客戶端配置的read timeout最小是5秒。

監(jiān)控系統(tǒng)需要設(shè)置一個閾值來監(jiān)控，比如1秒內(nèi)如果有100個請求延遲都大于了5秒就觸發(fā)報警，讓系統(tǒng)維護(hù)人員去查找問題。

?

客戶端設(shè)置的read timeout不能太大，如果因為服務(wù)端故障導(dǎo)致延遲，要保證fail-fast，防止因為資源不能釋放造成系統(tǒng)性能大幅度降低。

?

1.6 監(jiān)控注意事項

監(jiān)控是為了能讓系統(tǒng)維護(hù)人員快速發(fā)現(xiàn)生產(chǎn)問題并定位到原因，不過監(jiān)控系統(tǒng)也有幾個指標(biāo)需要考慮：

• 根據(jù)監(jiān)控目標(biāo)來制定監(jiān)控指標(biāo)采樣頻率，頻率太高會增加監(jiān)控成本。
• 監(jiān)控覆蓋率，最好能夠覆蓋到所有核心的系統(tǒng)指標(biāo)。
• 監(jiān)控有效性，監(jiān)控指標(biāo)不是越多越好，太多會給分辨報警有效性帶來額外工作量，也會讓開發(fā)人員習(xí)以為常。
• 告警時效，對于跑批任務(wù)這種非實時交易類系統(tǒng)，可以不用實時告警，記錄事件后定一個時間，比如早晨8點觸發(fā)告警，責(zé)任人到公司后處理。
• 為避免長尾效應(yīng)，最好不要使用平均值。如下圖：10個請求，有9個延遲都是1秒，但有1個延遲是10秒，所以平均值參考意義并不大。

?

可以采用按照區(qū)間分組的方式，比如延遲1秒以內(nèi)的請求數(shù)量，1-2秒的請求數(shù)量，2-3秒的請求數(shù)量分組進(jìn)行統(tǒng)計，按照指數(shù)級增長的方式來配置監(jiān)控閾值。

?

2 故障管理

2.1 常見故障原因

故障發(fā)生的原因五花八門，但常見的無非下面幾種：

• 發(fā)布升級帶來的故障
• 硬件資源故障
• 系統(tǒng)過載
• 惡意攻擊
• 基礎(chǔ)服務(wù)故障

2.2 應(yīng)對策略

應(yīng)對故障，我們分兩步走：

• 立即解決故障，比如因為數(shù)據(jù)問題引起的故障，修改問題數(shù)據(jù)即可。
• 找出故障原因，可以通過查找日志或者調(diào)用鏈追蹤系統(tǒng)來定位問題并解決

2.2.1 軟件升級故障

升級帶來的故障，有的是上線后能很快暴露的。有的是上線很長時間才會暴露，比如有的業(yè)務(wù)代碼可能之前一直執(zhí)行不到。

對于第一種情況，可以采用灰度發(fā)布的方式進(jìn)行驗證解決。

對于第二種情況，完全避免是很難的，我們只能最大限度地提高測試用例覆蓋率。

2.2.2 硬件資源故障

這類故障主要分為兩類：

• 硬件資源超載，比如內(nèi)存不夠
• 硬件資源老化

對于第一種故障一般用監(jiān)控告警的方式來通知責(zé)任人處理，處理的方式主要是增加資源，找出消耗資源嚴(yán)重的程序進(jìn)行優(yōu)化。

對于第二種故障需要運維人員對硬件資源進(jìn)行記錄和監(jiān)控，對于老化的資源及時進(jìn)行更換。

2.3 系統(tǒng)過載

系統(tǒng)過載可能是遇到秒殺之類的突增流量，也可能是隨著業(yè)務(wù)發(fā)展慢慢地超過系統(tǒng)承受能力，可以使用增加資源或者限流的方式來應(yīng)對。

2.4 惡意攻擊

惡意攻擊的類型非常多，比如DDOS攻擊、惡意軟件、瀏覽器攻擊等。

針對惡意攻擊，防止手段也很多，比如對請求報文進(jìn)行加密、引入專業(yè)的網(wǎng)絡(luò)安全防火墻、定期安全掃描、核心服務(wù)部署在非默認(rèn)端口等。

2.5 基礎(chǔ)軟件故障

如下圖所示，除了業(yè)務(wù)服務(wù)外每個組件都是基礎(chǔ)軟件，都需要考慮高可用。

3 發(fā)布管理

發(fā)布通常指軟硬件的升級，包括業(yè)務(wù)系統(tǒng)版本升級、基礎(chǔ)軟件升級、硬件環(huán)境升級等。作為程序員，本文講的升級是針對業(yè)務(wù)系統(tǒng)的升級。

3.1 發(fā)布流程

一般情況下，業(yè)務(wù)系統(tǒng)升級流程如下：

發(fā)布到生產(chǎn)環(huán)境，驗證沒有問題表示發(fā)布成功。

3.2 發(fā)布質(zhì)量

在升級軟件的時候，發(fā)布質(zhì)量非常重要，為保證發(fā)布質(zhì)量需要注意下面這些問題。

3.2.1 CheckList

為了保證發(fā)布質(zhì)量，發(fā)布前維護(hù)一份CheckList，并且開發(fā)團(tuán)隊對所有的問題進(jìn)行確認(rèn)。等這份清單都確認(rèn)完成后進(jìn)行構(gòu)建發(fā)布。下面是一些比較典型的問題：

• 上線sql是否正確
• 生產(chǎn)配置文件配置項是否完備
• 外部依賴的服務(wù)是否已經(jīng)發(fā)布并驗證完成
• 新機器路由權(quán)限是否已經(jīng)開通
• 多個服務(wù)的發(fā)布順序是否已經(jīng)明確
• 如果上線后發(fā)生故障怎么應(yīng)對

3.2.2 灰度發(fā)布

灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式。如下圖：

升級時采用金絲雀部署的方式，先把其中一個server作為金絲雀進(jìn)行發(fā)布升級，這個server在生產(chǎn)環(huán)境運行后沒有問題，再升級其他的server。有問題則進(jìn)行回滾。

3.2.2 藍(lán)綠部署

藍(lán)綠部署的方式如下圖：

升級之前客戶端的請求發(fā)送到綠色服務(wù)上，升級發(fā)布之后，通過負(fù)載均衡把請求轉(zhuǎn)到藍(lán)色系統(tǒng)，綠色系統(tǒng)暫時不下線，如果生產(chǎn)測試沒有問題，則下線綠色系統(tǒng)，否則切回綠色系統(tǒng)。

?

藍(lán)綠部署跟金絲雀部署的區(qū)別是，金絲雀部署不用增加新的機器，而藍(lán)綠部署相當(dāng)于是增加了一套新機器，需要額外的資源成本。

?

3.2.4 ab測試

ab測試是指在生產(chǎn)環(huán)境發(fā)布多個版本，主要目的是測試不同版本的不同效果。比如頁面樣式不一樣，操作流程不一樣，這樣可以讓用戶選擇一個最喜歡的版本作為最終版本。如下圖：

三個顏色的服務(wù)部署了，客戶端的請求分別發(fā)送到跟自己顏色一樣的服務(wù)上。

?

ab測試的版本都是已經(jīng)是驗證沒有問題的，這點不同于灰度發(fā)布。

?

3.2.4 配置變更

好多時候我們把配置寫在代碼里，比如yaml文件。這樣我們修改配置后就需要重新發(fā)布新版本。如果配置修改頻繁，可以考慮下面兩種方法：

• 引入配置中心
• 使用外部系統(tǒng)保存配置

4 容量管理

在2.3節(jié)中講到系統(tǒng)過載導(dǎo)致的系統(tǒng)故障。容量管理是保證系統(tǒng)上線后穩(wěn)定運行的一個重要環(huán)節(jié)，主要是保證系統(tǒng)流量不超過系統(tǒng)能承受的閾值，防止系統(tǒng)崩潰。一般情況下，系統(tǒng)容量超載的原因如下：

• 業(yè)務(wù)持續(xù)增加給系統(tǒng)帶來的流量不斷增加
• 系統(tǒng)資源收縮，比如一臺機器上新部署了一個應(yīng)用，占用了一些資源
• 系統(tǒng)處理請求變慢，比如因為數(shù)據(jù)量變大，數(shù)據(jù)庫響應(yīng)變慢，導(dǎo)致單個請求處理時間變長，資源不能釋放
• 重試導(dǎo)致的請求增加
• 突增流量，比如微博系統(tǒng)遇到明星離婚案之類的新聞。

4.1 重試

對于一些失敗的請求進(jìn)行重試，能夠很好地增加系統(tǒng)的用戶體驗。重試一般分為兩類，一類是對連接超時的請求，一類是對響應(yīng)超時的請求。

對于連接超時的請求，可能是網(wǎng)絡(luò)瞬時故障造成的，這種情況下重試并不會對服務(wù)端造成壓力，因為失敗的請求壓根就沒有到達(dá)服務(wù)端。

但是對于響應(yīng)超時的請求，如果進(jìn)行重試，可能會給服務(wù)端帶來額外的壓力。如下圖：

正常情況下，客戶端先調(diào)用服務(wù)A，服務(wù)A再調(diào)用服務(wù)B，服務(wù)B只被調(diào)用了一次。

如果服務(wù)B響應(yīng)慢導(dǎo)致超時，客戶端配置了失敗重試2次，服務(wù)A也配置了失敗重試2次，在服務(wù)B最終不能響應(yīng)的情況下，服務(wù)B最終被調(diào)了9次。

在大型分布式系統(tǒng)中，如果調(diào)用鏈很長，每個服務(wù)都配置了重試，那重試會給調(diào)用鏈下游服務(wù)造成巨大的壓力甚至讓系統(tǒng)崩潰。可見重試不是越多越好，合理的設(shè)置重試對系統(tǒng)有保護(hù)作用。

對于重試，有如下3個建議：

• 非核心業(yè)務(wù)不重試，如果重試，必須限定次數(shù)
• 重試時間間隔需要指數(shù)增加
• 根據(jù)返回失敗的狀態(tài)進(jìn)行重試，比如服務(wù)端定義一個拒絕碼，客戶端就不重試了

4.2 突增流量

對于突增流量，是很難提前規(guī)劃到的。

遇到突增的流量時，我們可以先考慮增加資源。以K8S為例，如果原來有2個pod，使用deploy編排擴(kuò)容到4個pod。命令如下：

kubectl scale deployment springboot-deployment --replicas=4

如果資源已經(jīng)用完了，那就得考慮限流了。推薦幾個限流框架：

• google guava
• netflix/concurrency-limits
• sentinel

4.3 容量規(guī)劃

系統(tǒng)建設(shè)初期做好容量規(guī)劃是非常重要的。

可以根據(jù)業(yè)務(wù)量來估算系統(tǒng)的QPS，基于QPS進(jìn)行壓力測試。針對壓力測試的結(jié)果估算的容量，并不一定能應(yīng)對生產(chǎn)環(huán)境的真實場景和突發(fā)情況，可以根據(jù)預(yù)估容量給出預(yù)留資源，比如2倍容量。

4.4 服務(wù)降級

服務(wù)降級對于服務(wù)端來說，可以有三種方式：

• 服務(wù)端容量超載后，直接拒絕新的請求
• 非核心服務(wù)暫停，預(yù)留資源給核心服務(wù)用
• 客戶端可以根據(jù)服務(wù)端拒絕的請求比例來進(jìn)行降級處理，比如觀察1分鐘，如果服務(wù)端對1000個請求，拒絕了100個，客戶端可以作為參考，以后每分鐘超過90個，就直接拒絕。

5 總結(jié)

微服務(wù)化的架構(gòu)給系統(tǒng)帶來了很多好處，但同時也帶來了一些技術(shù)上的挑戰(zhàn)。這些挑戰(zhàn)包括服務(wù)注冊與發(fā)現(xiàn)、負(fù)載均衡、監(jiān)控管理、發(fā)布升級、訪問控制等。而服務(wù)治理就是對這些問題進(jìn)行管理和預(yù)防，保證系統(tǒng)持續(xù)平穩(wěn)地運行。

本文所講的服務(wù)治理方案，也算是傳統(tǒng)意義上的方案，有時會有一些代碼的侵入，而框架的選擇也會對編程語言有限制。

在云原生時代，Service Mesh的出現(xiàn)又把服務(wù)治理的話題帶入一個新的階段。后續(xù)再做分享。

---

相關(guān)文章

研發(fā)效能之技術(shù)治理

infra ｜ devops工具鏈基建建設(shè)評價標(biāo)準(zhǔn)

阿里云香港節(jié)點全面故障給我們的啟示

陳宗綿｜關(guān)于研發(fā)效能的理想與現(xiàn)實

數(shù)字化轉(zhuǎn)型趨勢｜汽車電子軟件開發(fā)工具鏈必看