一、前言

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

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

二、高可用的定義

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

可用性的計(jì)算公式：

?

大部分公司的要求是4個(gè)9，也就是年度宕機(jī)時(shí)長(zhǎng)不能超過(guò)53分鐘，實(shí)際要達(dá)到這個(gè)目標(biāo)還是非常困難的，需要各個(gè)子模塊相互配合。

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

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

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

人為因素

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

軟件因素

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

硬件因素

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

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

4.1 系統(tǒng)拆分

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

接入層&服務(wù)層

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

數(shù)據(jù)層

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

4.2 解耦

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

4.3 技術(shù)選型

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

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

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

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

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

4.5 容量評(píng)估

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

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

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

通過(guò)壓測(cè)評(píng)估單機(jī)在安全水位以下能支持的最高QPS（建議通過(guò)混合場(chǎng)景來(lái)驗(yàn)證，比如按照預(yù)估流量配比同時(shí)壓測(cè)多個(gè)核心接口）；

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

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

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

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

下游DB的連接數(shù)最多支持當(dāng)前服務(wù)擴(kuò)容幾臺(tái)？

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

放量策略

這些因素都是需要提前做好準(zhǔn)備，整理出完備的SOP文檔，當(dāng)然最好的方式是進(jìn)行演練，實(shí)際上手操作，有備無(wú)患。

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

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

4.7 流量整形&熔斷降級(jí)

?

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

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

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

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

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

4.8資源隔離

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

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

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

4.9系統(tǒng)性保護(hù)

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

4.10 可觀測(cè)性&告警

?

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

4.11 變更流程三板斧

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

可灰度

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

可回滾

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

可觀測(cè)

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

五、總結(jié)

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

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

審核編輯：劉清