背景簡(jiǎn)介

對(duì)于大型應(yīng)用后臺(tái)系統(tǒng)來說，穩(wěn)定性至關(guān)重要。目前越來越多的大型應(yīng)用系統(tǒng)采用微服務(wù)架構(gòu)，更加需要關(guān)注穩(wěn)定性的技術(shù)能力建設(shè)。穩(wěn)定性是服務(wù)系統(tǒng)基礎(chǔ)能力的體現(xiàn)。

基礎(chǔ)知識(shí)

在介紹穩(wěn)定性技術(shù)策略主題之前，我們首先梳理一些基礎(chǔ)概念和知識(shí)。

針對(duì)我們業(yè)務(wù)后臺(tái)系統(tǒng)建設(shè)，任何大型業(yè)務(wù)后臺(tái)系統(tǒng)絕對(duì)不是一蹴而就。它是伴隨著業(yè)務(wù)不同階段，不斷進(jìn)行演進(jìn)的過程。如果經(jīng)歷過從 0 到 1 建設(shè)一個(gè)業(yè)務(wù)后臺(tái)系統(tǒng)的同學(xué)，都會(huì)有類似的體會(huì)。

啟動(dòng)階段

啟動(dòng)階段，業(yè)務(wù)模型相對(duì)簡(jiǎn)單，用戶量少，這時(shí)候我們可以將所有的系統(tǒng)模塊耦合在一個(gè)工程里面，進(jìn)行單機(jī)部署。這時(shí)候可能僅僅需要將業(yè)務(wù)系統(tǒng)與數(shù)據(jù)庫(kù)進(jìn)行隔離。

探索階段

探索階段，業(yè)務(wù)模型不斷演進(jìn)，用戶量增加，單機(jī)服務(wù)能力瓶頸凸顯。這時(shí)候就需要由單機(jī)服務(wù)部署向集群服務(wù)部署來優(yōu)化，利用負(fù)載均衡將請(qǐng)求合理分配，減少單機(jī)服務(wù)壓力。另外一個(gè)方面，數(shù)據(jù)量不斷的增加，也需要考慮針對(duì)數(shù)據(jù)來進(jìn)行水平的擴(kuò)展(主從部署，讀寫分離)。

在這一階段，我們僅僅是做了集群擴(kuò)展，但所有的業(yè)務(wù)代碼都在同一個(gè)工程維護(hù)，所有的數(shù)據(jù)信息都在同一個(gè)數(shù)據(jù)庫(kù)中存儲(chǔ)。隨著團(tuán)隊(duì)的擴(kuò)充與業(yè)務(wù)交互不斷復(fù)雜化，在工程維護(hù)上存在很大的風(fēng)險(xiǎn)，工程研發(fā)效率受到制約，業(yè)務(wù)代碼之間的耦合也難以清晰，系統(tǒng)可靠性存在很大風(fēng)險(xiǎn)，一個(gè) bug 可能會(huì)造成整個(gè)應(yīng)用的崩潰不可用。

發(fā)展階段

如果我們比較幸運(yùn)，業(yè)務(wù)持續(xù)快速發(fā)展，對(duì)于業(yè)務(wù)角色模型理解越來越清晰，業(yè)務(wù)角色模型之間的交互越來越確定。這時(shí)候就需要我們基于對(duì)業(yè)務(wù)充分的理解前提下進(jìn)行垂直拆分。不同的業(yè)務(wù)模型會(huì)部署到不同的系統(tǒng)工程中，工程之間通過接口來進(jìn)行交互。這樣工程內(nèi)業(yè)務(wù)高度集中，工程間通過接口服務(wù)來進(jìn)行解耦。這時(shí)候不管是系統(tǒng)維護(hù)，還是業(yè)務(wù)模塊維護(hù)，都將大大的提高效率。數(shù)據(jù)部分同樣垂直拆分，不同業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)，從而提高單機(jī)數(shù)據(jù)庫(kù)的能力。

拿電商系統(tǒng)的結(jié)構(gòu)來說，如下圖所示：

基于業(yè)務(wù)模型分為幾個(gè)大的系統(tǒng)服務(wù)，系統(tǒng)服務(wù)之間通過內(nèi)部 RPC 接口來進(jìn)行交互。

成熟階段

上面是基于大的業(yè)務(wù)模型進(jìn)行劃分，隨著業(yè)務(wù)復(fù)雜度越來越高，我們必將對(duì)大業(yè)務(wù)模型，基于功能或者業(yè)務(wù)邊界進(jìn)行更細(xì)粒度的拆分。比如說，我們可以將產(chǎn)品中心劃分為：基礎(chǔ)信息中心，庫(kù)存管理中心，SKU 中心等。

這時(shí)候就涉及到微服務(wù)的拆分與治理工作。

微服務(wù)的拆分原則我們應(yīng)該注意：業(yè)務(wù)功能單一； 服務(wù)間業(yè)務(wù)邊界清晰；拆分粒度合理； 分層劃分合理。

從研發(fā)的角度來說，微服務(wù)帶來的好處：研發(fā)效率提升；代碼質(zhì)量更優(yōu)；能夠獨(dú)立部署；單模塊復(fù)雜度降低。上面提到的產(chǎn)品中心我們可以拆分很多小的服務(wù)來提供，如下圖所示：

細(xì)粒度的拆分，也會(huì)帶來一定的挑戰(zhàn)：

