[[392916]]

本文轉(zhuǎn)載自微信公眾號(hào)「程序員jinjunzhu」，作者jinjunzhu。轉(zhuǎn)載本文請(qǐng)聯(lián)系程序員jinjunzhu公眾號(hào)。

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

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

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

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

1 監(jiān)控告警

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

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

1.1 批處理效率

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

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

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

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

1.2 流量監(jiān)控

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

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

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

1.3 異常監(jiān)控

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

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

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

1.4 資源使用率

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

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

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

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

1.5 請(qǐng)求延遲

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

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

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

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

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

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

• 根據(jù)監(jiān)控目標(biāo)來(lái)指定監(jiān)控指標(biāo)采樣頻率，頻率太高會(huì)增加監(jiān)控成本。
• 監(jiān)控覆蓋率，最好能夠覆蓋到所有核心的系統(tǒng)指標(biāo)。
• 監(jiān)控有效性，監(jiān)控指標(biāo)不是越多越好，太多會(huì)給分辨報(bào)警有效性帶來(lái)額外工作量，也會(huì)讓開(kāi)發(fā)人員習(xí)以為常。
• 告警時(shí)效，對(duì)于跑批任務(wù)這種非實(shí)時(shí)交易類系統(tǒng)，可以不用實(shí)時(shí)告警，記錄事件后定一個(gè)時(shí)間，比如早晨8點(diǎn)觸發(fā)告警，責(zé)任人到公司后處理。

為避免長(zhǎng)尾效應(yīng)，最好不要使用平均值。如下圖：

圖片10個(gè)請(qǐng)求，有9個(gè)延遲都是1秒，但有1個(gè)延遲是10秒，所以平均值參考意義并不大。

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

2 故障管理

2.1 常見(jiàn)故障原因

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

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

2.2 應(yīng)對(duì)策略

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

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

2.2.1 軟件升級(jí)故障

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

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

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

2.2.2 硬件資源故障

這類故障主要分為兩類：

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

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

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

2.3 系統(tǒng)過(guò)載

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

2.4 惡意攻擊

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

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

2.5 基礎(chǔ)軟件故障

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

3 發(fā)布管理

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

3.1 發(fā)布流程

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

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

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

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

3.2.1 CheckList

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

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

3.2.2 灰度發(fā)布

灰度發(fā)布是指在黑與白之間，能夠平滑過(guò)渡的一種發(fā)布方式。如下圖：圖片升級(jí)時(shí)采用金絲雀部署的方式，先把其中一個(gè)server作為金絲雀進(jìn)行發(fā)布升級(jí)，這個(gè)server在生產(chǎn)環(huán)境運(yùn)行后沒(méi)有問(wèn)題，再升級(jí)其他的server。有問(wèn)題則進(jìn)行回滾。

3.2.2 藍(lán)綠部署

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

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

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

3.2.4 ab測(cè)試

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

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

ab測(cè)試的版本都是已經(jīng)是驗(yàn)證沒(méi)有問(wèn)題的，這點(diǎn)不同于灰度發(fā)布。

3.2.4 配置變更

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

引入配置中心

使用外部系統(tǒng)保存配置

4 容量管理

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

業(yè)務(wù)持續(xù)增加給系統(tǒng)帶來(lái)的流量不斷增加

系統(tǒng)資源收縮，比如一臺(tái)機(jī)器上新部署了一個(gè)應(yīng)用，占用了一些資源

系統(tǒng)處理請(qǐng)求變慢，比如因?yàn)閿?shù)據(jù)量變大，數(shù)據(jù)庫(kù)響應(yīng)變慢，導(dǎo)致單個(gè)請(qǐng)求處理時(shí)間變長(zhǎng)，資源不能釋放

重試導(dǎo)致的請(qǐng)求增加

突增流量，比如微博系統(tǒng)遇到明星離婚案之類的新聞。

4.1 重試

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

對(duì)于連接超時(shí)的請(qǐng)求，可能是網(wǎng)絡(luò)瞬時(shí)故障造成的，這種情況下重試并不會(huì)對(duì)服務(wù)端造成壓力，因?yàn)槭〉恼?qǐng)求壓根就沒(méi)有到達(dá)服務(wù)端。

但是對(duì)于響應(yīng)超時(shí)的請(qǐng)求，如果進(jìn)行重試，可能會(huì)給服務(wù)端帶來(lái)額外的壓力。如下圖：圖片正常情況下，客戶端先調(diào)用服務(wù)A，服務(wù)A再調(diào)用服務(wù)B，服務(wù)B只被調(diào)用了一次。

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

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

對(duì)于重試，有如下3個(gè)建議：

非核心業(yè)務(wù)不重試，如果重試，必須限定次數(shù)

重試時(shí)間間隔要指數(shù)增加

根據(jù)返回失敗的狀態(tài)進(jìn)行重試，比如服務(wù)端定義一個(gè)拒絕碼，客戶端就不重試了

4.2 突增流量

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

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

kubectl scale deployment springboot-deployment --replicas=4 

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

• google guava
• netflix/concurrency-limits
• sentinel

4.3 容量規(guī)劃

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

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

4.4 服務(wù)降級(jí)

服務(wù)降級(jí)對(duì)于服務(wù)端來(lái)說(shuō)，可以有三種方式：

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

5 總結(jié)

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

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

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