聊一聊互聯(lián)網(wǎng)三高架構(gòu)中的系統(tǒng)穩(wěn)定性

一、前言

高并發(fā)、高可用、高性能被稱為互聯(lián)網(wǎng)三高架構(gòu)，這三者都是工程師和架構(gòu)師在系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一。今天我們就來聊一聊三H中的高可用，也是我們常說的系統(tǒng)穩(wěn)定性。

本篇文章只聊思路，沒有太多的深入細節(jié)。閱讀全文大概需要5~10分鐘。

二、高可用的定義

業(yè)界常用 N 個 9 來量化一個系統(tǒng)可用性程度，可以直接映射到網(wǎng)站正常運行時間的百分比上。

可用性的計算公式：

?

大部分公司的要求是4個9，也就是年度宕機時長不能超過53分鐘，實際要達到這個目標還是非常困難的，需要各個子模塊相互配合。

要想提升一個系統(tǒng)的可用性，首先需要知道影響系統(tǒng)穩(wěn)定性的因素有哪些。

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

首先我們先梳理一下影響系統(tǒng)穩(wěn)定性的一些常見的問題場景，大致可分為三類：

人為因素

不合理的變更、外部攻擊等等

軟件因素

代碼bug、設(shè)計漏洞、GC問題、線程池異常、上下游異常

硬件因素

網(wǎng)絡(luò)故障、機器故障等 下面就是對癥下藥，首先是故障前的預(yù)防，其次是故障后的快速恢復(fù)能力，下面我們就聊聊幾種常見的解決思路。

四、提升穩(wěn)定性的幾種思路

4.1 系統(tǒng)拆分

拆分不是以減少不可用時間為目的，而是以減少故障影響面為目的。因為一個大的系統(tǒng)拆分成了幾個小的獨立模塊，一個模塊出了問題不會影響到其他的模塊，從而降低故障的影響面。系統(tǒng)拆分又包括接入層拆分、服務(wù)拆分、數(shù)據(jù)庫拆分。

接入層&服務(wù)層

一般是按照業(yè)務(wù)模塊、重要程度、變更頻次等維度拆分。

數(shù)據(jù)層

一般先按照業(yè)務(wù)拆分后，如果有需要還可以做垂直拆分也就是數(shù)據(jù)分片、讀寫分離、數(shù)據(jù)冷熱分離等。

4.2 解耦

系統(tǒng)進行拆分之后，會分成多個模塊。模塊之間的依賴有強弱之分。如果是強依賴的，那么如果依賴方出問題了，也會受到牽連出問題。這時可以梳理整個流程的調(diào)用關(guān)系，做成弱依賴調(diào)用。弱依賴調(diào)用可以用MQ的方式來實現(xiàn)解耦。即使下游出現(xiàn)問題，也不會影響當前模塊。

4.3 技術(shù)選型

可以在適用性、優(yōu)缺點、產(chǎn)品口碑、社區(qū)活躍度、實戰(zhàn)案例、擴展性等多個方面進行全量評估，挑選出適合當前業(yè)務(wù)場景的中間件&數(shù)據(jù)庫。前期的調(diào)研一定要充分，先對比、測試、研究，再決定，磨刀不誤砍柴工。

4.4 冗余部署&故障自動轉(zhuǎn)移

服務(wù)層的冗余部署很好理解，一個服務(wù)部署多個節(jié)點，有了冗余之后還不夠，每次出現(xiàn)故障需要人工介入恢復(fù)勢必會增加系統(tǒng)的不可服務(wù)時間。

所以，又往往是通過“自動故障轉(zhuǎn)移”來實現(xiàn)系統(tǒng)的高可用。即某個節(jié)點宕機后需要能自動摘除上游流量，這些能力基本上都可以通過負載均衡的探活機制來實現(xiàn)。

涉及到數(shù)據(jù)層就比較復(fù)雜了，但是一般都有成熟的方案可以做參考。一般分為一主一從、一主多從、多主多從。不過大致的原理都是數(shù)據(jù)同步實現(xiàn)多從，數(shù)據(jù)分片實現(xiàn)多主，故障轉(zhuǎn)移時都是通過選舉算法選出新的主節(jié)點后在對外提供服務(wù)（這里如果寫入的時候不做強一致同步，故障轉(zhuǎn)移時會丟失一部分數(shù)據(jù)）。具體可以參考Redis Cluster、ZK、Kafka等集群架構(gòu)。

4.5 容量評估

在系統(tǒng)上線前需要對整個服務(wù)用到的機器、DB、cache都要做容量評估，機器容量的容量可以采用以下方式評估：

明確預(yù)期流量指標-QPS；

明確可接受的時延和安全水位指標（比如CPU%≤40%，核心鏈路RT≤50ms）；

通過壓測評估單機在安全水位以下能支持的最高QPS（建議通過混合場景來驗證，比如按照預(yù)估流量配比同時壓測多個核心接口）；

最后就可以估算出具體的機器數(shù)量了。

DB和cache評估除了QPS之外還需要評估數(shù)據(jù)量，方法大致相同，等到系統(tǒng)上線后就可以根據(jù)監(jiān)控指標做擴縮容了。

4.6 服務(wù)快速擴容能力&泄洪能力

現(xiàn)階段不論是容器還是ECS，單純的節(jié)點復(fù)制擴容是很容易的，擴容的重點需要評估的是服務(wù)本身是不是無狀態(tài)的，比如：

下游DB的連接數(shù)最多支持當前服務(wù)擴容幾臺？

擴容后緩存是否需要預(yù)熱？

放量策略

這些因素都是需要提前做好準備，整理出完備的SOP文檔，當然最好的方式是進行演練，實際上手操作，有備無患。

