多利熊基於分散式架構實踐穩定性建設

　　多利熊穩定性建設，是指為了確保系統或服務，在生產環境中的穩定性而採取的一系列措施和最佳化。這包括但不限於監控、預警、容錯、自動化、規範、質量等方面的最佳化。透過穩定性建設，可以提高系統的可靠性和可用性，從而為使用者提供更好的使用體驗和服務質量。

　　 01 業務介紹

　　多利熊是百度旗下的本地生活服務平臺，是針對本地生活行業的SaaS解決方案，利用中心化+去中心化分銷渠道，幫助商家在百度內外廣泛獲客及持續經營，幫助使用者發現所在地的商戶，並給使用者提供特色又優惠的吃喝玩樂商品服務。

　　多利熊生活服務平臺，包含以下三個主要產品形態：

　　多利熊商家平臺：主要是面向商家提供服務，是商家管理門店、核銷訂單、處理售後、資金提現的經營平臺；包括PC後臺、小程式、APP雙端（多利熊掌櫃）

　　多利熊運營平臺：面向內部運轉，用於商戶稽核、商品稽核、套餐撰文等事務管理；包括PC後臺、APP雙端（熊管家）

　　多利熊使用者平臺：面向C端使用者和達人，提供多利熊百度小程式、多利熊微信小程式、多利熊APP等

　　多利熊業務挑戰，隨著技術角色分工越來越細、技術專業化程度越來越深，分散式系統的架構特性為其穩定性建設中的架構設計、組織設計等帶來了新的挑戰。

　　隨著模組微服務(使用者、商品、訂單、商家、券碼、支付...)數量激增，如何保障架構健壯可擴充。

　　依賴內部服務多，呼叫鏈路長，如何保障服務效能以及穩定性。

　　依賴外部服務多(交易、營銷、三方Saas...)，如何保證資料最終一致性。

　　迭代週期短，節奏快，如何平衡開發重構節奏，保障架構良性迭代。

　　 02 建設理念

　　多利熊業務複雜性，對產品整體的穩定性質量建設，帶來了巨大的挑戰，實際建設過程中主要從技術規範、業務規範、微服務三個方面落地實踐，具體如下：　　

　　多利熊穩定性建設，示意圖：　　

　　 03 實施過程

　　從開發到上線，如何保證穩定性？以多利熊業務穩定性建設落地實踐介紹，主要從以下幾個階段：方案設計、技術評審、開發、CR、提測、上線、問題處理、Case沉澱 實施落地，具體內容如下圖：　　

　　3.1 方案設計

　　方案設計旨在梳理需求背景，瞭解業務，確保需求合理性，可行性。方案設計帶來的好處：

　　梳理需求背景，瞭解業務，確定需要做的事情，確保需求合理性，可行性。

　　跨團隊、跨部門需求，需要達成一致性認知，對齊需求上下文。

　　詳設可以有效紕漏潛在的風險；評估開發工作量，保證專案進度。

　　沉澱開發文件，保證專案開發文件詳細準確，保證產品的專案開發文件的持續性，技術方案良構。

　　方案設計要包含內容如下：　　

　　方案版本：版本號、編寫時間、變更內容、修改人等資訊

　　開發文件：需求文件、需求 icafe(feature) 地址、prd地址、依賴文件地址、需求負責人，便於後續查詢

　　專案背景：對專案功能進列舉說明，專案背景梳理明白為什麼我們要做這個專案、要實現什麼功能

　　技術方案：技術架構、流程設計、模組互動、功能設計，需要將產品需求轉變為技術實現的過程表達清楚

　　介面設計：提供的介面命名、引數定義(型別 大小限制 長度限制 是否必填 備註...)、響應結果、介面資訊(描述資訊 建立人 負責人...)等協議資訊，解決前後端介面文件與實際情況不一致，隨著時間推移，版本迭代，介面文件往往很容易就跟不上程式碼了等問題

