前言

關(guān)于軟件的高可用，是一個(gè)老生常談的話題。“高可用性”（High Availability）通常來(lái)描述一個(gè)系統(tǒng)經(jīng)過(guò)專門的設(shè)計(jì)，從而減少停工時(shí)間，而保持其服務(wù)的高度可用性。其計(jì)算公式是：可用率=（總時(shí)間-不可用時(shí)間）/總時(shí)間。

本文重點(diǎn)從落地實(shí)踐的視角作為切入點(diǎn)，帶領(lǐng)大家從協(xié)作效率，技術(shù)落地和運(yùn)營(yíng)規(guī)范幾個(gè)方面來(lái)展現(xiàn)高可用的實(shí)施步驟和落地細(xì)節(jié)。為了方便理解，先來(lái)統(tǒng)一語(yǔ)言話術(shù)，看一下軟件交付過(guò)程中的各個(gè)階段，如下圖：

為什么說(shuō)軟件的高可用會(huì)面臨著諸多挑戰(zhàn)呢？

從需求交付鏈路來(lái)看，要完成目標(biāo)交付，需要產(chǎn)品，研發(fā)，測(cè)試，運(yùn)維，運(yùn)營(yíng)等多方利益相關(guān)者的密切配合。有些項(xiàng)目需求，合作者有時(shí)能夠達(dá)到上百人，每個(gè)人職責(zé)分工各不相同，但卻相互配合依賴，任何一個(gè)環(huán)節(jié)出現(xiàn)紕漏，可用率就有可能受到影響；

從時(shí)間角度來(lái)看，如果要達(dá)到全年99.99%的可用率，就意味著一年當(dāng)中，允許有故障的時(shí)間為：365*24*60*（100%-99.99%）=52分鐘，如果要達(dá)到5個(gè)9的可用率，允許故障的時(shí)間僅為5分鐘，這差不多是我們發(fā)現(xiàn)問(wèn)題后，重啟應(yīng)用的耗時(shí)；

從迭代效率來(lái)看，不迭代，不上線，問(wèn)題出現(xiàn)的概率一定會(huì)小很多。軟件的迭代效率和可用率之間存在著負(fù)相關(guān)的關(guān)系，平衡好兩者之間的關(guān)系，也會(huì)面臨著不小的挑戰(zhàn)。

總結(jié)一下，我們具體面臨的問(wèn)題如下：

如何解決需求交付相關(guān)協(xié)作者多，鏈路長(zhǎng)的問(wèn)題？

如何應(yīng)對(duì)故障時(shí)間容忍度低的問(wèn)題？

如何在頻繁需求迭代的現(xiàn)狀下，保持可用率不受到大的沖擊問(wèn)題？

協(xié)作效率保障

01認(rèn)知誤區(qū)

從整個(gè)需求交付鏈路我們可以發(fā)現(xiàn)，隨著鏈路的逐級(jí)遞增，信息的傳遞鏈路分支就會(huì)越多，傳遞層級(jí)就會(huì)越深。這會(huì)導(dǎo)致兩個(gè)問(wèn)題：

1.信息傳遞效率降低；

2.信息準(zhǔn)確性變差。

這兩個(gè)問(wèn)題最終導(dǎo)致的結(jié)果，就是協(xié)作效率的降低。

一個(gè)沒有實(shí)戰(zhàn)經(jīng)驗(yàn)的同學(xué)往往會(huì)認(rèn)為增加人數(shù)，就會(huì)提高需求交付效率。其實(shí)這種想法不完全正確，具體關(guān)系參考下圖：

這就像蓋樓房，如果一個(gè)人按部就班的建設(shè)，需要100天完成。如果請(qǐng)了100個(gè)人來(lái)幫忙，能否用1天的時(shí)間完成房子建設(shè)呢？答案是否定的。

這里面有協(xié)作的成本，比如：團(tuán)隊(duì)默契（設(shè)計(jì)師，瓦工，泥工，水電工），崗位匹配，風(fēng)險(xiǎn)控制；

這里面有流程的依賴，比如：施工依賴于設(shè)計(jì)，軟裝總在硬裝之后；

這里面有成本預(yù)算，比如：整個(gè)組織的人才梯度，規(guī)模大小（承建方，代理商，承包商）；

以上這些，都不是簡(jiǎn)單的通過(guò)人力鋪設(shè)來(lái)解決的。

02流程規(guī)范

