可用性的理解

理解目標

業(yè)界高可用的目標是幾個9，對于每一個系統(tǒng)，要求是不一樣的。研發(fā)人員對所設(shè)計或者開發(fā)的系統(tǒng)，要知道用戶規(guī)模及使用場景，知道可用性的目標。

比如，5個9的目標對應的是全年故障5分鐘。

拆解目標

幾個9的目標比較抽象，需要對目標進行合理的分解，可以分解成如下兩個子目標。

頻率要低：減少出故障的次數(shù)

不出問題，一定是高可用的，但這是不可能的。系統(tǒng)越大、越復雜，只能盡量避免問題，通過系統(tǒng)設(shè)計、流程機制來減少出問題的概率。但如果經(jīng)常出問題，后面恢復再快也是沒有用的。

時間要快：縮短故障的恢復時間

故障出現(xiàn)時，不是解決或者定位到具體問題，而是快速恢復是***要務的，防止次生災害，問題擴大。這里就要求要站在業(yè)務角度思考，而不僅是技術(shù)角度思考。

下面，我們就按這兩個子目標來分別闡述。

頻率要低：減少出故障的次數(shù)

設(shè)計：根據(jù)業(yè)務變化不斷進行迭代

以點評交易系統(tǒng)的演進過程為例。

幼兒時期：2012年前

使命：滿足業(yè)務要求，快速上線。

因為2011年要快速地把團購產(chǎn)品推向市場，臨時從各個團隊抽取的人才，大部分對.NET更熟悉，所以使用.NET進行了***代的團購系統(tǒng)設(shè)計。畢 竟?jié)M足業(yè)務要求是***的，還沒有機會遇到可用性等質(zhì)量問題?？紤]比較簡單，即使都掛了，量也比較小，出現(xiàn)問題，重啟、擴容、回滾就解決問題了。

系統(tǒng)架構(gòu)如下圖所示。

少年時期：垂直拆分（2012-2013）

使命：研發(fā)效率&故障隔離。

當2012年在團單量從千到萬量級變化，用戶每日的下單量也到了萬級時候，需要考慮的是迭代速度、研發(fā)效率。垂直拆分，有助于保持小而美的團隊，研 發(fā)效率才能更高。另外一方面也需要將各個業(yè)務相互隔離，比如商品首頁的展示、商品詳情頁的展示，訂單、支付流程的穩(wěn)定性要求不一樣。前面可以緩存，可以做 靜態(tài)化來保證可用性，提供一些柔性體驗。后面支付系統(tǒng)做異地容災，比如我們除了南匯機房支付系統(tǒng)，在寶山機房也部署了，只是后來發(fā)現(xiàn)這個系統(tǒng)演進太快，沒 有工具和機制保證雙機房更新，所以后來也不好使用了。

系統(tǒng)演進如下圖所示。服務垂直化了，但是數(shù)據(jù)沒有完整隔離開，服務之間還需要互相訪問非自己的數(shù)據(jù)。

青年時期：服務做小，不共享數(shù)據(jù)（2014-2015）

使命：支撐業(yè)務快速發(fā)展，提供高效、高可用的技術(shù)能力。

從2013年開始，Deal－service （商品系統(tǒng)）偶爾會因為某一次大流量（大促或者常規(guī)活動）而掛掉，每幾個月總有那么一次，基本上可用性就在3個9徘徊。這里訂單和支付系統(tǒng)很穩(wěn)定，因為流 量在商品詳情頁到訂單有一個轉(zhuǎn)化率，流量大了詳情頁就掛了，訂單也就沒有流量了。后來詳情頁的靜態(tài)化比較好了，能減少恢復的速度，能降級，但是Deal- service的各個系統(tǒng)依賴太深了，還是不能保證整體端到端的可用性。