微服務(wù)劃分單元越細(xì)，整體服務(wù)維護(hù)非常復(fù)雜；

微服務(wù)通過 RPC 接口交互，整個(gè)鏈路可能會(huì)不清晰；

單服務(wù)的修改或者優(yōu)化會(huì)受到其他模塊的牽制。

當(dāng)然這些挑戰(zhàn)都是我們需要思考與解決的問題，并不能抹殺微服務(wù)的優(yōu)點(diǎn)。

大型業(yè)務(wù)后臺(tái)系統(tǒng)，不斷的微服務(wù)化，帶來系統(tǒng)之間的接口交互與依賴管理也越來越重要。我們需要從整體上考慮我們?nèi)绾伪ＷC這樣一個(gè)流量并發(fā)高，業(yè)務(wù)模型復(fù)雜，服務(wù)依賴交互多的大型微服務(wù)后臺(tái)應(yīng)用系統(tǒng)的穩(wěn)定性。不能由于某個(gè)不利因素來影響整個(gè)業(yè)務(wù)微服務(wù)系統(tǒng)的不可用。接下來我們將重點(diǎn)介紹穩(wěn)定性相關(guān)的內(nèi)容。

穩(wěn)定性技術(shù)策略

什么是穩(wěn)定性

對(duì)于大型微服務(wù)系統(tǒng)，在錯(cuò)綜復(fù)雜的服務(wù)邏輯各種交互情景下，面對(duì)各種未知的條件變化，整體系統(tǒng)依舊能夠正常平穩(wěn)的提供服務(wù)，這便是穩(wěn)定性。

影響穩(wěn)定性的因素

系統(tǒng)穩(wěn)定性影響因素非常多，舉例來說：

1. 服務(wù)間的依賴：某個(gè)服務(wù) BUG 造成其他依賴服務(wù)的不可用；

2. 業(yè)務(wù)邏輯變更：業(yè)務(wù)邏輯不斷迭代演變，新老服務(wù)的不兼容；

3. 訪問流量激增：流量突然增加，比如我們進(jìn)行促銷活動(dòng)期間，導(dǎo)致服務(wù)壓力過大 ，達(dá)到服務(wù)能力上限，從而導(dǎo)致服務(wù)崩潰；

4. 機(jī)器老化異常：任何機(jī)器和人一樣，都有生老病死，隨著長(zhǎng)時(shí)間的運(yùn)行，也會(huì)有磨損，因此某個(gè)機(jī)器故障，也是可能的異常。

還有其他各方面的因素，在這里就不進(jìn)行窮盡了，大家可以思考一下，還有那些經(jīng)典的影響因素。

穩(wěn)定性的衡量標(biāo)準(zhǔn)

穩(wěn)定性衡量標(biāo)準(zhǔn)一般用 N 個(gè) 9 來衡量。如表格所示：

名稱級(jí)別年度停機(jī)時(shí)間描述2 個(gè) 999%87.6 小時(shí)基本可用3 個(gè) 999.9%8.8 小時(shí)較高可用性4 個(gè) 999.99%53 分鐘技術(shù)容災(zāi)能力可用性5 個(gè) 999.999%5 分鐘極高可用性

比如說某個(gè)系統(tǒng)網(wǎng)站全年穩(wěn)定性達(dá)到 4 個(gè) 9 ，意味著全年服務(wù)不可用的時(shí)間小于等于 53 分鐘。

穩(wěn)定性技術(shù)策略

穩(wěn)定性的技術(shù)策略，是我們本文介紹的重點(diǎn)，從大的方面來說，穩(wěn)定性技術(shù)策略包含：監(jiān)控，冗余，限流，降級(jí)，回滾，重試。

監(jiān)控

監(jiān)控是指對(duì)整個(gè)系統(tǒng)服務(wù)進(jìn)行實(shí)時(shí)的監(jiān)控操作，準(zhǔn)確反饋系統(tǒng)運(yùn)行狀態(tài)，能夠做到及時(shí)發(fā)現(xiàn)異常故障，記錄詳細(xì)日志與數(shù)據(jù)，提高故障發(fā)現(xiàn)，定位，解決的效率。從而提高系統(tǒng)服務(wù)整體穩(wěn)定性。

監(jiān)控是保證穩(wěn)定性最基礎(chǔ)工作。我們將重點(diǎn)介紹監(jiān)控需要從幾個(gè)方面考慮？ 有哪些監(jiān)控方向？

監(jiān)控可以分為以下幾類來進(jìn)行：

流量監(jiān)控

流量監(jiān)控包括：PV、 UV、 IP，熱門頁(yè)面，用戶響應(yīng)時(shí)間。

這些基本的流量指標(biāo)就不在這里向大家詳細(xì)說明了，如果有不太清楚的同學(xué)可以自己搜索一下。

在流量監(jiān)控這塊，我們需要注意的是：流量毛刺。流量毛刺往往代表了系統(tǒng)某個(gè)風(fēng)險(xiǎn)點(diǎn)或者異常情況的發(fā)生。

一個(gè)正常業(yè)務(wù)的流量趨勢(shì)具備周期一致性特征。比如說，一個(gè)業(yè)務(wù)每天的流量峰值一般在中午 12:00 和下午 18:00，那么這種峰值在沒有特殊情況出現(xiàn)的前提下，應(yīng)該會(huì)遵循該峰值時(shí)間規(guī)律。 那么流量毛刺是啥呢？ 如下圖所示：