提高協(xié)作效率的底層邏輯是通過(guò)減少交付鏈路層級(jí)，縮短信息傳遞鏈路，進(jìn)而保證信息的準(zhǔn)確性和傳遞效率。（組織建設(shè)層面的內(nèi)容這里不做展開）

這就要求具有今日事，今日畢的行動(dòng)力。組織層面這叫流程規(guī)范，個(gè)人層面這叫做事方法，責(zé)任心。

盡量避免將當(dāng)下的事情拖延到下一個(gè)環(huán)節(jié)，否則就會(huì)影響后續(xù)鏈路的排期計(jì)劃和交付效率，極端情況甚至?xí)霈F(xiàn)返工的情形。簡(jiǎn)言之，考慮清楚，不埋坑。產(chǎn)品需求對(duì)研發(fā)，研發(fā)設(shè)計(jì)對(duì)測(cè)試，測(cè)試用例對(duì)產(chǎn)品等各個(gè)交付節(jié)點(diǎn)都是如此，交付物一定是靠譜的。

技術(shù)落地保障

在需求響應(yīng)周期中，高質(zhì)量的落實(shí)架構(gòu)設(shè)計(jì)，編碼實(shí)現(xiàn)，安全上線，部署運(yùn)營(yíng)等生產(chǎn)階段，是軟件高可用落地保障的前提和基礎(chǔ)。

01架構(gòu)設(shè)計(jì)

架構(gòu)設(shè)計(jì)往往影響著系統(tǒng)的前期實(shí)現(xiàn)成本（即ROI）和后續(xù)運(yùn)維難度，屬于軟件的頂層設(shè)計(jì)，這里面既包含宏觀的設(shè)計(jì)方案，也包含落地細(xì)節(jié)里的范式約束。

流程保障

邀請(qǐng)架構(gòu)師參與：核心交易節(jié)點(diǎn)、重大需求改動(dòng)邀請(qǐng)架構(gòu)師參與，這是閉坑最直接有效的方式；

重視設(shè)計(jì)文檔：方案描述清楚了，并取得相關(guān)利益者的認(rèn)可，是走在正確道路上的前提。

設(shè)計(jì)保障

容災(zāi)設(shè)計(jì)：要預(yù)留后路，提前想清楚，做好容災(zāi)設(shè)計(jì)。可回滾，可熔斷，可重試，可降級(jí)。

魯棒性設(shè)計(jì)：無(wú)狀態(tài)設(shè)計(jì)，防重設(shè)計(jì)，冪等設(shè)計(jì)，數(shù)據(jù)一致性設(shè)計(jì)

02編碼實(shí)現(xiàn)

如果說(shuō)架構(gòu)設(shè)計(jì)是骨架，那么編碼實(shí)現(xiàn)就是神經(jīng)，血管和肌肉。前者決定了能走多穩(wěn)，走多久，后者決定著走多快，走多遠(yuǎn)。落實(shí)到編碼層面，就是代碼的衰老腐敗程度。

流程規(guī)范

代碼評(píng)審機(jī)制：代碼評(píng)審不僅僅是發(fā)現(xiàn)系統(tǒng)中存在的問(wèn)題這么簡(jiǎn)單。它是一種長(zhǎng)期行為，是進(jìn)行組織文化貫徹和傳承的一種形式和載體。評(píng)審的過(guò)程中，明確了業(yè)務(wù)職責(zé)邊界，設(shè)計(jì)與編碼共識(shí)，優(yōu)秀的標(biāo)準(zhǔn)導(dǎo)向等研發(fā)共識(shí)。相當(dāng)于通過(guò)具象化的案例，給出針對(duì)性的指導(dǎo)，這些都是保證團(tuán)隊(duì)?wèi)?zhàn)斗力的基石。

研發(fā)過(guò)程中的很多問(wèn)題，通過(guò)代碼評(píng)審機(jī)制可以被發(fā)現(xiàn)和解決，比如：

如何對(duì)待臨時(shí)需求的設(shè)計(jì)與實(shí)現(xiàn)？

如何看待“Hello World!”的N中寫法？

如何理解設(shè)計(jì)模式和過(guò)度設(shè)計(jì)的邊界？

如何評(píng)價(jià)當(dāng)前階段的交付物？

是否有必要引入單元測(cè)試？

代碼規(guī)范

有沒有對(duì)錯(cuò)誤進(jìn)行處理？對(duì)于調(diào)用的外部服務(wù)，是否檢查了返回值或處理了異常？

