思考：如何保證服務穩定性？

最近一直在忙618大促的全鏈路壓測&穩定性保障相關工做，結果618還未開始，生產環境就出了幾回生產故障，且大多都是和系統穩定性、性能相關的bad case。

生產全鏈路壓測終於告一段落，抽出時間將我的收集的穩定性相關資料整理review了一遍，順帶從不一樣的維度，談談穩定性相關的「務虛」認知和思考。。。

 

1、SLA!

在開始談穩定性保障以前，咱們先來聊聊業內常常說起的一個Topic：SLA！

業內喜歡用SLA （服務等級協議，全稱：service level agreement）來衡量系統的穩定性，對互聯網公司來講就是網站服務可用性的一個保證。

9越多表明整年服務可用時間越長服務越可靠，停機時間越短。就以一個標準99.99%爲例，停機時間52.6分鐘，平均到每週也就是隻能有差很少1分鐘的停機時間，

也就是說網絡抖動這個時間可能就沒了。保證一個系統四個9或者更高的五個9，須要一套全體共識嚴格標準的規章制度，沒有規矩不成方圓。建立的規範有以下幾種：

一、研發規範、自身穩定；

二、事務中不能包含遠程調用；

三、超時時間和重試次數要合理；

四、表數據操做必須double check，合理利用索引，避免出現慢查詢、分庫分表不走分表鍵；

五、沒有有效的資源隔離， 避免不一樣業務共用一個線程池或鏈接池；

六、合理的系統拓撲，禁止不合理的服務依賴，能去依賴就去依賴，不然同步依賴儘可能改爲異步弱依賴；

七、精簡的代碼邏輯；

八、核心路徑流程必須進行資源隔離，確保任何突發狀況主流程不能受影響。

 

2、單服務穩定性

關鍵字：開關可控、單一職責、服務隔離、異常兜底、監控發現！

對於穩定性來講，拋開總體系統架構設計，單就每一個業務域服務的穩定性也是很是的重要。

只有每一個業務環節都穩如泰山，才能夠保障整個穩定性。單服務的穩定能夠從如下幾個方面來進行：

一、禁用設計：應該提供控制具體功能是否開啓可用的配置，在相應的功能服務出現故障時，快速下線局部功能，以保證總體服務的可用性；

二、必要的緩存：緩存是解決併發的利器，能夠有效的提升系統的吞吐量。按照業務以及技術的緯度必要時能夠增長多級緩存來保證其命中率；

三、接口無狀態性：服務接口應該是無狀態的，當前接口訪問不該該依賴上層接口的狀態邏輯；

四、接口單一職責性：對於核心功能的接口，不該該過多的耦合不屬於它的功能。若是一個接口作的事情太多應作拆分，保證單接口的穩定性和快速響應；

五、第三方服務隔離性：任何依賴於第三方的服務（不論接口仍是中間件等），都應該作到熔斷和降級，不能有強耦合的依賴；

六、業務場景兜底方案：核心業務場景須要作到完整的兜底方法，從前端到後端都應該有兜底措施；

七、服務監控與及時響應：每一個服務應該作好對應的監控工做，若有異常應及時響應，不該累積。

 

3、集羣穩定性

關鍵字：系統架構、部署發佈、限流熔斷、監控體系、壓測機制！

對於集羣維度的穩定性來講，穩定性保障會更加複雜。單服務是局部，集羣是全局。一個見微知著，一個高瞻遠矚。

一、合理的系統架構：合理的系統架構是穩定的基石；

二、當心的代碼邏輯：代碼時刻都要當心，多擔憂一點這裏會不會有性能問題，那裏會不會出現併發，代碼就不會有多少問題；

三、優秀的集羣部署：一臺機器永遠會有性能瓶頸，優秀的集羣部署，能夠將一臺機器的穩定放大無限倍，是高併發與大流量的保障；

四、科學的限流熔斷：高併發來臨時，科學的限流和熔斷是系統穩定的必要條件；

五、精細的監控體系：沒有監控體系，你永遠不會知道你的系統到底有多少隱藏的問題和坑，也很難知道瓶頸在哪裏；

六、強悍的壓測機制：壓測是高併發穩定性的試金石，能提早預知高併發來臨時，系統應該出現的模樣；

七、膽小的開發人員：永遠須要一羣膽小的程序員，他們討厭bug，懼怕error，不放過每個波動，不信任全部的依賴。

 

4、穩定性專項

專項指的是針對某些特定場景下的特定問題而梳理出對應的方案。下面是針對一些常見的穩定性專項的概述：

一、預案：分爲定時預案和緊急預案，定時預案是大促常規操做對於一系列開關的編排，緊急預案是應對突發狀況的特殊處理，都依賴於事前梳理；

二、預熱：分爲JIT代碼預熱和數據預熱，阿里內部有專門的一個產品負責這塊，經過存儲線上的常態化流量或者熱點流量進行回放來提早預熱，

　 起源於某年雙十一零點的毛刺問題，緣由是訪問了數據庫的冷數據rt增高致使的一系列上層限流，如今預熱已經成了大促以前的一個必要流程。