從圖中左側(cè)部分可以看到，8 點(diǎn)鐘有流量的突增，這時(shí)候我們需要確認(rèn)為什么會(huì)有流量的突增。是業(yè)務(wù)的正常表現(xiàn)，還是有其他的異常流量進(jìn)入。

從圖中右側(cè)部分可以看到，每條曲線代表了每一天的流量統(tǒng)計(jì)，紅色曲線相對(duì)于其他幾天的流量曲線在凌晨 3:00 和早上 8:00 的時(shí)候有明顯的流量毛刺，這時(shí)候我們就需要確認(rèn)是什么因素造成流量數(shù)據(jù)的突變。

通過對(duì)于流量毛刺的觀察，能夠讓我們及時(shí)了解業(yè)務(wù)中的風(fēng)險(xiǎn)，及時(shí)做好預(yù)警與準(zhǔn)備。

業(yè)務(wù)監(jiān)控

業(yè)務(wù)監(jiān)控是根據(jù)業(yè)務(wù)屬性來定義監(jiān)控指標(biāo)，可以用于判定整體業(yè)務(wù)的運(yùn)轉(zhuǎn)是否正常。不同業(yè)務(wù)類型監(jiān)控的指標(biāo)肯定有所不同，比如電商場(chǎng)景、物流場(chǎng)景、游戲場(chǎng)景是完全不同的監(jiān)控方向。

我們拿一個(gè)電商交易業(yè)務(wù)系統(tǒng)來舉例，看看有哪些監(jiān)控指標(biāo)？大家可以參考著思考自己目前負(fù)責(zé)的業(yè)務(wù)指標(biāo)。舉例來說針對(duì)一個(gè)電商交易系統(tǒng)我們可以監(jiān)控的業(yè)務(wù)指標(biāo)有：

用戶下單監(jiān)控：秒/分/時(shí) 用戶下單統(tǒng)計(jì) ；

用戶支付監(jiān)控：秒/分/時(shí) 用戶支付統(tǒng)計(jì)；

用戶退款情況：秒/分/時(shí) 用戶退款統(tǒng)計(jì)；

商品庫(kù)存狀態(tài)：庫(kù)存消耗/剩余統(tǒng)計(jì)；

業(yè)務(wù) GMV 監(jiān)控：業(yè)務(wù)整體銷售額統(tǒng)計(jì)；

商家在線狀態(tài)：監(jiān)控商家在線狀態(tài)；

促銷運(yùn)營(yíng)監(jiān)控：監(jiān)控促銷金額與數(shù)量。

在業(yè)務(wù)監(jiān)控中，還需要重點(diǎn)關(guān)注業(yè)務(wù)轉(zhuǎn)化漏斗概念。流量漏斗可以看出業(yè)務(wù)轉(zhuǎn)化率以及用戶的訪問深度。它是業(yè)務(wù)健康程度的監(jiān)控，也是部分需求效果的衡量標(biāo)準(zhǔn)。

機(jī)器監(jiān)控

機(jī)器監(jiān)控需要關(guān)注的內(nèi)容，應(yīng)該是后臺(tái)研發(fā)比較熟悉的部分。 主要監(jiān)控方向包含下面幾個(gè)部分：

當(dāng)然在 linux 系統(tǒng)中，也有各種常用指令，來進(jìn)行該類數(shù)據(jù)的收集：top、free、ping、iostat、netstat。

對(duì)于 Java 系統(tǒng)來說，需要進(jìn)行 JVM 層面的監(jiān)控內(nèi)容，比如說：gc 的情況，線程創(chuàng)建銷毀情況，full gc 情況，內(nèi)存不同模塊使用情況等。 JVM 同樣也提供了指令集，方便我們進(jìn)行信息的查找：jstat、jps、stack、jmap、jhat 等。

日志記錄

在日志的打印過程中，我們需要注意日志的打印規(guī)范，日志打印內(nèi)容應(yīng)該包含對(duì)于問題排查有益的信息，并且日志格式清晰，可解析性高。日志一般是打印到服務(wù)器磁盤上面，但是由于單機(jī)磁盤能力有限，并且對(duì)于大型分布式系統(tǒng)來說需要整體收集不同服務(wù)器模塊的日志，進(jìn)行統(tǒng)一分析，提高問題排查效率。這時(shí)候就需要一個(gè)集中式的日志中心。

日志中心的核心能力一般包含：獲取日志、存儲(chǔ)日志、展示日志、分析日志、報(bào)警服務(wù)。

相對(duì)比較簡(jiǎn)單的實(shí)現(xiàn)方式可以采用ELK快速搭建自己的日志中心。

我們利用 kafka 將日志信息，進(jìn)行異步廣播，然后進(jìn)行日志的解析，存儲(chǔ)到 ES 檢索系統(tǒng)中，利用 kibana 來進(jìn)行日志的檢索、查看等。進(jìn)一步提升日志的有效管理。

冗余

冗余的對(duì)立面是單點(diǎn)。冗余可以有效的減少單點(diǎn)問題造成的影響。大家可以思考一下，如果一個(gè)系統(tǒng)服務(wù)只部署到一臺(tái)機(jī)器，機(jī)器服務(wù)掛掉之后，意味著服務(wù)不可用，依賴于它的服務(wù)也會(huì)出現(xiàn)異常，最壞的情況可能會(huì)造成雪崩。

為了簡(jiǎn)化冗余的思考，我們將整個(gè)應(yīng)用后臺(tái)架構(gòu)簡(jiǎn)化為四層架構(gòu)，如下圖所示：