　　儲存設計：涉及庫表、欄位變更，必須考慮是否涉及上下游同步、資料相容、表情符號、欄位長度等

　　相容性：資料相容，新增欄位或者上線前後修改邏輯不一致等；介面相容，考慮介面升級，是否相容；上線順序相容，考慮前後端上線順序以及依賴關係，等其他需要考慮的相容場景

　　監控告警：執行失敗、異常場景監控告警。異常分支邏輯、執行時異常邏輯、關鍵路徑邏輯「支付、註冊等」

　　上線：上線前輸出上線文件，包括資源、配置、授權、上下游依賴、上線順序等等

　　3.2 技術評審

　　目的：技術文件沉澱以及技術文件持續性，同時保證技術方案良構。

　　目標：元件技術方案評審小組，輸出技術方案評審標準(方案設計、評審內容、方案回顧)。

　　技術評審主要職責：

　　指定評審內容，收集技術方案文件，指定參與評審人員(值班)，發起評審會邀

　　輸出准入規則，主要從競品調研、架構、介面協議、效能、庫表、核心流程可用性等方面，輸出准入規約

　　方案週期回顧，定期組織技術方案 Review(值班)，進行技術方案合理性分析回顧，保障架構良構

　　3.3 編碼現約

　　編碼規範願景是提效，保證程式碼質量，提升團隊的協作效率，降低溝通成本。開發規約主要包含，編碼規約、安全規約、Mysql規約、日誌規約、異常規約等。開發規約目標：

　　保證程式碼質量

　　開發提效

　　提升團隊的協作效率

　　降低溝通成本

　　提升線上服務穩定性

　　保障專案健康快速迭代

　　3.4 CodeReview

　　Code Review在保障程式碼質量准入重要一環，CR 的主要職責如下：

　　提前發現由於業務理解偏差、邏輯錯誤等帶來的質量隱患，從而減少線上問題和異常case

　　編碼風格的統一規範、設計的合理性、程式碼的健壯性等多方面

　　CR標準指導，從硬編碼、巢狀層級、日誌、常量、方法定義、SQL使用、配置檔案等方面對評審的標準進行了總結沉澱

　　基於多利熊業務，我們也逐步落實和完善了一套CR流程實踐，流程如下：

　　開發提交CR，開發自測完成之後發起，需經同模組內小組同學和負責人分別評審，評審人給出評審意見和打分。

　　集中式CR，涉及到多個模組聯動的，以需求為單位，在上線前發起，此環節是上線前質量把控很重要的一個環節，可以發現模組間由於理解偏差導致的依賴使用問題或邏輯問題。　　

　　3.5 操作上線

　　上線內容，需要周知模組負責人，透過上線方案評審，完成上線內容登記，上線通告後，進行上線操作。

　　上線視窗，對上線視窗沒有嚴格限制，週五原則上儘量不上線

　　上線前準備，完成上線方案設計並透過評審，涉及不相容、或者風險較高上線，周知 PM 確認是否需要發上線通告，上線通知模板如下：　　

　　預覽上線，先上線預覽環境，觀察服務是否符合預期

　　操作上線，保障無損上線，上線順序如下

　　單邊單臺，停留 10 分鐘，觀察服務是否符合預期（驗證改動功能符合預期），出現問題第一時間回滾，止損

　　單邊，全量

　　上線後，線上迴歸測試（對於線上沒有覆蓋到的迴歸場景，必須周知相應 PM&QA 同學，紕漏風險），完成監控告警新增以及確認，持續關注監控以及上線業務及資料是否符合預期

　　3.6 問題處理

　　問題處理原則：先通告，止損，再排查問題，線上問題優先跟進處理，最短時間上線修復。

　　問題上線原則：線上 bugfix 分支，不與業務上線混合上線，應獨立上線，避免回滾風險：

　　PM/QA/RD誰先發現問題，第一時間反饋，同時記錄 icafe 跟進

