背景簡介

對于大型應(yīng)用后臺系統(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ǔ)知識

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

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

啟動階段

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

探索階段

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

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

發(fā)展階段

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

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

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

成熟階段

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

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

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

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

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

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

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

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

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

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

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

什么是穩(wěn)定性

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

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

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

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

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

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

4. 機器老化異常：任何機器和人一樣，都有生老病死，隨著長時間的運行，也會有磨損，因此某個機器故障，也是可能的異常。

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

穩(wěn)定性的衡量標準

穩(wěn)定性衡量標準一般用 N 個 9 來衡量。如表格所示：

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

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

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

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

監(jiān)控

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

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

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

流量監(jiān)控

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

機器監(jiān)控

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

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

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

日志記錄

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

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

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

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

冗余

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

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

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

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

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

怎么去做冗余呢？

對于 Nginx 層與 Server 層，我們可以從下面幾個方向考慮冗余：

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

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

異地多活：如果所有機房都在同一個城市，就會造成地域單點，比如說城市光纖異常。這時候異地多活部署就會減少這部分影響。

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

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

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

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

限流

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

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

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

限流的目的

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

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

限流策略：

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

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

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

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

三者的區(qū)別：

限流的維度

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

限流的實現(xiàn)

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

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

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

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

降級

降級的目的

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

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

舉例來說：

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

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

降級策略

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

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

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

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

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

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

降級實現(xiàn)

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

基于 Redis 實現(xiàn)；

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

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

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

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

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

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

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

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

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

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

回滾

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

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

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

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

回滾方向：

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ā)布包，都有唯一的版本號；命名一定要規(guī)范。包含主要內(nèi)容。 舉例：工程名稱 - 模塊名稱 - 代碼版本 - 環(huán)境類型 - 日期版本 .jar(war)

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

代碼 review 時機：

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

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

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

周期固定時間，形成團隊習(xí)慣。

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

注意事項:

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

若手動，需要執(zhí)行詳細規(guī)范；

不斷設(shè)計減少手動操作頻次。

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

重試

重試目的

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

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

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

重試的場景可以有 異常重試，超時重試。

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

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

全局思考重試策略

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

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

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

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

峰值應(yīng)對策略

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

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

事前

前期準備

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

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

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

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

容量預(yù)估方向：

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

系統(tǒng)壓測

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

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

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

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

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

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

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

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

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

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

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

全鏈路壓測的流程如圖所示：

容災(zāi)演練

目的

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

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

驗證服務(wù)異常狀態(tài)，驗證報警機制。

步驟：

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

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

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

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

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

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

服務(wù)巡檢

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

定事：

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

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

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

定時：

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

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

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

事中

峰值應(yīng)對值班

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

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

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

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

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

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

統(tǒng)計指標注意跨團隊的理解程度（可理解的形式來描述）；

對比屬性，比如說目前峰值是上次活動峰值的多少倍。

線上緊急情況處理

處理準則：

這里特別重要的一點準則就是，快速止損是第一要務(wù)，問題排查以及解決是止損之后的動作。

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

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

事后

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

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

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

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

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

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

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

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

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

性能優(yōu)化策略

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

用戶角度：網(wǎng)站體驗重要衡量標準；

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

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

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

我們在考慮網(wǎng)站性能優(yōu)化方案選擇的時候，從收益與投入兩個方向綜合考慮。

應(yīng)用技術(shù)棧對于后臺研發(fā)同學(xué)來說是相對比較熟悉的技術(shù)內(nèi)容，所以投入會相對較少，收益卻會很大。因為大部分性能優(yōu)化的問題，還都在于代碼與技術(shù)方案層面。

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

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

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

總結(jié)

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

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

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