最上層是用戶訪問，然后到反向代理，Nginx 為流量入口； 然后到站點(diǎn)應(yīng)用，比如說咱們的 Tomcat 或者 Jetty 應(yīng)用服務(wù)器； 最后是數(shù)據(jù)層 db；為了性能優(yōu)化增加了 Cache 服務(wù)。

大家思考一下，如果這幾層服務(wù)，全部的都是單點(diǎn)，單點(diǎn)就是我們只有一個(gè)機(jī)器去部署這些服務(wù)。Nginx 只有一臺(tái)機(jī)器，Server 應(yīng)用也只有一臺(tái)機(jī)器。如果機(jī)器宕機(jī)會(huì)造成什么樣的后果？會(huì)直接導(dǎo)致整個(gè)系統(tǒng)服務(wù)不可用，這個(gè)就是單點(diǎn)的風(fēng)險(xiǎn)。

完全依賴一個(gè)單點(diǎn) 沒有任何冗余備份，導(dǎo)致服務(wù)的穩(wěn)定性非常脆弱。

怎么去做冗余呢？

對(duì)于 Nginx 層與 Server 層，我們可以從下面幾個(gè)方向考慮冗余：

多機(jī)部署：同一個(gè)機(jī)房?jī)?nèi)，部署多個(gè)服務(wù)節(jié)點(diǎn)，其中一臺(tái)掛掉，還有同機(jī)房的冗余備份；

跨機(jī)房部署：不同機(jī)房?jī)?nèi)，部署多個(gè)服務(wù)幾點(diǎn)，其中一個(gè)機(jī)房斷電或者其他異常情況，還有其他機(jī)房來備份提供支持；

異地多活：如果所有機(jī)房都在同一個(gè)城市，就會(huì)造成地域單點(diǎn)，比如說城市光纖異常。這時(shí)候異地多活部署就會(huì)減少這部分影響。

對(duì)于數(shù)據(jù)層面比如 MySQL、Redis 都有自身提供的冗余方案。 MySQL 自身提供了主從部署，主從同步的機(jī)制，系統(tǒng)服務(wù)可以進(jìn)行讀主寫從操作。

Redis 也類似，提供了集群冗余方案：主從配置，哨兵機(jī)制，集群模式。

Redis 集群模式能夠?qū)崿F(xiàn)數(shù)據(jù)分區(qū)冗余備份，主從同步，多主容災(zāi)，故障自動(dòng)轉(zhuǎn)移能力。

冗余的思路，在業(yè)務(wù)實(shí)現(xiàn)方向也可以落地考慮，比如說重要數(shù)據(jù)的多介質(zhì)存儲(chǔ)；重要組件的多版本選擇等等。

限流

大型微服務(wù)架構(gòu)中的任何服務(wù)節(jié)點(diǎn)，不管咱們?cè)趺磧?yōu)化，怎么拓展，都會(huì)有能力上限。如果達(dá)到能力上線，系統(tǒng)服務(wù)奔潰的可能性增加，這種情況也很容易造成整個(gè)微服務(wù)應(yīng)用的雪崩效應(yīng)。

作為一個(gè)面向用戶的網(wǎng)站，有時(shí)候我們會(huì)面對(duì)流量激增的情形，如果這時(shí)候達(dá)到了我們某個(gè)或者多個(gè)服務(wù)的能力上限，我們應(yīng)該怎么保證系統(tǒng)的穩(wěn)定性?

限流在這種情形下就起到了作用。

限流的目的

就是當(dāng)服務(wù)器的壓力劇增的情況下，為了保證服務(wù)不被拖垮，對(duì)一些流量采取拒絕或者降級(jí)的策略，以此來保證核心服務(wù)的正常運(yùn)轉(zhuǎn)。這是一種有損的技術(shù)手段。

將部分流量進(jìn)行限制速率，控制輸入和輸出，將超過限制速率部分的流量，進(jìn)行拒絕服務(wù)、或者排隊(duì)等措施。以此來達(dá)到系統(tǒng)的自我保護(hù)目的。

限流策略：

限流策略有三種常用方式：

1. 總量計(jì)數(shù)限流：并發(fā)量或者訪問量超過設(shè)定的閾值，將拒絕提供服務(wù)；

2. 漏桶限流算法：一個(gè)固定容量漏斗，任意速率流入或者生成并發(fā)或者訪問，但會(huì)以一個(gè)固定的速率執(zhí)行這些并發(fā)或者訪問。如果超過固定容量的部分將被拒絕；

3. 令牌桶限流算法：一個(gè)固定容量的令牌通，令牌按照固定速率放到桶中，請(qǐng)求到來時(shí)候先去令牌通獲取令牌，如果獲取到則可以進(jìn)入業(yè)務(wù)邏輯部分，獲取不到則不會(huì)執(zhí)行。

三者的區(qū)別：

限流的維度

如下圖所示，限流思考從三個(gè)維度去思考：

限流的實(shí)現(xiàn)

1. 基于 AtomicLong 來實(shí)現(xiàn)單機(jī)(接口)總量計(jì)數(shù)法限流；

2. 基于 Semaphore 信號(hào)量來實(shí)現(xiàn)單機(jī)(接口)總量計(jì)數(shù)法限流；

3. 利用 Guava limiter 來實(shí)現(xiàn)令牌通的算法；

