最近一直在忙618大促的全鏈路壓測&穩定性保障相關工作，結果618還未開始，生產環境就出了幾次生產故障，且大多都是和系統穩定性、性能相關的bad case。
生產全鏈路壓測終於告一段落，抽出時間將個人收集的穩定性相關資料整理review了一遍，順帶從不同的維度，談談穩定性相關的“務虛”認知和思考。。。
一、SLA!
在開始談穩定性保障之前，我們先來聊聊業內經常提及的一個Topic：SLA！
業內喜歡用SLA （服務等級協議，全稱：service level agreement）來衡量系統的穩定性，對互聯網公司來說就是網站服務可用性的一個保證。
9越多代表全年服務可用時間越長服務越可靠，停機時間越短。就以一個標準99.99%為例，停機時間52.6分鐘，平均到每周也就是只能有差不多1分鐘的停機時間，
也就是說網絡抖動這個時間可能就沒了。保證一個系統四個9或者更高的五個9，需要一套全體共識嚴格標準的規章制度，沒有規矩不成方圓。創建的規範有如下幾種：
1、研發規範、自身穩定；
2、事務中不能包含遠程調用；
3、超時時間和重試次數要合理；
4、表數據操作必須double check，合理利用索引，避免出現慢查詢、分庫分表不走分表鍵；
5、沒有有效的資源隔離， 避免不同業務共用一個線程池或連接池；
6、合理的系統拓撲，禁止不合理的服務依賴，能去依賴就去依賴，否則同步依賴盡量改成異步弱依賴；
7、精簡的代碼邏輯；
8、核心路徑流程必須進行資源隔離，確保任何突發情況主流程不能受影響。
二、單服務穩定性
關鍵字：開關可控、單一職責、服務隔離、異常兜底、監控發現！
對於穩定性來說，拋開整體系統架構設計，單就每個業務域服務的穩定性也是非常的重要。
只有每個業務環節都穩如泰山，才可以保障整個穩定性。單服務的穩定可以從以下幾個方面來進行：
1、禁用設計：應該提供控制具體功能是否開啟可用的配置，在相應的功能服務出現故障時，快速下線局部功能，以保證整體服務的可用性；
2、必要的緩存：緩存是解決併發的利器，可以有效的提高系統的吞吐量。按照業務以及技術的緯度必要時可以增加多級緩存來保證其命中率；
3、接口無狀態性：服務接口應該是無狀態的，當前接口訪問不應該依賴上層接口的狀態邏輯；
4、接口單一職責性：對於核心功能的接口，不應該過多的耦合不屬於它的功能。如果一個接口做的事情太多應做拆分，保證單接口的穩定性和快速響應；
5、第三方服務隔離性：任何依賴於第三方的服務（不論接口還是中間件等），都應該做到熔斷和降級，不能有強耦合的依賴；
6、業務場景兜底方案：核心業務場景需要做到完整的兜底方法，從前端到後端都應該有兜底措施；
7、服務監控與及時響應：每個服務應該做好對應的監控工作，如有異常應及時響應，不應累積。
三、集群穩定性
關鍵字：系統架構、部署發布、限流熔斷、監控體系、壓測機制！
對於集群維度的穩定性來說，穩定性保障會更加複雜。單服務是局部，集群是全局。一個見微知著，一個高瞻遠矚。
1、合理的系統架構：合理的系統架構是穩定的基石；
2、小心的代碼邏輯：代碼時刻都要小心，多擔心一點這裡會不會有性能問題，那裡會不會出現併發，代碼就不會有多少問題；
3、優秀的集群部署：一台機器永遠會有性能瓶頸，優秀的集群部署，可以將一台機器的穩定放大無限倍，是高併發與大流量的保障；
4、科學的限流熔斷：高併發來臨時，科學的限流和熔斷是系統穩定的必要條件；
5、精細的監控體系：沒有監控體系，你永遠不會知道你的系統到底有多少隱藏的問題和坑，也很難知道瓶頸在哪裡；
6、強悍的壓測機制：壓測是高併發穩定性的試金石，能提前預知高併發來臨時，系統應該出現的模樣；
7、膽小的開發人員：永遠需要一群膽小的程序員，他們討厭bug，害怕error，不放過每一個波動，不信任所有的依賴。
四、穩定性專項
專項指的是針對某些特定場景下的特定問題而梳理出對應的方案。下面是針對一些常見的穩定性專項的概述：
1、預案：分為定時預案和緊急預案，定時預案是大促常規操作對於一系列開關的編排，緊急預案是應對突發情況的特殊處理，都依賴於事前梳理；
2、預熱：分為JIT代碼預熱和數據預熱，阿里內部有專門的一個產品負責這塊，通過存儲線上的常態化流量或者熱點流量進行回放來提前預熱，
起源於某年雙十一零點的毛刺問題，原因是訪問了數據庫的冷數據rt增高導致的一系列上層限流，現在預熱已經成了大促之前的一個必要流程。
3、強弱依賴:梳理強弱依賴是一個偏人肉的過程，但是非常重要，這是一個系統自查識別潛在風險點併為後續整理開關限流預案和根因分析的一個重要參考，
阿里內部有一個強弱依賴檢測的平台，通過對測試用例注入RPC調用的延遲或異常來觀察鏈路的依賴變化，自動梳理出強弱依賴關係。
4、限流降級熔斷:應對突發流量防止請求超出自身處理能力系統被擊垮的必要手段；
5、監控告警&鏈路追蹤:監控分為業務監控、系統監控和中間件監控和基礎監控，作為線上問題發現和排查工具，重要性不言而喻。
五、穩定性建設
穩定性建設，就和基礎技術建設一樣，是一個長期迭代和不斷調整的過程，業內常見的穩定性建設類型，主要有如下幾種：
1、容量規劃：個人感覺容量規劃在大廠里也並沒有做的很好，更多依賴的是業務方自己拍腦袋，然後全鏈路壓測期間驗證，不夠就再加機器。
2、混沌工程：混沌工程是近幾年比較火的名詞，通過不斷給系統找麻煩來驗證並完善系統能力，阿里在這塊花了很大的精力建設紅藍軍對抗攻防，進行定期和不定期的演練，
最後以打分的形式來給各個部門系統做排名，除了系統層面的故障演練外還有資金演練，篡改線上sql語句製造資損來測試業務監控糾錯的能力，通過製造小錯來避免大錯。
跳轉門：混沌工程-初識
3、流量調度：通過metric秒級監控和聚類算法實時找出異常單機來降低RPC流量權重，提升集群整體吞吐能力減少異常請求。
4、容災&異地多活：起源於15年某施工隊將光纖挖斷帶來的支付寶故障，由此出來的三地五中心和單元化架構，異地多活本身的成本比較高，
然後又存在數據同步的延時問題和切流帶來的臟數據問題，對於業務和技術都有比較高的要求。常見的容災有如下幾種：
1）緩存掛掉，集群重啟緩存預熱如何處理？本地緩存，多級緩存是否可以替代？
2）分佈式鎖，是否有開關一鍵切換？比如：ZK/ETCD編寫的分佈式鎖；
3）大促峰值流量，如何防止外部ddos攻擊？如何識別流量類型？
4）資源隔離：資源隔離，服務分組，流量隔離；
5）高可用思想：避免單點設計！
6）容錯：容錯上游，防禦下游。容錯主要需要注意如下幾點：
6-1：外部依賴的地方都要做熔斷，避免雪崩；
6-2：對於依賴我們的上游要限流，防止上游突發流量超過自己系統能夠扛住的最大QPS；
6-3：對於下游既要評估好接口超時時間，防止下游接口超時異常導致自己系統被拖累；
6-4：下游的接口要考慮各種異常情況，需要考慮中間狀態，通過引入柔性事務，確保數據最終一致。
5、異地多活
異地多活的本質，是數據中心架構的演進。
1）演進：單機房——雙機房——異地災備——異地多活；
2）定義：分多個地域、多個數據中心運行線上的業務，並且每個IDC均提供在線服務；
3）優點：彈性擴展能力、流量就近接入、靈活調度、提升可用性與用戶體驗、容災；
4）步驟：
4-1：基礎設施：機房之間專線互聯，保證網絡質量穩定；
4-2：持久存儲：一主三從，主IDC同步複製，異地IDC異步複製；
4-3：中間件：DB、MQ、分佈式存儲；
4-4：應用部署：根據應用域劃分，不同應用部署在不同地域，保持親緣性；
4-5：流量接入與調度：網絡協議兼容，DNS，動態調度用戶就近訪問；
4-6：監控與運維保障：專線實時監控，確保發生故障時可以觸發Failover（失效備援）和流量調度。
六、穩定性思考
關鍵字：階段工作、角色轉變！
穩定性建設是一個演進的階段性過程，主要分為三個階段：
1、發現問題解決問題：當問題較多時候就很被動，很多時候我們通過不斷完善監控來確保我們來快速定位問題，但仍處於被動的一方；
2、主動尋找問題：混沌工程、破壞性測試、極限壓測、紅藍對抗等手段，一方作為創造問題方不斷挑戰系統極限，另一方見招拆招快速修復。
3、角色轉變：這個過程中會積累很多處理問題的經驗，不斷完善系統健壯性，爭取在用戶發現問題前消滅於萌芽中。角色轉變，變被動為主動。
七、推薦閱讀
聊聊服務災備
大促穩定性建設
運維監控體系建設
這樣的高可用，我不要
高併發限流，到底限的什麼鬼
新浪微博平台穩定性體系介紹
StabilityGuide—穩定大於一切
沒有預熱，不叫高併發，叫併發高
信號量限流，高併發限流不得不說的秘密
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線
※Google地圖已可更新顯示潭子電動車充電站設置地點!!
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※別再煩惱如何寫文案,掌握八大原則!
※網頁設計最專業,超強功能平台可客製化