設(shè)計(jì)是否遵從已知的設(shè)計(jì)模式或項(xiàng)目中常用的模式？

開發(fā)者新寫的代碼能否用已有的SDK/Framework中的功能實(shí)現(xiàn)？在本項(xiàng)目中是否存在類似的功能可以調(diào)用而不用全部重新實(shí)現(xiàn)？

工程中是否引入了無(wú)用的，功能重復(fù)的，不同版本的jar包依賴？（json類庫(kù)，各種utils）

有沒有無(wú)用的代碼可以清除？

代碼可讀性如何？有沒有足夠的注釋？

參數(shù)傳遞有無(wú)錯(cuò)誤，有沒有使用斷言（Assert）或判斷來(lái)保證我們認(rèn)為不變的條件真的得到滿足？

邊界條件是如何處理的？switch語(yǔ)句的default分支是如何處理的？循環(huán)有沒有可能出現(xiàn)死循環(huán)？

對(duì)資源的利用，是在哪里申請(qǐng)，在哪里釋放的？有無(wú)可能存在資源泄漏（包括超時(shí)時(shí)間，內(nèi)存、文件、對(duì)象引用，大對(duì)象，線程數(shù)等）？有沒有優(yōu)化的空間？

代碼的效能如何？最壞的情況是怎樣的？

代碼中，特別是循環(huán)中是否有明顯可優(yōu)化的部分（string的操作是否能用StringBuilder來(lái)優(yōu)化）？

對(duì)于系統(tǒng)和網(wǎng)絡(luò)的調(diào)用是否會(huì)超時(shí)？如何處理?

代碼是否易于測(cè)試（方法行數(shù)，圈復(fù)雜度，出入?yún)⒍x是否合理）？

改動(dòng)是否影響到舊版本、歷史數(shù)據(jù)、上游能否兼容？?接口設(shè)計(jì)是否有考慮冪等、并發(fā)、越權(quán)，降級(jí)等問(wèn)題？

是否存在緩存、數(shù)據(jù)庫(kù)性能問(wèn)題以及多數(shù)據(jù)源數(shù)據(jù)一致性的問(wèn)題？

上線方案是否考慮了灰度方案，數(shù)據(jù)狀態(tài)不一致問(wèn)題？

03安全上線

線上70%的故障都是由某種變更而觸發(fā)的，其中相當(dāng)一部分占比是不規(guī)范的上線引起的。所以安全上線這一環(huán)節(jié)至關(guān)重要。

流程規(guī)范

嚴(yán)禁頻繁上線：比如，每周不大于2次；

嚴(yán)禁高峰期上線：降低問(wèn)題影響范圍；

嚴(yán)禁私自上線：有改動(dòng)，必須通過(guò)測(cè)試驗(yàn)證，產(chǎn)品回歸確認(rèn)；

過(guò)程規(guī)范

摘流量：選擇第一批機(jī)器jsf下線/np摘流量(選為冷備)；

看日志：觀察日志確認(rèn)摘除機(jī)器無(wú)流量；

服務(wù)預(yù)熱：確認(rèn)機(jī)器啟動(dòng)成功，核心業(yè)務(wù)接口需要接口預(yù)熱；

掛流量：掛載上線機(jī)器流量；

看指標(biāo)：觀察上線機(jī)器mdc指標(biāo)是否異常(cpu、內(nèi)存、負(fù)載)、日志是否有異常。

04部署運(yùn)營(yíng)

實(shí)現(xiàn)高可用的一個(gè)很重要的手段就是能力冗余。下面給出方向和思路，具體落地細(xì)節(jié)和策略，可以根據(jù)具體情況各自延展。

網(wǎng)絡(luò)

運(yùn)營(yíng)商層面，聯(lián)通，電信，移動(dòng)等；

鏈路節(jié)點(diǎn)方面，VIP，CDN，路由器/交換機(jī)，反向代理，客戶端，瀏覽器等；

存儲(chǔ)

無(wú)論是數(shù)據(jù)庫(kù)主從架構(gòu)，還是ES的副本架構(gòu)，都是實(shí)現(xiàn)存儲(chǔ)高可用的手段，重要數(shù)據(jù)要利用好相關(guān)特性；

在進(jìn)行數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)時(shí)，同樣也需要做好分流策略，容量規(guī)劃，數(shù)據(jù)拆分或異構(gòu)。比如：避免緩存熱key，數(shù)據(jù)庫(kù)表吞吐量瓶頸，數(shù)據(jù)庫(kù)連接數(shù)限制等各種影響高可用的問(wèn)題出現(xiàn)。

