最近一直在忙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、角色轉變：這個過程中會積累很多處理問題的經驗，不斷完善系統健壯性，爭取在使用者發現問題前消滅於萌芽中。角色轉變，變被動為主動。
七、推薦閱讀