4. 對(duì)于分布式限流，我們可以考慮，利用 Redis 的 Incr 來進(jìn)行實(shí)現(xiàn)。

降級(jí)

降級(jí)的目的

1. 削弱非核心服務(wù)資源占用；

2. 保證業(yè)務(wù)核心服務(wù)穩(wěn)定性。

舉例來說：

一個(gè)交易平臺(tái)，有用戶下單，支付等功能，同時(shí)也有用戶評(píng)論，商品推薦，廣告推薦等模塊。在促銷活動(dòng)期間，用戶大批量的進(jìn)入，那么這時(shí)候由于功能模塊非常多，流量或者機(jī)器資源消耗非常大。造成系統(tǒng)整體負(fù)載過高。那么很可能出現(xiàn)一個(gè)可怕的情況，用戶沒辦法進(jìn)行正常交易。

面對(duì)這種情況，我們應(yīng)該怎么做？這時(shí)候降級(jí)就體現(xiàn)了它的實(shí)用價(jià)值。

降級(jí)策略

降級(jí)策略有很多方面需要思考與落地，在這里總結(jié)一下經(jīng)常用到降級(jí)策略。

頁(yè)面降級(jí)：非核心頁(yè)面模塊，占用緊張資源，關(guān)停該頁(yè)面，減少訪問；

服務(wù)降級(jí)：將功能分類，分為核心服務(wù)與非核心服務(wù)，將非核心服務(wù)進(jìn)行關(guān)停；

依賴降級(jí)：將依賴服務(wù)梳理分類，保證核心依賴的穩(wěn)定，將非核心進(jìn)行降級(jí)關(guān)停；

讀寫降級(jí)：將直接讀寫數(shù)據(jù)庫(kù)切換為讀寫緩存； 對(duì)于緩存依舊可以進(jìn)行備份冗余；

延遲降級(jí)：頁(yè)面的異步加載策略； 數(shù)據(jù)寫入異步消息隊(duì)列等。

降級(jí)實(shí)現(xiàn)

降級(jí)就需要一個(gè)分布式開關(guān)，通過開關(guān)來確定降級(jí)策略的啟動(dòng)與否。 分布式開關(guān)的實(shí)現(xiàn)方式，我們也簡(jiǎn)述一下：

基于 Redis 實(shí)現(xiàn)；

基于 ZK 來實(shí)現(xiàn)；

基于內(nèi)部數(shù)據(jù)庫(kù)來實(shí)現(xiàn)。

每個(gè)具體的實(shí)現(xiàn)方式大家如果感興趣可以查閱一下資料，基本上都是功能實(shí)現(xiàn)相對(duì)簡(jiǎn)單。

合理降級(jí)了解了降級(jí)方法之后， 我們還需要清楚不是所有服務(wù)都能降級(jí)，也不是等到故障發(fā)生了以后，才去選擇或者確定哪些服務(wù)可以降級(jí)。故障的降級(jí)策略一定是要提前去規(guī)劃與思考。

系統(tǒng)或者服務(wù)需要分為核心系統(tǒng)和非核心系統(tǒng)(核心服務(wù)和非核心服務(wù))來區(qū)分。核心服務(wù)是我們力保不能有任何問題的主流程服務(wù) P0； 非核心服務(wù)，又可以根據(jù)重要性進(jìn)行再次分層?？梢詣澐譃?P1、P2、P3 服務(wù)。

P0 服務(wù)網(wǎng)為主服務(wù)，是力保穩(wěn)定性的對(duì)象，他們掛了整個(gè)業(yè)務(wù)也就崩潰；

P1 服務(wù)為與緊密主服務(wù)相關(guān)，但可以后續(xù)異步補(bǔ)償來操作的服務(wù)，比如說，結(jié)算流水，訂單統(tǒng)計(jì)；

P2 服務(wù)與主服務(wù)有點(diǎn)相關(guān)，但關(guān)閉了對(duì)主服務(wù)任何業(yè)務(wù)邏輯沒有影響，比如說，訂單評(píng)價(jià)，商品推薦等；

P3 服務(wù)于主服務(wù)沒有相關(guān)，關(guān)閉之后對(duì)主服務(wù)沒有任何影響 比如說，廣告推薦，用戶喜好，評(píng)論瀏覽等。

在梳理服務(wù)等級(jí)的時(shí)候，需要注意 2-8 原則 也就是 20% 的系統(tǒng)為核心系統(tǒng)，80% 的系統(tǒng)為非核心服務(wù)。

回滾

根據(jù)經(jīng)驗(yàn)，線上的大部分 BUG 都是由于新需求或者新的工程改動(dòng)造成的。

那么當(dāng)系統(tǒng)出現(xiàn) BUG 或者不穩(wěn)定的時(shí)候，考慮到尋找或者排查問題耗時(shí)會(huì)比較久，我們一般都會(huì)選擇先回滾然后再去尋找問題具體原因。這種方式在一定程度上保證了系統(tǒng)的穩(wěn)定性狀態(tài)。

回滾定義：快速恢復(fù)到變化之前的狀態(tài)，讓程序或者服務(wù)恢復(fù)到改動(dòng)之前的穩(wěn)定狀態(tài)?；貪L目的：及時(shí)止損，減少線上問題排查付出的代價(jià)回滾影響：新改動(dòng)的需求會(huì)延遲生效

那么我們回滾的方向又有哪些呢？

回滾方向：

1. 代碼版本，也就是新舊代碼的轉(zhuǎn)換；