泄洪能力一般是指冗余部署的情況下，選擇幾個節(jié)點作為備用節(jié)點，平時承擔(dān)很小一部分流量，當流量洪峰來臨時，通過調(diào)整流量路由策略把熱節(jié)點的一部分流量轉(zhuǎn)移到備用節(jié)點上。

對比擴容方案這種成本相對較高，但是好處就是響應(yīng)快，風(fēng)險小。

4.7 流量整形&熔斷降級

?

流量整形也就是常說的限流，主要是防止超過預(yù)期外的流量把服務(wù)打垮，熔斷則是為了自身組件或者依賴下游故障時，可以快速失敗防止長期阻塞導(dǎo)致雪崩。

關(guān)于限流熔斷的能力，開源組件Sentinel基本上都具備了，用起來也很簡單方便，但是有一些點需要注意。

限流閾值一般是配置為服務(wù)的某個資源能支撐的最高水位，這個需要通過壓測摸底來評估。隨著系統(tǒng)的迭代，這個值可能是需要持續(xù)調(diào)整的。如果配置的過高，會導(dǎo)致系統(tǒng)崩潰時還沒觸發(fā)保護，配置的過低會導(dǎo)致誤傷。

熔斷降級-某個接口或者某個資源熔斷后，要根據(jù)業(yè)務(wù)場景跟熔斷資源的重要程度來評估應(yīng)該拋出異常還是返回一個兜底結(jié)果。

比如下單場景如果扣減庫存接口發(fā)生熔斷，由于扣減庫存在下單接口是必要條件，所以熔斷后只能拋出異常讓整個鏈路失敗回滾，如果是獲取商品評論相關(guān)的接口發(fā)生熔斷，那么可以選擇返回一個空，不影響整個鏈路。

4.8資源隔離

如果一個服務(wù)的多個下游同時出現(xiàn)阻塞，單個下游接口一直達不到熔斷標準（比如異常比例跟慢請求比例沒達到閾值），那么將會導(dǎo)致整個服務(wù)的吞吐量下降和更多的線程數(shù)占用，極端情況下甚至導(dǎo)致線程池耗盡。引入資源隔離后，可以限制單個下游接口可使用的最大線程資源，確保在未熔斷前盡可能小的影響整個服務(wù)的吞吐量。

說到隔離機制，這里可以擴展說一下，由于每個接口的流量跟RT都不一樣，很難去設(shè)置一個比較合理的可用最大線程數(shù)，并且隨著業(yè)務(wù)迭代，這個閾值也難以維護。這里可以采用共享加獨占來解決這個問題，每個接口有自己的獨占線程資源，當獨占資源占滿后，使用共享資源，共享池在達到一定水位后，強制使用獨占資源，排隊等待。這種機制優(yōu)點比較明顯就是可以在資源利用最大化的同時保證隔離性。

這里的線程數(shù)只是資源的一種，資源也可以是連接數(shù)、內(nèi)存等等。

4.9系統(tǒng)性保護

系統(tǒng)性保護是一種無差別限流，一句話概念就是在系統(tǒng)快要崩潰之前對所有流量入口進行無差別限流，當系統(tǒng)恢復(fù)到健康水位后停止限流。具體一點就是結(jié)合應(yīng)用的 Load、總體平均 RT、入口 QPS 和線程數(shù)等幾個維度的監(jiān)控指標，讓系統(tǒng)的入口流量和系統(tǒng)的負載達到一個平衡，讓系統(tǒng)盡可能跑在最大吞吐量的同時保證系統(tǒng)整體的穩(wěn)定性。

4.10 可觀測性&告警

?

當系統(tǒng)出現(xiàn)故障時，我們首先需找到故障的原因，然后才是解決問題，最后讓系統(tǒng)恢復(fù)。排障的速度很大程度上決定了整個故障恢復(fù)的時長，而可觀測性的最大價值在于快速排障。其次基于Metrics、Traces、Logs三大支柱配置告警規(guī)則，可以提前發(fā)現(xiàn)系統(tǒng)可能存在的風(fēng)險&問題，避免故障的發(fā)生。

4.11 變更流程三板斧

變更是可用性最大的敵人，99%的故障都是來自于變更，可能是配置變更，代碼變更，機器變更等等。那么如何減少變更帶來的故障呢？

可灰度

用小比例的一部分流量來驗證變更后的內(nèi)容，減小影響用戶群。

可回滾

出現(xiàn)問題后，能有有效的回滾機制。涉及到數(shù)據(jù)修改的，發(fā)布后會引起臟數(shù)據(jù)的寫入，需要有可靠的回滾流程，保證臟數(shù)據(jù)的清除。

可觀測

通過觀察變更前后的指標變化，很大程度上可以提前發(fā)現(xiàn)問題。 除了以上三板斧外，還應(yīng)該在其他開發(fā)流程上做規(guī)范，比如代碼控制，集成編譯、自動化測試、靜態(tài)代碼掃描等。

五、總結(jié)

對于一個動態(tài)演進的系統(tǒng)而言，我們沒有辦法將故障發(fā)生的概率降為0，能做的只有盡可能的預(yù)防和縮短故障時的恢復(fù)時間。當然我們也不用一味的追求可用性，畢竟提升穩(wěn)定性的同時，維護成本、機器成本等也會跟著上漲，所以需要結(jié)合系統(tǒng)的業(yè)務(wù)SLO要求，適合的才是最好的。

如何做好穩(wěn)定性和高可用保障是一個很龐大的命題，本篇文章沒有太多的深入細節(jié)，只聊了整體的一些思路，主要是為了大家在以后的系統(tǒng)高可用建設(shè)過程中，有一套系統(tǒng)的框架可以參考。最后感謝耐心看完的同學(xué)。

審核編輯：劉清