原創不易，求分享、求一鍵三連
資料地址：https://files.cnblogs.com/files/yexiaochai/%E4%BF%9D%E9%9A%9C.zip?t=1652146053
面對業務迅速增長複雜度會呈幾何級增加，爲了降低維護複雜度而引入了微服務，只要每個服務足夠簡單，那麼維護成本也可以降低。
服務保障也是一個非常困難的事情，今天聊一聊系統穩定性方案。
方案設計層面
- 業務邏輯正常是最基礎的要求。
- 接口安全、數據安全（數據泄漏、數據遍歷、越權訪問）。
- 服務擴展性（服務是否可平滑擴容，能擴的最大範圍是多少個節點）、是否存在單點。
- 數據庫表結構設計、索引設計。
- 緩存更新機制、過期機制、是否存在單點熱Key
- 消息系統設計、流轉過程；投遞速率、消費速率
- 定時任務運行方式、執行記錄、失敗處理、是否可以恢復
僅僅考慮前面的場景可能還是不夠，所以繼續進行系統穩定性的思考。
系統穩定性
流量控制
一般情況下越靠近下層資源的吞吐能力越弱，數據庫吞吐能力有限，要儘量將流量攔截到上層儘快返回響應，讓越下層的資源做正確和重要的事情，達到壓榨系統的目的，所以上面看到的WAF攔截；限流基本都是放在網關或者離用戶更近的一層。
數據冗餘
系統中最重要的是數據，保證數據不丟失至關重要，數據冗餘是防止丟失最簡單的方式。數據冗餘備份方式很多種，從物理到邏輯的角度，備份可以分爲以下幾類：
- 物理冗餘
- 只對數據庫操作系統的物理文件（如數據文件、日誌文件等）的備份
- 物理備份又可以分爲冷備(在關閉數據庫時進行的備份操作，能夠較好地保證數據庫的完整性)和熱備(在數據庫運行狀態中進行操作，這種備份方法依賴於數據庫的日誌文件)
- 邏輯備份
從數據庫的備份策略角度來看，備份又可分爲全量備份、增量和冗餘備份
- 全量備份
- 每次對數據進行完整的備份
- 可以備份整個數據庫，包含用戶表、系統表、索引、視圖和存儲過程等所有數
- 據庫對象
但它需要花費更多的時間和空間，所以，做一次完全備份的週期要長些
- 增量冗餘
只有那些在上次完全備份或者增量備份後被修改的文件纔會被備份
- 差異冗餘
- 備份那些自從上次完全備份之後被修改過的文件，即只備份數據庫部分的內容
- 它比最初的完全備份小，因爲只包含自上次完全備份以來所改變的數據庫
- 它的優點是存儲和恢復速度快
高可用
爲了保證系統的高可用，在框架、基礎建設層面需要做很多建設。
- 超時、重試、冪等
超時控制，可以讓服務之間調用快速拋錯。
如果單個請求耗時長會影響服務的性能。比如API接口設置2s超時API調用a服務用了1s，服務a調用服務b用了1s，那麼現在已經超時了，如果還需要調用服務c，這個時候整體接口已經超時就不需要繼續調用c服務，浪費時間和資源。
重試是保證一些服務可能偶爾服務抖動失效情況下，再重新發起一次，保證當前請求的準確性，重試需要有限制，不能無限循環，再則操作是否可以重試，是有支持冪等。
- 擴容
擴容策略可以分爲兩種，一種是對單機整體擴容，也就是機器內部包含CPU、內存、存儲設備等;另一種增加機器，對於服務的擴容一定要慎重，需要考慮到擴容之後下游的資源是否能夠支撐。
比如mysql服務器鏈接只有2000個，當前集羣已經使用的差不多了，服務數量增加之後會導致鏈接不夠用；業務更容易出問題。微服務k8s容器化之後，我們自研的發佈系統上可以進行輕鬆的擴容。
- 限流、熔斷、降級
舉個業務降級的例子，定時送道具打積分榜單，榜單計算支持的QPS可能是1w，道具分多種檔次，其中有一種薅羊毛的道具1積分，花錢的幾十到幾萬積分不等，可能有刷子囤積了幾億的羊毛道具等待打榜時候使用程序投遞影響活動的體驗；
如果有大量羊毛道具並且超過榜單計算的QPS，此時就降級把羊毛道具剔除掉，只算花錢的，畢竟1積分對榜單影響小（業務定奪）。
- 隔離
顧名思義，按照一定的原則進行劃分，進行單獨維護。
服務隔離：將系統按照業務特性分成不同的服務模塊，各個模塊之間相對獨立，無強依賴，某些模塊出現故障不至於全部不可用。
動態接口和靜態接口隔離，比如：一個接口裏面有用戶自己特定的一些數據，也包含了所有用戶看到都是一樣的數據，那麼就可以把這部分拆分成兩個接口；大家看到統一數據的接口可以加統一緩存或者上CDN；不拆分是無法上CDN的；
數據庫分庫分表等；隔離之後儘量保證不可越界、不可共享防止隔離失效。
業務保障的基礎（監控&告警）
怎樣衡量業務系統是否表現正常？是應用在線上跑着進程還在沒有宕機，這可能是一個先決條件，有的程序雖然還在跑着，但是已經不能提供服務了，能體現服務的正常需要看流量，流量是看不見的，只有通過日誌監控體現。
監控需要監控哪些呢，基礎資源監控-基礎的資源是否出現問題了？
單服務監控-某個服務是不是指標是否出現異常了？
QPS（GRPC、http）、耗時、接口錯誤碼、錯誤率監控、上下游依賴監控(DB、緩存、上游依賴服務、下游支持服務)
微服務調用鏈路監控-調用鏈路到某個服務是否異常了？
用戶端監控-用戶體驗端是否出現異常了？
上線規範-預演
預演是非常重要的環節，很多bug都可以在預演環節被幹掉，這裏不是因爲測試同學不努力，不能把那些BUG過掉，是因爲：
- 預演環境有真實的龐大數據
- 預演環境的能還原真實的QPS，會覆蓋掉很多邊界場景
- 有些測試必須在生產環境進行
- 預演需要做方案，不能引起線上髒數據
有了這些東西就可以進行預演了，然後這裏有一個最大原則：預演請務必儘可能還原真實場景，包括時間點的設置！
那些之前重點關注的問題，很多重要的事情需要扣細節，扣的越多思考越細能考慮到整個事情的所擁有的發展方向，提前堵上錯誤的路徑。
- 廣播到端上刷接口
之前工作中遇到一個廣播的場景，是服務端會推送給web端一個命令消息，web收到消息之後需要向服務端發起一個http請求獲取數據，由於命令推送是同一個，根據不同的用戶獲取的http響應不一樣，並且http接口數量也比較大，前期用戶不多的情況下http接口的QPS比較低還能接收，逐漸業務增長後，http接口內部實現使用緩存能優化。
當服務端已經無法優化之後，簡單粗暴的，進行推送之後，web收到命令消息之後，0-5分鐘內打散請求服務端也能抗一段時間，量持續增長，到0-5分鐘即使打散量還是很大，給對應的http接口限流，用戶會反饋爲什麼我沒收到消息。
這種邏輯面對大量用戶在線確實比較難搞，後面將接口返回的數據進行拆分（動態和靜態）靜態數據加CDN並在界面上提前下發，動態數據壓縮走廣播，去掉廣播刷接口的邏輯。
- 無用請求搶佔帶寬
帶寬也是資源，之前遇到過一個事故，前端獲取一個接口數據如果沒有獲取成功，則會再進行api請求拉取一次，沒有做重試退出操作，導致這個接口的流量很大基本上打滿了某個服務的所有資源，進而急劇惡化其他請求都無法請求到後端服務。
之前處理的方式是在網關層面限制改接口的流量，部分正常的業務可以打到服務節點上，但是網關層量還是一直升高，最後將改接口直接掛到CDN上，不讓回源到服務，但當時CDN緩存的是404響應，事後想想直接把響應結果緩存到CDN，不是所有客戶端都正常了。
- 日誌打印不規範
無法及時發現線上問題，請不要亂打日誌，可能這個行爲是給別人埋坑，info日誌能看出業務在正常運行，error日誌能看出系統哪些業務出錯了。
緊急故障處理
線上故障總會出現的，我們出現故障如何緊急處理（參見：毛老師 SRE PPT）
經驗沉澱
覆盤本質就做兩件事情① 評價結果 ② 總結過程經驗教訓。具體來說：
- 覆盤要緊密圍繞事情結果來討論。
- 事情結果的好壞，取決於是否達成預定目標。
- 因此，任何事在啓動前必須有明確可衡量的目標。
- 對於目標實現有貢獻的，稱之爲經驗；對於目標實現有阻礙影響的，稱之爲教訓。
- 經驗、教訓要能傳承並指導後續的行動。
引用：
https://cloud.tencent.com/developer/article/1666384
https://mp.weixin.qq.com/s/Rx_XuMLeor_M9EuQcYq23w
https://zhuanlan.zhihu.com/p/61363959
https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81
好了，今天的分享就到這，喜歡的同學可以四連支持：
想要更多交流可以加微信羣：
