建站
咨詢
售后
建站咨詢
新聞中心
Part One 可用性概念一覽
概念一：MTBF (mean time between failure)
MTBF是指兩次相鄰的系統(tǒng)失效(服務(wù)故障)之間的工作時間長度。也可以叫它無故障時間 或 失效間隔。這個值越大，說明系統(tǒng)的故障率越低，系統(tǒng)越可靠。因此，我們通常希望這個時間間隔越大越好。
概念二：MTTR (mean time to repair)
MTTR是指從出現(xiàn)故障到修復中間的時間長度。也叫做修復時間。這個值越低，說明故障越容易恢復，系統(tǒng)可維護性越好。因此，我們通常希望這個時間間隔越小越好。
因此，系統(tǒng)可用性可以量化為：
MTBF / (MTBF + MTTR)
示例：系統(tǒng)的可用性要求 99.999% ，那么，按一年365天來算:
全年允許的宕機時間只有5分鐘多一點。
Part Two 高可用的保障
全年宕機5分鐘?從上一部分可以知道，我們的目的，是要盡可能的增大系統(tǒng)的無故障運行時間，同時，在發(fā)生故障時，盡可能迅速的完成恢復。
故障的發(fā)生多種多樣，經(jīng)過了這么多年的研發(fā)前輩的踩坑，我們可以將其分類匯總，并給出分析和對應(yīng)的方案。
Level1: 配置修改出錯
最不應(yīng)該犯的錯，但是感覺很多人都沒少犯。
原因也很簡單，要不就是格式錯了，要不就是配置的數(shù)據(jù)不對，而且錯誤的配置還被直接發(fā)到了線上，直接導致業(yè)務(wù)異常，甚至宕機。
解決方案主要是兩部分：變更管控 + 配置灰度
- 用工單+審批的方式，讓配置變更流程化、正規(guī)化，提升配置變更的被重視程度。
- 利用配置灰度發(fā)布平臺功能，通過測試和灰度多環(huán)境的上線前驗證加上版本可回滾的能力，減少由于配置問題造成的可用性降級。
Level2: 代碼BUG
人為BUG往往是系統(tǒng)異常的罪魁禍首。coder? 不，請叫我buger ~ 雖然最是常見，但這一部分又是相對最容易應(yīng)對的。
解決方案有兩個方面：
把控研發(fā)質(zhì)量 + 測試質(zhì)量：
- 需要通過系統(tǒng)分析文檔的撰寫和評審提前分析業(yè)務(wù)問題和系統(tǒng)邊界。
- 通過容錯設(shè)計、單側(cè)、CR來完善代碼的健壯性。
- 通過測試分析來明確測試重點和影響點。
- 通過線上請求錄制回放等仿真測試來保證原有的邏輯不受影響。
Level3: 依賴服務(wù)故障
業(yè)務(wù)高速發(fā)展，系統(tǒng)被水平垂直拆分，越來越復雜，幾乎沒有哪個系統(tǒng)可以獨立存在，總歸會有依賴。
然而，依賴系統(tǒng)在整個業(yè)務(wù)流程中占比很重，但我們自己又無法把控，因此，服務(wù)的依賴治理，是可用性保障中的非常重要的一環(huán)。
解決方案包括：
依賴梳理+指標約定+故障解決
- 首先，要根據(jù)業(yè)務(wù)本身的情況，梳理出強弱依賴，不同級別的依賴區(qū)分應(yīng)對。比如，弱依賴就可以剝離主鏈路，采用異步或離線等方式進行;而強依賴如RPC中間件，就只能增加監(jiān)控，提高問題發(fā)現(xiàn)速率。
- 其次，定制指標，做好指標監(jiān)控和百分位預(yù)警。比如對依賴系統(tǒng)的調(diào)用量預(yù)估以及sla約定，達到百分位閾值時，及時報警
- 再次，制定故障預(yù)案，如主鏈路的限流、弱依賴的熔斷等。預(yù)案需要多次演練才能上線。
Level4: 突發(fā)流量和流量洪峰對應(yīng)不足
讓業(yè)務(wù)按我們預(yù)先計劃的線路增長是不切實際的?？赃臧T肚做個需求想讓它漲10%，結(jié)果沒漲反而掉了，當你不注意的時候，突然來了一波上漲，都是很常見的事~
應(yīng)對方法有兩個方面：
流量規(guī)律預(yù)估 + 異常流量防護
- 規(guī)律方面，要分析業(yè)務(wù)規(guī)律，合理安排策略，如請求排隊，提前擴容等。如打車場景，流量高峰(上下班)和流量突發(fā)(雨雪大風天)的情況都非常典型。為啥經(jīng)常遇到司機吐槽接不到單，為啥一到雨雪天就要從派單模式切換成搶單模式，真的是因為選擇性突然變多了么~
- 異常流量方面，要讓上游協(xié)助減少無效重試，用緩存等策略防止底層服務(wù)雪崩。如電商商品詳情系統(tǒng)，一到晚上流量就徒增，爬蟲無疑;再如系統(tǒng)超時導致用戶不斷刷新的流量放大
Level5: 容量預(yù)估不足
上述的流量預(yù)估其實屬于容量預(yù)估的一個方面，除此之外，還有緩存容量、底層數(shù)據(jù)存儲容量、服務(wù)器容量、帶寬容量等等。
應(yīng)對方案有四個方面：
容量規(guī)劃+限流降級+冗余+全鏈路壓測
- 前期，需要做好容量規(guī)劃和容量預(yù)警方案，爭取把可能的突發(fā)流量都考慮在內(nèi)，核心模塊盡量實現(xiàn)冗余部署、容災(zāi)部署;同時，利用多維度的報警，盡量早和及時的發(fā)現(xiàn)容量問題。
- 故障發(fā)生時，依據(jù)前面提到的依賴服務(wù)治理方案，根據(jù)重要程度的不同，進行限流、降級或熔斷。減少對容量的持續(xù)沖擊。
- 故障發(fā)生后，利用冗余部署，快速切換路由，分擔當前單元的容量壓力。
- 單服務(wù)壓測只能摸到當前服務(wù)的高度，但是這個高度是否滿足全鏈路的要求，就需要全鏈路去呀，這個時候，全局統(tǒng)一的路由、影子庫等的基礎(chǔ)建設(shè)就至關(guān)重要了。
Level6: 硬件甚至整個機房故障
相比于動則百萬造價的大型服務(wù)器，普通計算機以及docker的穩(wěn)定性要大打折扣。因此，宕機是難免的事，除了服務(wù)器，還有交換機甚至是光纖抖動都有可能發(fā)生。
而應(yīng)對方案有兩個方面：分散+冗余:
- 正所謂不要把雞蛋都裝到一個籃子里，而要多分幾個籃子裝。這樣，一個籃子打了，不至于影響全部雞蛋。螞蟻的單元化部署就是這個思路，不同的用戶按ID分到不同的處理單元，因此，就算這個單元全宕了，最差的情況也只會影響到這個單元的用戶群。
- 冗余，則是有備無患的思想。主從互備、同城機房互備、兩地三中心、三地五中心則是這個思路的具體落地。
Part Three 總結(jié)
越是重要的系統(tǒng)，對高可用的要求越高。而高可用的治理，會很考驗整個技術(shù)團隊的技術(shù)沉淀。如果后面大家遇到對系統(tǒng)可用性非常敏感的情況，希望本文可以對大家的思路和著手點有所幫忙。
當前標題：聊聊高可用方法論！你知道嗎？
標題來源：http://www.5511xx.com/article/cocicsg.html