服務(wù)

橫向擴(kuò)容：服務(wù)要保證可以通過(guò)添加資源的方式進(jìn)行能力擴(kuò)容，這一點(diǎn)非常重要；

服務(wù)分組：按照業(yè)務(wù)方或使用場(chǎng)景，對(duì)服務(wù)進(jìn)行不同粒度的隔離，防止極端情況導(dǎo)致服務(wù)相互影響；

極限策略：主要是一些極端異常情況下的防御策略，目的是意外發(fā)生后，盡量保持服務(wù)的可靠性。比如：限流，熔斷，重試，快速失敗等；

灰度策略：新功能上線，往往是最容易出現(xiàn)問(wèn)題的時(shí)候，擁有成熟的流量灰度能力，是控制問(wèn)題影響范圍的關(guān)鍵；

運(yùn)營(yíng)規(guī)范保障

01運(yùn)營(yíng)規(guī)范

1.可監(jiān)控：系統(tǒng)運(yùn)行狀況

2.可報(bào)警：異常情況能夠通知到系統(tǒng)相關(guān)人員

3.可定位：出現(xiàn)問(wèn)題后，能夠快速定位問(wèn)題原因

4.可修復(fù)：出現(xiàn)異常情況，能夠在第一時(shí)間進(jìn)行問(wèn)題修復(fù)；

02應(yīng)急預(yù)案

高可用意味著對(duì)故障時(shí)間的容忍性差，意味著沒有時(shí)間進(jìn)行故障排查和修復(fù)，更沒有時(shí)間打開代碼進(jìn)行漏洞排查。這就要求我們有一套完備的應(yīng)急預(yù)案，這套預(yù)案能夠解決大部分可預(yù)見的故障問(wèn)題。

反詐在身邊

恢復(fù)生產(chǎn)第一；

排查問(wèn)題第二；

詳細(xì)事故應(yīng)急處理手冊(cè)，可以參照下圖：

過(guò)程規(guī)范

網(wǎng)絡(luò)，服務(wù)，存儲(chǔ)分三個(gè)維度制定對(duì)應(yīng)方案，并將應(yīng)急預(yù)案清單（文件名：checklist）填寫到自己的代碼庫(kù)中，保持內(nèi)容傳承和更新；

可預(yù)見性，即問(wèn)題觸發(fā)場(chǎng)景要寫清楚。舉例：按照當(dāng)前進(jìn)度（1萬(wàn)/天），隨著數(shù)據(jù)庫(kù)數(shù)據(jù)的增加，預(yù)計(jì)10個(gè)月后，數(shù)據(jù)庫(kù)表（xxx表名）會(huì)出現(xiàn)慢查詢；

可執(zhí)行性，能夠消除問(wèn)題的解決方案。舉例：?jiǎn)?dòng)歷史數(shù)據(jù)歸檔任務(wù)（xxxWorker），將歷史數(shù)據(jù)進(jìn)行轉(zhuǎn)移到歸檔數(shù)據(jù)庫(kù)中；

03規(guī)范達(dá)標(biāo)

再好的流程和規(guī)范都需要有對(duì)應(yīng)的機(jī)制來(lái)貫徹執(zhí)行，否則就是鏡中花，水中月，看著美好，實(shí)則沒用。可執(zhí)行，能度量，是按照目標(biāo)變好的前提。所以這里給出一個(gè)《高可用達(dá)標(biāo)定期自查表》的工具，輔助規(guī)范落地。

總結(jié)

本文從“高可用為什么存在著很大挑戰(zhàn)？”的問(wèn)題展開探討，強(qiáng)調(diào)了需求交付過(guò)程中，協(xié)作效率的重要性，并指出了為什么要遵從“今日事，今日畢”的工作原則。又從架構(gòu)設(shè)計(jì)，編碼實(shí)現(xiàn)，安全上線，部署運(yùn)營(yíng)等幾個(gè)方面，詳細(xì)介紹了技術(shù)落地保障相關(guān)的指導(dǎo)規(guī)范和落地細(xì)節(jié)。最后又從上線后運(yùn)營(yíng)的角度，給出了應(yīng)急預(yù)案三板斧，規(guī)范達(dá)標(biāo)定期自查表等比較實(shí)用的運(yùn)營(yíng)保障工具。希望能夠給讀者帶來(lái)幫助。