聊聊我們是如何做技術保障的

2022 年 5 月 11 日
筆記

原創不易，求分享、求一鍵三連

資料地址：//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）

經驗沉澱

復盤本質就做兩件事情① 評價結果 ② 總結過程經驗教訓。具體來說：

復盤要緊密圍繞事情結果來討論。
事情結果的好壞，取決於是否達成預定目標。
因此，任何事在啟動前必須有明確可衡量的目標。
對於目標實現有貢獻的，稱之為經驗；對於目標實現有阻礙影響的，稱之為教訓。
經驗、教訓要能傳承並指導後續的行動。

引用：

//cloud.tencent.com/developer/article/1666384

//mp.weixin.qq.com/s/Rx_XuMLeor_M9EuQcYq23w

//zhuanlan.zhihu.com/p/61363959

//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

好了，今天的分享就到這，喜歡的同學可以四連支援：

想要更多交流可以加微信群：