2. 系統(tǒng)服務(wù)，就是講新上線部署的功能給予回滾操作，讓服務(wù)恢復(fù)到新上線前的狀態(tài)；

3. 數(shù)據(jù)內(nèi)容，將修改的數(shù)據(jù)內(nèi)容重新修改為歷史數(shù)據(jù)版本。

怎么才能科學(xué)的回滾？

如果想把回滾的工作做好，需要處理好下面的主要內(nèi)容：

發(fā)布信息規(guī)范：每次發(fā)布包，都有唯一的版本號(hào)；命名一定要規(guī)范。包含主要內(nèi)容。 舉例：工程名稱 - 模塊名稱 - 代碼版本 - 環(huán)境類型 - 日期版本 .jar(war)

代碼管理科學(xué)：代碼分支管理科學(xué)、 代碼 review 機(jī)制、工程結(jié)構(gòu)統(tǒng)一化。

代碼 review 時(shí)機(jī)：

大版本(需求)代碼必須 review；

線上 case 修復(fù)，代碼必須 review；

測(cè)試前代碼 review (保證測(cè)試質(zhì)量)；

周期固定時(shí)間，形成團(tuán)隊(duì)習(xí)慣。

數(shù)據(jù)管理規(guī)范：避免線上庫(kù)直接操作、任何變更必須有回滾腳本、線下驗(yàn)證 。

注意事項(xiàng):

盡量避免線上數(shù)據(jù)庫(kù)手動(dòng)操作；

若手動(dòng)，需要執(zhí)行詳細(xì)規(guī)范；

不斷設(shè)計(jì)減少手動(dòng)操作頻次。

工程上線規(guī)范：上線窗口避免流量高峰，灰度驗(yàn)證避免全量上線，及時(shí)驗(yàn)證回歸測(cè)試，上線通告。

重試

重試目的

配合超時(shí)機(jī)制，正確的獲取結(jié)果，同時(shí)保護(hù)系統(tǒng)資源服務(wù)；

利用多次訪問策略，減少外部抖動(dòng)對(duì)系統(tǒng)結(jié)果造成的影響；

借助冪等概念，保證信息提交成功，達(dá)到分布式一致性。

重試的場(chǎng)景可以有 異常重試，超時(shí)重試。

異常重試：我們?cè)L問某個(gè)依賴接口的時(shí)候，如果出現(xiàn)接口返回異常的情況，我們可以進(jìn)行訪問重試，從而獲取正確結(jié)果。

超時(shí)重試：接口在規(guī)定的超時(shí)時(shí)間內(nèi)沒有得到相應(yīng)的結(jié)果數(shù)據(jù)，進(jìn)行重試操作。

全局思考重試策略

如何進(jìn)行合理的超時(shí)重試策略設(shè)定，需要結(jié)合業(yè)務(wù)特點(diǎn)來進(jìn)行詳細(xì)的規(guī)劃與測(cè)試。如果設(shè)定不好，很可能造成線上問題。

超時(shí)時(shí)間過長(zhǎng)，可能導(dǎo)致服務(wù)阻塞； 超時(shí)時(shí)間太短，可能導(dǎo)致服務(wù)調(diào)用成功率降低。如果成功率降低，可能就會(huì)導(dǎo)致重試的概率加大。 重試必然會(huì)導(dǎo)致新的請(qǐng)求發(fā)生，增加一次訪問時(shí)間，可能在用戶體驗(yàn)上存在影響。

如果不斷的重試，很可能導(dǎo)致不斷的新建訪問線程，重復(fù)請(qǐng)求，導(dǎo)致三方接口的壓力。

所以超時(shí)時(shí)間 重試策略 都需要根絕我們業(yè)務(wù)特點(diǎn)進(jìn)行驗(yàn)證與設(shè)計(jì)，避免上面介紹問題的出現(xiàn)。

峰值應(yīng)對(duì)策略

當(dāng)我們業(yè)務(wù)系統(tǒng)需要進(jìn)行運(yùn)營(yíng)促銷活動(dòng)的時(shí)候，或者面臨特殊日期將要給網(wǎng)站帶來高于平時(shí)流量的時(shí)候，我們需要做好應(yīng)對(duì)流量峰值的準(zhǔn)備。我們需要系統(tǒng)的思考如何在系統(tǒng)峰值時(shí)刻保證我們大型微服務(wù)系統(tǒng)的穩(wěn)定性。

我們將峰值應(yīng)對(duì)按照時(shí)間維度進(jìn)行劃分：事前，事中，事后。

事前

前期準(zhǔn)備

確定模塊：確定本次峰值影響的工程或者服務(wù)，梳理一定要完整；

團(tuán)隊(duì)組建：根據(jù)影響模塊，確定本次維穩(wěn)參與同學(xué)(注意跨團(tuán)隊(duì))，確認(rèn)分工；

合作約定：周期性的溝通，比如周會(huì)、約會(huì)、事前會(huì)議、事后總結(jié)會(huì)議。

數(shù)據(jù)預(yù)估

容量預(yù)估方向：

數(shù)據(jù)預(yù)估的時(shí)候不僅僅要考慮峰值的應(yīng)對(duì)時(shí)候的容量冗余，同時(shí)也要考慮數(shù)據(jù)長(zhǎng)期增量的準(zhǔn)備。

系統(tǒng)壓測(cè)

系統(tǒng)壓測(cè)的維度由小到達(dá)來說：