所以2014年對Deal-service做了很大的重構(gòu)，大系統(tǒng)做小，把商品詳情系統(tǒng)拆成了無數(shù)小服務，比如庫存服務、價格服務、基礎(chǔ)數(shù)據(jù)服務等 等。這下商品詳情頁的問題解決了，后面壓力就來了，訂單系統(tǒng)的壓力增大。2014年10月起，訂單系統(tǒng)、支付系統(tǒng)也啟動了全面微服務化，經(jīng)過大約1年的實 踐，訂單系統(tǒng)、促銷系統(tǒng)、支付系統(tǒng)這3個領(lǐng)域后面的服務總和都快上百個了，后面對應的數(shù)據(jù)庫20多個，這樣能支撐到每日訂單量***。

業(yè)務的增長在應用服務層面是可以擴容的，但是***的單點——數(shù)據(jù)庫是集中式的，這個階段我們主要是把應用的數(shù)據(jù)訪問在讀寫上分離，數(shù)據(jù)庫提供更多的從庫來解決讀的問題，但是寫入仍然是***的瓶頸（MySQL的讀可以擴展，而寫入QPS也就小2萬）。

這時系統(tǒng)演變成如下圖所示。這個架構(gòu)大約能支撐QPS 3000左右的訂單量。

成年時期：水平拆分（2015至今）

使命：系統(tǒng)要能支撐大規(guī)模的促銷活動，訂單系統(tǒng)能支撐每秒幾萬的QPS，每日上千萬的訂單量。

2015年的917吃貨節(jié)，流量***峰，如果我們?nèi)匀皇乔懊娴募夹g(shù)架構(gòu)，必然會掛掉。所以在917這個大促的前幾個月，我們就在訂單系統(tǒng)進行了架構(gòu) 升級和水平拆分，核心就是解決數(shù)據(jù)單點，把訂單表拆分成了1024張表，分布在32個數(shù)據(jù)庫，每個庫32張表。這樣在可見的未來都不用太擔心了。

雖然數(shù)據(jù)層的問題解決了，但是我們還是有些單點，比如我們用的消息隊列、網(wǎng)絡、機房等。舉幾個我過去曾經(jīng)遇到的不容易碰到的可用性問題：

服務的網(wǎng)卡有一個壞了，沒有被監(jiān)測到，后來發(fā)現(xiàn)另一個網(wǎng)卡也壞了，這樣服務就掛了。

我們使用 cache的時候發(fā)現(xiàn)可用性在高峰期非常低，后來發(fā)現(xiàn)這個cache服務器跟公司監(jiān)控系統(tǒng)CAT服務器在一個機柜，高峰期的流量被CAT占了一大半，業(yè)務的網(wǎng)絡流量不夠了。

917大促的時候我們對消息隊列這個依賴的通道能力評估出現(xiàn)了偏差，也沒有備份方案，所以造成了一小部分的延遲。

這個時期系統(tǒng)演進為下圖這樣：

未來：思路仍然是大系統(tǒng)做小，基礎(chǔ)通道做大，流量分塊

大系統(tǒng)做小，就是把復雜系統(tǒng)拆成單一職責系統(tǒng)，并從單機、主備、集群、異地等架構(gòu)方向擴展。

基礎(chǔ)通道做大就是把基礎(chǔ)通信框架、帶寬等高速路做大。

流量分塊就是把用戶流量按照某種模型拆分，讓他們聚合在某一個服務集群完成，閉環(huán)解決。

系統(tǒng)可能會演進為下圖這樣：

上面點評交易系統(tǒng)的發(fā)展幾個階段，只以業(yè)務系統(tǒng)的演進為例。除了這些還有CDN、DNS、網(wǎng)絡、機房等各個時期遇到的不同的可用性問題，真實遇到過的就有：聯(lián)通的網(wǎng)絡掛了，需要切換到電信；數(shù)據(jù)庫的電源被人踢掉了，等等。

易運營

