本地生活服務平臺基於分佈式架構實踐

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

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...) 降級處理，保障用戶體驗。

作者：百度小程序團隊

來源：百度 Geek 說

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/DwpDnS3qpHMkTD8fCgjOFg