單接口壓測(cè)：接口維度的壓測(cè)，人工根據(jù)接口模型進(jìn)行壓測(cè)數(shù)據(jù)；我們可以使用 Apach ab、Http load 來進(jìn)行。

單機(jī)初級(jí)壓測(cè)：針對(duì)機(jī)器維度來進(jìn)行整體壓測(cè)，可以人工構(gòu)造數(shù)據(jù)也可以線上訪問流量的復(fù)制來構(gòu)造壓測(cè)數(shù)據(jù)。我們可以使用 Jemeter、LoadRunner、tcp dump 等相關(guān)工具來進(jìn)行。

單機(jī)負(fù)載均衡壓測(cè)：也是針對(duì)單機(jī)維度來進(jìn)行壓測(cè)，與初級(jí)壓測(cè)不同的是，根據(jù)負(fù)責(zé)均衡，將線上流量進(jìn)行實(shí)時(shí)轉(zhuǎn)發(fā)，將流量比例向壓測(cè)機(jī)器傾斜，從而達(dá)到壓測(cè)的目的。

全鏈路壓測(cè)：全業(yè)務(wù)后臺(tái)服務(wù)整體壓測(cè)，復(fù)制線上真實(shí)流量，進(jìn)行壓測(cè)數(shù)據(jù)的改造，然后高并發(fā)的訪問業(yè)務(wù)系統(tǒng)，提前相對(duì)真實(shí)的模擬峰值到來的情形。

全鏈路壓測(cè)是最困難，涉及面最廣的一種壓測(cè)方式。同時(shí)也是最能發(fā)現(xiàn)系統(tǒng)瓶頸的一種方式，全鏈路壓測(cè)的挑戰(zhàn)有：

困難1：鏈路梳理復(fù)雜度；

困難2：多模塊，多服務(wù)，多團(tuán)隊(duì)協(xié)同；

困難3：尋找短板，避免系統(tǒng)雪崩風(fēng)險(xiǎn)；

困難4：壓測(cè)數(shù)據(jù)準(zhǔn)備，臟數(shù)據(jù)處理；

困難5：壓測(cè)統(tǒng)籌安排，數(shù)據(jù)采樣對(duì)比。

全鏈路壓測(cè)的流程如圖所示：

容災(zāi)演練

目的

主動(dòng)觸發(fā)異常，熟悉異常處理流程；

驗(yàn)證故障處理規(guī)范，不斷完善規(guī)范；

驗(yàn)證服務(wù)異常狀態(tài)，驗(yàn)證報(bào)警機(jī)制。

步驟：

目前內(nèi)容，評(píng)估影響，方案確認(rèn)；

制定故障 SOP 手冊(cè)，詳細(xì)到每一步執(zhí)行；

根據(jù) SOP 進(jìn)行問題解決執(zhí)行操作；

記錄故障數(shù)據(jù)與現(xiàn)象，監(jiān)控報(bào)警確認(rèn)；

故障分類：可以快速解決，需要外部支持。

容災(zāi)演練的 SOP 建設(shè)：

服務(wù)巡檢

在峰值到達(dá)之前的一段時(shí)間里，我們需要對(duì)系統(tǒng)服務(wù)整體巡檢，確保的我們的各項(xiàng)指標(biāo)都能正常工作，及時(shí)發(fā)現(xiàn)可能存在的風(fēng)向。

定事：

1. 對(duì)業(yè)務(wù)、流量、系統(tǒng)、機(jī)器、日志 進(jìn)行數(shù)據(jù)指標(biāo)的 check ；

2. 確保主要數(shù)據(jù)無遺漏，不重復(fù)，沒錯(cuò)誤。

定人： 專人專事，責(zé)任明確，分工合理，推進(jìn)日常巡檢工作 。

定時(shí)：

1. 根據(jù)業(yè)務(wù)特點(diǎn)周期性的進(jìn)行服務(wù)巡檢，比如每天一次，每周一次；

2. 根據(jù)業(yè)務(wù)特點(diǎn)，合理的安排巡檢的時(shí)間，比如說中午、下午。

定方案： 根據(jù)巡檢出現(xiàn)的異常數(shù)據(jù)或者不合理數(shù)據(jù)，進(jìn)行解決方案的制定 方案必須可執(zhí)行同時(shí)有完成時(shí)間點(diǎn)。

事中

峰值應(yīng)對(duì)值班

在面對(duì)峰值期間，我們需要保證團(tuán)隊(duì)資源的穩(wěn)定，需要安排核心人員進(jìn)行值班操作。值班過程中需要做一下工作：

服務(wù)觀察：業(yè)務(wù)數(shù)據(jù)，服務(wù)監(jiān)控，日志報(bào)警，趨勢(shì)檢測(cè)； **熟悉 SOP **：容災(zāi)操作 SOP ，值班 SOP ，同步 SOP；組織形式：站會(huì)，日?qǐng)?bào)，總結(jié)。

數(shù)據(jù)觀察同步

為了讓團(tuán)隊(duì)其他人或者合作團(tuán)隊(duì)了解當(dāng)前的系統(tǒng)運(yùn)行情況，我們需要在固定的時(shí)間里同步相關(guān)數(shù)據(jù)，及時(shí)檢查數(shù)據(jù)走向與趨勢(shì)。

每天固定時(shí)間進(jìn)行數(shù)據(jù)同步（盡量選擇峰值時(shí)間段）；