高可用性的系統(tǒng)一定是可運營的。聽到運營，大家更多想到的是產(chǎn)品運營，其實技術(shù)也有運營——線上的質(zhì)量、流程的運營，比如，整個系統(tǒng)上線后，是否方便切換流量，是否方便開關(guān)，是否方便擴展。這里有幾個基本要求：

可限流

線上的流量永遠有想不到的情況，在這種情況下，系統(tǒng)的穩(wěn)定吞吐能力就非常重要了，高并發(fā)的系統(tǒng)一般采取的策略是快速失敗機制，比如系統(tǒng)QPS能支撐 5000，但是1萬的流量過來，我能保證持續(xù)的5000，其他5000我快速失敗，這樣很快1萬的流量就被消化掉了。比如917的支付系統(tǒng)就是采取了流量 限制，如果超過某一個流量峰值，我們就自動返回“請稍后再試”等。

無狀態(tài)

應用系統(tǒng)要完全無狀態(tài)，運維才能隨便擴容、分配流量。

降級能力

降級能力是跟產(chǎn)品一起來看的，需要看降級后對用戶體驗的影響。簡單的比如：提示語是什么。比如支付渠道，如果支付寶渠道掛了，我們掛了50% ，支付寶旁邊會自動出現(xiàn)一個提示，表示這個渠道可能不穩(wěn)定，但是可以點擊；當支付寶渠道掛了100% ，我們的按鈕變成灰色的，不能點擊，但也會有提示，比如換其他支付渠道（剛剛微信支付還掛了，就又起作用了）。另一個案例，我們在917大促的時候?qū)δ承?依賴方，比如誠信的校驗，這種如果判斷比較耗資源，又可控的情況下，可以通過開關(guān)直接關(guān)閉或者啟用。

可測試

無論架構(gòu)多么***，驗證這一步必不可少，系統(tǒng)的可測試性就非常重要。

測試的目的要先預估流量的大小，比如某次大促，要跟產(chǎn)品、運營討論流量的來源、活動的力度，每一張頁面的，每一個按鈕的位置，都要進行較準確的預估。

此外還要測試集群的能力。有很多同學在實施的時候總喜歡測試單臺，然后水平放大，給一個結(jié)論，但這不是很準確，要分析所有的流量在系統(tǒng)間流轉(zhuǎn)時候的 比例。尤其對流量模型的測試（要注意高峰流量模型跟平常流量模型可能不一致）系統(tǒng)架構(gòu)的容量測試，比如我們某一次大促的測試方法

從上到下評估流量，從下至上評估能力：發(fā)現(xiàn)一次訂單提交有20次數(shù)據(jù)庫訪問，讀寫比例高峰期是1:1，然后就跟進數(shù)據(jù)庫的能力倒推系統(tǒng)應該放入的流量，然后做好前端的異步下單，讓整個流量平緩地下放到數(shù)據(jù)庫。

降低發(fā)布風險

嚴格的發(fā)布流程

目前點評的發(fā)布都是開發(fā)自己負責，通過平臺自己完成的。上線的流程，發(fā)布的常規(guī)流程模板如下：

灰度機制

服務器發(fā)布是分批的，按照10%、30%、50%、100%的發(fā)布，開發(fā)人員通過觀察監(jiān)控系統(tǒng)的曲線及系統(tǒng)的日志，確定業(yè)務是否正常。

線上的流量灰度機制，重要功能上線能有按照某種流量灰度上線能力。

可回滾是標配，***有最壞情況的預案。

時間要快：縮短故障的恢復時間

如果目標就要保證全年不出故障或者出了故障在5分鐘之內(nèi)能解決，要對5分鐘進行充分的使用。5分鐘應該這樣拆解：1分鐘發(fā)現(xiàn)故障，3分鐘定位故障出 現(xiàn)在哪個服務，再加上后面的恢復時間。就是整個時間的分解，目前我們系統(tǒng)大致能做到前面2步，離整體5個9的目標還有差距，因為恢復的速度跟架構(gòu)的設(shè)計， 信息在開發(fā)、運維、DBA之間的溝通速度及工具能力，及處理問題人員的本身能力有關(guān)。