三、強弱依賴:梳理強弱依賴是一個偏人肉的過程，可是很是重要，這是一個系統自查識別潛在風險點併爲後續整理開關限流預案和根因分析的一個重要參考，

　 阿里內部有一個強弱依賴檢測的平臺，經過對測試用例注入RPC調用的延遲或異常來觀察鏈路的依賴變化，自動梳理出強弱依賴關係。

四、限流降級熔斷:應對突發流量防止請求超出自身處理能力系統被擊垮的必要手段；

五、監控告警&鏈路追蹤:監控分爲業務監控、系統監控和中間件監控和基礎監控，做爲線上問題發現和排查工具，重要性不言而喻。

 

5、穩定性建設

穩定性建設，就和基礎技術建設同樣，是一個長期迭代和不斷調整的過程，業內常見的穩定性建設類型，主要有以下幾種：

一、容量規劃：我的感受容量規劃在大廠裏也並無作的很好，更多依賴的是業務方本身拍腦殼，而後全鏈路壓測期間驗證，不夠就再加機器。

二、混沌工程：混沌工程是近幾年比較火的名詞，經過不斷給系統找麻煩來驗證並完善系統能力，阿里在這塊花了很大的精力建設紅藍軍對抗攻防，進行按期和不按期的演練，

　 最後以打分的形式來給各個部門系統作排名，除了系統層面的故障演練外還有資金演練，篡改線上sql語句製造資損來測試業務監控糾錯的能力，經過製造小錯來避免大錯。

　 跳轉門：混沌工程-初識

三、流量調度：經過metric秒級監控和聚類算法實時找出異常單機來下降RPC流量權重，提高集羣總體吞吐能力減小異常請求。

四、容災&異地多活：起源於15年某施工隊將光纖挖斷帶來的支付寶故障，由此出來的三地五中心和單元化架構，異地多活自己的成本比較高，

　 而後又存在數據同步的延時問題和切流帶來的髒數據問題，對於業務和技術都有比較高的要求。常見的容災有以下幾種：

　 1）緩存掛掉，集羣重啓緩存預熱如何處理？本地緩存，多級緩存是否能夠替代？

　 2）分佈式鎖，是否有開關一鍵切換？好比：ZK/ETCD編寫的分佈式鎖；

　 3）大促峯值流量，如何防止外部ddos攻擊？如何識別流量類型？

　 4）資源隔離：資源隔離，服務分組，流量隔離；

　 5）高可用思想：避免單點設計！

　 6）容錯：容錯上游，防護下游。容錯主要須要注意以下幾點：

　 　  6-1：外部依賴的地方都要作熔斷，避免雪崩；

　　   6-2：對於依賴咱們的上游要限流，防止上游突發流量超過本身系統可以扛住的最大QPS；

　　   6-3：對於下游既要評估好接口超時時間，防止下游接口超時異常致使本身系統被拖累；

　　   6-4：下游的接口要考慮各類異常狀況，須要考慮中間狀態，經過引入柔性事務，確保數據最終一致。

五、異地多活

異地多活的本質，是數據中心架構的演進。

1）演進：單機房——雙機房——異地災備——異地多活；

2）定義：分多個地域、多個數據中心運行線上的業務，而且每一個IDC均提供在線服務；

3）優勢：彈性擴展能力、流量就近接入、靈活調度、提高可用性與用戶體驗、容災；

4）步驟：

　 4-1：基礎設施：機房之間專線互聯，保證網絡質量穩定；

　 4-2：持久存儲：一主三從，主IDC同步複製，異地IDC異步複製；

　 4-3：中間件：DB、MQ、分佈式存儲；

　 4-4：應用部署：根據應用域劃分，不一樣應用部署在不一樣地域，保持親緣性；

　 4-5：流量接入與調度：網絡協議兼容，DNS，動態調度用戶就近訪問；

　 4-6：監控與運維保障：專線實時監控，確保發生故障時能夠觸發Failover（失效備援）和流量調度。

 

6、穩定性思考

關鍵字：階段工做、角色轉變！

穩定性建設是一個演進的階段性過程，主要分爲三個階段：

一、發現問題解決問題：當問題較多時候就很被動，不少時候咱們經過不斷完善監控來確保咱們來快速定位問題，但仍處於被動的一方；

二、主動尋找問題：混沌工程、破壞性測試、極限壓測、紅藍對抗等手段，一方做爲創造問題方不斷挑戰系統極限，另外一方見招拆招快速修復。

三、角色轉變：這個過程當中會積累不少處理問題的經驗，不斷完善系統健壯性，爭取在用戶發現問題前消滅於萌芽中。角色轉變，變被動爲主動。

 

7、推薦閱讀

聊聊服務災備

大促穩定性建設

運維監控體系建設

這樣的高可用，我不要

高併發限流，到底限的什麼鬼

新浪微博平臺穩定性體系介紹

StabilityGuide—穩定大於一切

沒有預熱，不叫高併發，叫併發高

信號量限流，高併發限流不得不說的祕密