數(shù)據(jù)同步對(duì)象包含：業(yè)務(wù)、PM、QA、RD 多個(gè)團(tuán)隊(duì)；

統(tǒng)計(jì)指標(biāo)注意跨團(tuán)隊(duì)的理解程度（可理解的形式來描述）；

對(duì)比屬性，比如說目前峰值是上次活動(dòng)峰值的多少倍。

線上緊急情況處理

處理準(zhǔn)則：

這里特別重要的一點(diǎn)準(zhǔn)則就是，快速止損是第一要?jiǎng)?wù)，問題排查以及解決是止損之后的動(dòng)作。

這時(shí)候在快速恢復(fù)線上服務(wù)的時(shí)候，就能考察我們前期的容災(zāi)演練的效果了。

上面圖形展示的操作規(guī)范都應(yīng)該在容災(zāi) SOP 建設(shè)中覆蓋到。

事后

1. 所有報(bào)警異常的梳理與解決，所有不規(guī)范性的討論與優(yōu)化；

2. 根據(jù)真實(shí)的場(chǎng)景進(jìn)行 SOP 的優(yōu)化，這個(gè) SOP 可能包含咱們的值班 SOP 以及容災(zāi)演練 SOP 的建設(shè)；

3. 復(fù)盤討論，需要根據(jù)業(yè)務(wù)數(shù)據(jù)、流量數(shù)據(jù)、系統(tǒng)服務(wù)情況統(tǒng)一來進(jìn)行復(fù)盤整理。復(fù)盤的邊界，不僅僅是應(yīng)用后臺(tái)，還應(yīng)該也包含前端研發(fā)、SRE、運(yùn)營(yíng)產(chǎn)品、中間件平臺(tái)等。

復(fù)盤討論的內(nèi)容一般包含：

應(yīng)用后臺(tái): 峰值期間業(yè)務(wù)數(shù)據(jù)、服務(wù)性能數(shù)據(jù)、整體穩(wěn)定性數(shù)據(jù)；

前端研發(fā)：APP crash 率、性能表現(xiàn)情況、DAU、各頁(yè)面轉(zhuǎn)化率；

SRE 運(yùn)維：機(jī)房整體情況、機(jī)器負(fù)載情況、網(wǎng)絡(luò)寬帶情況、資源利用率等；

運(yùn)營(yíng)產(chǎn)品：業(yè)務(wù)指標(biāo)完成度、同比(環(huán)比)情況、未來規(guī)劃；

中間件平臺(tái)：中間件峰值穩(wěn)定性情況、容量情況、服務(wù)能力情況。

性能優(yōu)化策略

性能優(yōu)化重要性：

用戶角度：網(wǎng)站體驗(yàn)重要衡量標(biāo)準(zhǔn)；

系統(tǒng)角度：穩(wěn)定性的基本要求保障；

研發(fā)角度：自身技術(shù)能力的競(jìng)爭(zhēng)力。

在這里由于篇幅有限，我們不針對(duì)每一塊優(yōu)化的技術(shù)策略進(jìn)行詳細(xì)的講解，我們重點(diǎn)介紹一下技術(shù)優(yōu)化的整體方向與策略，以及如何選擇方案。

我們?cè)诳紤]網(wǎng)站性能優(yōu)化方案選擇的時(shí)候，從收益與投入兩個(gè)方向綜合考慮。

應(yīng)用技術(shù)棧對(duì)于后臺(tái)研發(fā)同學(xué)來說是相對(duì)比較熟悉的技術(shù)內(nèi)容，所以投入會(huì)相對(duì)較少，收益卻會(huì)很大。因?yàn)榇蟛糠中阅軆?yōu)化的問題，還都在于代碼與技術(shù)方案層面。

數(shù)據(jù)庫(kù)方面也是需要重點(diǎn)投入的方向，能夠避免業(yè)務(wù)數(shù)據(jù)獲取以及存儲(chǔ)方面的瓶頸。

其他的三個(gè)方向網(wǎng)絡(luò)優(yōu)化，容器組件，底層環(huán)境都不是業(yè)務(wù)后臺(tái)研發(fā)同學(xué)經(jīng)常學(xué)習(xí)的方向。所以這幾塊優(yōu)化方向可以考慮和公司的運(yùn)維同學(xué)進(jìn)行共同思考與建設(shè)。

當(dāng)然性能優(yōu)化是一個(gè)長(zhǎng)期重復(fù)執(zhí)行的動(dòng)作，需要進(jìn)行不斷的總結(jié)，梳理出來符合自己業(yè)務(wù)的性能優(yōu)化策略。

總結(jié)

本文介紹了大型微服務(wù)架構(gòu)后臺(tái)應(yīng)用系統(tǒng)穩(wěn)定性技術(shù)策略的介紹。每個(gè)技術(shù)點(diǎn)都需要我們持續(xù)的思考與落地，全面整體的思考穩(wěn)定性相關(guān)的建設(shè)動(dòng)作。與此同時(shí)，還進(jìn)行峰值應(yīng)對(duì)過程中穩(wěn)定性的保障工作如何開展，希望對(duì)大家有所幫助。

軟件定制 | 網(wǎng)站建設(shè) | get更多干貨

關(guān)注服務(wù)號(hào)，直接搜索公眾號(hào)名稱（汕頭創(chuàng)云科技），關(guān)注后在對(duì)話界面回復(fù)關(guān)鍵字“智能菜單”，獲取更多資訊