生命值：

持續(xù)關(guān)注線上運行情況

熟悉并感知系統(tǒng)變化，要快就要熟，熟能生巧，所以要關(guān)注線上運營情況。

了解應用所在的網(wǎng)絡、服務器性能、存儲、數(shù)據(jù)庫等系統(tǒng)指標。

能監(jiān)控應用的執(zhí)行狀態(tài)，熟悉應用自己的QPS、響應時間、可用性指標，并對依賴的上下游的流量情況同樣熟悉。

保證系統(tǒng)穩(wěn)定吞吐

系統(tǒng)如果能做好流量控制、容錯，保證穩(wěn)定的吞吐，能保證大部分場景的可用，也能很快地消化高峰流量，避免出現(xiàn)故障，產(chǎn)生流量的多次高峰。

故障時

快速的發(fā)現(xiàn)機制

告警的移動化

系統(tǒng)可用性的告警應該全部用微信、短信這種能保證找到人的通信機制。

告警的實時化

目前我們只能做到1分鐘左右告警。

監(jiān)控的可視化

我們系統(tǒng)目前的要求是1分鐘發(fā)現(xiàn)故障，3分鐘定位故障。這就需要做好監(jiān)控的可視化，在所有關(guān)鍵service里面的方法層面打點，然后做成監(jiān)控曲 線，不然3分鐘定位到具體是哪個地方出問題，比較困難。點評的監(jiān)控系統(tǒng)CAT能很好的提供這些指標變化，我們系統(tǒng)在這些基礎(chǔ)上也做了一些更實時的能力，比 如訂單系統(tǒng)QPS就是秒級的監(jiān)控曲線。

有效的恢復機制

比如運維的四板斧：回滾、重啟、擴容、下服務器。在系統(tǒng)不是很復雜、流量不是很高的情況下，這能解決問題，但大流量的時候就很難了，所以要更多地從流量控制、降級體驗方面下功夫。

幾點經(jīng)驗

珍惜每次真實高峰流量，建立高峰期流量模型。

因為平常的壓力測試很難覆蓋到各種情況，而線上的真實流量能如實地反映出系統(tǒng)的瓶頸，能較真實地評估出應用、數(shù)據(jù)庫等在高峰期的表現(xiàn)。

珍惜每次線上故障復盤，上一層樓看問題，下一層樓解決問題。

線上出問題后，要有一套方法論來分析，比如常見的“5W”，連續(xù)多問幾個為什么，然后系統(tǒng)思考解決方案，再逐漸落地。

可用性不只是技術(shù)問題。

系統(tǒng)初期：以開發(fā)為主；

系統(tǒng)中期：開發(fā)＋DBA＋運維為主；

系統(tǒng)后期：技術(shù)＋產(chǎn)品＋運維＋DBA。

系統(tǒng)較簡單、量較小時，開發(fā)同學能比較容易地定位問題并較容易解決問題。

當系統(tǒng)進入較復雜的中期時，就需要跟運維、數(shù)據(jù)庫的同學一起來看系統(tǒng)的瓶頸。

當系統(tǒng)進入復雜的后期時，系統(tǒng)在任何時候都要考慮不可用的時候如何提供柔性體驗，這就需要從產(chǎn)品角度來思考。

單點和發(fā)布是可用性***的敵人。

可用性要解決的核心問題就是單點，比如常見的手段：垂直拆分、水平拆分、灰度發(fā)布；單機到主備、集群、異地容災等等。

另外，系統(tǒng)發(fā)布也是引起系統(tǒng)故障的關(guān)鍵點，比如常見的系統(tǒng)發(fā)布、數(shù)據(jù)庫維護等其他引起系統(tǒng)結(jié)構(gòu)變化的操作。