　　跟進原則，問題定位前：誰先報出問題，誰負責推動定位問題，問題定位後：相應問題負責人跟進

　　通告模板

　　【問題通報】問題描述

　　【問題描述】x年x月x日，因xx原因導致xx問題現象

　　【當前進展】xxx

　　【問題影響】待統計

　　【問題原因】待確定

　　 04 實戰

　　基於多利熊業務，我們也逐步落實和完善了一套穩定性建設流程實踐閉環。

　　4.1 穩定性閉環

　　穩定性建設各個環節互動如下：　　

　　4.2 最終一致性

　　多利熊業務內外部依賴服務較多，為了保障效能以及服務穩定性，最終採用方案如下：

　　非同步呼叫，保障服務效能，同時引入異常情況下，資料不一致問題

　　最終一致性，通用解決方案有 本地訊息表、外部訊息表、Seata等。多利熊選則了 本地訊息表方案，實現最終一致性，解決非同步呼叫資料不一致問題

　　多利熊業務業務呼叫，最終一致性實現流程如下：　　

　　4.3重試冪等

　　冪等介紹：多次呼叫不會改變業務狀態，多次呼叫獲得相同結果，對於請求的某一個資源應該具有同樣的副作用。

　　對於 Http 請求，會有三個狀態：成功，失敗，或者超時。成功、失敗是明確業務是很好處理的，超時是未知的，超時可能是網路傳輸丟包，也可能是請求超時，還有可能是返回結果超時。這時候我們是否可以重試呢？

　　冪等和防重

　　防重，主要為了避免產生重複資料或者髒資料，對返回沒有太多要求。主要有，前端重複點選，網路重試等等

　　冪等，比防重要求更加嚴苛，除了避免產生重複資料或者髒資料，還要求每次返回一樣的結果

　　常見冪等問題場景

　　前端重複提交，多次點選，服務端收到多次請求

　　超時重試，呼叫下游服務或者依賴外部服務處理超時，或者因為網路原因導致超時

　　訊息重複消費，使用訊息中介軟體 pulsar、mq 等，重複訊息傳送，或者 ack 異常重複消費

　　高併發，唯一 ID 生成碰撞，重複寫入，邊界控制等

　　多利熊業務冪等設計實現，設計冪等都需要一個 全域性唯一的ID，標記唯一的。通常使用 UUID 或者 雪花演算法生成全域性唯一 ID，多利熊採用的 防重表方式 實現冪等，流程如下：　　

　　4.4 監控警告

　　多利熊業務部署採用 k8s以及雲原生prome監控，本節主要介紹，多利熊涉及監控告警技術選型，以及監控告警處理流程實踐。

　　Trace 和 天眼（一站式日誌服務平臺）區別

　　天眼，應用於分散式服務的具有日誌採集、加工、儲存、檢索、告警等功能的一站式日誌服務平臺，為業務團隊提供低延遲, 高效能, 高可用的日誌服務, 提升業務排障效率與能力

　　Trace，基於日誌處理的全鏈路一站式查詢分析協議，特別對於鏈路較長業務，可以快速定位到那個業務出現了問題。

　　監控告警處理流程如圖：　　

　　多利熊業務監控選型，Trace，天眼，Actuator，Prometheus、Grafana，整體實現效果如下：

　　4.5 其他

　　業務成長，週期邀請產品、運營分享業務知識，以及產品交流，生活服務研發做到『快』、『懂業務』和『正影響』。

　　技術成長，架構師週期分享前言技術，技術培訓，定期分析討論架構，基礎服務研發做到『及時性』、『專業性』、『穩定性』和『安全性』。

　　 05 規劃

　　自動化縮容

　　基於個效能指標或者Prometheus自定義指標來進行擴縮容，滿足秒殺、大促等場景。

　　服務智慧化容錯

　　核心業務流程(下單、支付、核銷...)降級處理，依賴服務資源(Redis、MQ...)降級處理，保障使用者體驗。