本文是2016年11月肖飛在京東技術開放日分享的《服務降級背后的技術架構設計》PPT內容。

降級之術

數據

• 總共5000+預案
• 結算頁，依賴62個服務接口，31個有故障切換預案，45個降級預案
• 移動大促高峰時點前主動降級

數據來源京東預案管理系統，有重合。涉及類型：故障切換、資源調配、限流、降級。

示例

• 犧牲部分用戶體驗
• 商詳頁不顯示特色服務icon、促銷信息等
• 結算頁不顯示自提/311/411預約日歷
• 訂單詳情頁不顯示GIS訂單軌跡、催單等
• 評價列表禁止10頁之后的翻頁
• 實時統計和報表禁用
• 強制必選查詢條件中的路由或索引字段
• 領豆豆防刷降級為拼圖驗證
• H5變PC頁面
• 使用通用內容代替個性化推薦內容

降低安全級別

• 發放京豆、提交訂單、發表評論、登錄不調用風控接口
• 結算頁前端下單不啟用驗證碼
• 集中式session不可用，cookie解密即可
• ip limit服務，注冊、登錄不限制次數
• 商品修改內容不做敏感詞過濾

犧牲部分業務邏輯

• 拍賣出價時不校驗京豆數量
• 發表評價，不再校驗是否退貨

延緩任務處理

• WMS任務處理引擎，暫停調撥、節能補貼等任務
• OFW優先處理高優先級、拆分邏輯較簡單的訂單

損失數據持久性

• 用戶地址更新，寫redis，不回寫數據庫
• 庫存預占，寫redis，異步回寫數據庫
• 用戶新增普票，寫redis，不持久
• 訂單二次拆分任務機制，由JMQ降為redis隊列

降低準確性/實時性

• 實時價格過期不回源
• 動態頁變靜態拖底頁
• 用戶昵稱接口降級，顯示用戶pin
• 庫存狀態接口降級，顯示有貨
• 抽獎異常，所有用戶均顯示未中獎

降低性能

• 數據庫代替緩存防重、查詢
• 數據庫任務隊列輪詢代替MQ
• CDN降為源站
• 本地緩存降為RPC

降低容災能力

• 自動調度變為手工調度
• VIP降級為real ip

降級之架構設計

降級設計的基礎：服務化架構

• 解決系統的擴展性
• 故障隔離
• 服務拆分和治理

根據單一職責和故障隔離原則，確認業務和功能邊界

• 確認服務依賴關系
• 確認上下游SLA

案例：結算頁核心服務;上游：PC端結算頁Web、手機APP、微信入口等;下游：62個依賴服務接口。

上游依賴

上游依賴分析的目的：梳理上游系統等級;設計限流降級方案和開關。

針對上游的主要降級手段：限流降級;按照用戶質量，將高風險用戶、爬蟲優先降級;按照上游系統等級，將低級別系統的資源調度到高級別系統。

下游依賴

下游依賴分析的目的：–梳理依賴的影響程度和范圍;設計候選降級方案和開關。

結算頁強依賴：服務：購物車、商品、庫房屬性、庫存預占、四級地址、訂單號、接單;存儲：orderstore緩存;不可降級，要求下游拼死保護SLA。

結算頁弱依賴

實施

降級實施：人工 or 自適應;主動 or 被動。

時機：根據上游確認的SLA，超出調用量閾值的，觸發限流降級開關;根據下游確認的SLA，結合最近的可用率、資源使用率、耗時等統計、監控信息，切換到備選方案，或恢復到常規方案。

降級之道

降級：是利用有限資源，保障系統核心功能高可用、有損的架構方法。有限資源;核心高可用;有損;架構方法。

關鍵詞解讀：

有限資源(邊際效用遞減法則：單位資源投入對可用性的效用是不斷遞減的)。核心(功能/服務等級：核心高可用，級別越低，可用性要求越低)。有損(降級與故障切換的關系：降級是有損的故障切換)。架構方法(降級需要預先分析、設計，有實施方法論)。

降級預案設計原則

 

• 候選方案要簡潔，不要把系統復雜化
• 考慮降級的收益和影響成本，設計收益率最高的方案
• 降級預案需要定期review：業務復雜度變更;系統重要級別提升
• 簡潔原則;經濟原則;動態原則

作者：肖飛，于2011年8月份加入京東，曾親身參與到京東的應用性能監控、統一日志、流式計算、內存緩存、四層防攻擊等一些基礎技術平臺的研發和搭建工作，經歷了京東的技術系統從簡單粗放向復雜精細化的演變過程。目前主要工作為多中心交易項目中的數據復制中間件JingoBUS的研發。平時也會開發一些公共的平臺和工具，關注分布式系統的實現、程序設計、性能優化、開發語言等。

 【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】