6月iOS設備性能榜：M2穩居榜首 A系列只能等一手3nm來救
沒有新品發布，自然iOS設備性能榜的上榜設備就沒有什么更替，僅僅只有跑分變化而產生的排名變動，畢竟蘋果新品的發布節奏就是這樣的，一年下來也就幾個移動端新品，不會像安卓廠商，一
游戲業務自 2017 年啟航，至今已近乎走過七個春秋，歷經漫長歲月的發展，不知不覺間背負起沉重的歷史包袱。猶如一棵大樹，既有繁茂精壯的枝椏，亦有諸多枯敗凋零的枝葉。此文主要聚焦于商品更新 MQ 消費這一細微模塊，詳述游戲業務如何對原有代碼予以重構，令游戲這棵大樹重煥蓬勃生機。
一日，驟然收到線上對下游接口 RPC 調用限流之警報，限流警報閾值為600k/min。遂著手排查觸發限流警報之因由。追根溯源，發覺乃外部存有更新操作，而更新接口調用閾值大約3K/min。明明更新流量不高，緣何觸發限流？于是開啟了對系統的調研與排查。
經過對限流原因的初步探索，我們進一步對商品消費 MQ 進行了全面梳理，發現游戲已有19個訂閱商品更新 MQ 的 Consumer，分布在不同集群。這些 Consumer 各自存有內部的查詢與更新相關操作，因其部分更新操作會催生新的 Message，致使接口調用進一步擴增。
調研還發現有的廢棄 Consumer 還在線上持續消費，有的相同的消費邏輯被多個 Consumer 在消費。
針對上面問題簡單梳理總結，問題如下：
圖片
a. 邏輯分散，可維護性差
b. 服務調用量成倍放大
c. 存在并發更新和覆蓋的情況
d. 存在廢棄或者重復消費情況
為什么會形成這樣的現狀？
作者認為：前期需求快速迭代，新增新的 Consumer 可迅速響應需求，且開發便捷。然而，伴隨需求的演變與迭代，新增的 Consumer 漸多，需求與人員的變更，使得系統全貌愈發難以全面掌控。不斷變更的邏輯，致使整個系統的維護愈發艱難，從而衍生出形形色色的問題。
若要降低 MQ 相關接口調用量，有兩個核心要點：其一，減少查詢，實現數據復用；其二，減少更新接口調用，抑制新的 Message 產生。但當下系統已然如此分散，于現有結構上極難獲取出色的解決方案。欲改變當前此種狀況，需要全新的結構，對原有 MQ 消費邏輯進行重構。借由新的結構，不但能夠化解當下的問題，還能夠構建新的約束，引導未來新的功能撰寫方式，使整個系統更為健康穩定。
在著手重構之前，最為關鍵的是明晰目標。目標能夠輔助我們擬定方案，明確范圍，指引項目落地而不偏離正軌。
a. 合理的結構
b. 優化重復無效消費邏輯
c. 提高消費能力
d. 邏輯優化
e. 構建新體系
期望通過合理的代碼架構，令消費商品 MQ 消息的邏輯高度內聚且低耦合、各個類及方法的職責清晰明確。重構并非對老系統的簡單復制，更肩負著為系統未來擴展定義新的約束規范。恰似于這棵游戲大樹中萌生出新的枝干與分支，決定著后續細枝的生長方向。
除了架構合理，還需優化解決此前的重復和無效消費的情況，提升整體消費能力，解決原先接口調用放大的問題。此外，在調研中發現系統存在一些已下線的廢棄邏輯和部分有問題的代碼，趁此次重構之機予以優化。（注：通常不建議在重構中修改邏輯，對于修改邏輯務必要進行充分測試，否則可能引入新的系統 Bug）
重構的總體方案主要由三部分構成：架構設計、實施計劃、測試計劃。
圖片
總體架構主要運用享元設計模式和策略設計模式，整個架構自上而下由三部分組成。
a. 數據預處理
b. 按分類調用Handler進行消費
c. 收攏調用更新接口
a：數據預處理主要負責過濾和預查詢數據。包含批量消費 MQ 消息，濾除非游戲的消息，調用批查詢接口，預處理后續可能重復處理的邏輯，減少重復查詢，提升接口效率。
b：主要是按分類抽取 Handler 和公共 Handler，以使職責清晰分明。抽取公共 Handler 以處理一些公共邏輯，例如記錄埋點日志等。各個分類的 Handler 僅處理本分類的業務邏輯，實現邏輯解耦，提升可維護性。為方便切面的使用以及增強相關功能的內聚性，在 Handler 之下額外抽取了一層 Manage 層。Manage 層主要負責實現具體的消費邏輯，并提供可復用組件，令邏輯更具內聚性。
c：對中臺商品相關的更新邏輯予以收攏，其主要目的在于減少更新接口的調用。（由于這些更新會產生新的 Message，故而通過調用批量接口的方式，來降低更新接口的調用次數，進而有效解決接口調用頻率放大的問題）
我們將整個重構劃分為以下三期來實現。
圖片
第一期和第二期
第一期：主要針對非核心業務 MQ 邏輯進行遷移重構。非核心業務灰度上線，控制影響范圍，迅速驗證架構的可行性與穩定性。
第二期：核心業務相關 MQ 遷移重構。灰度上線，關注對核心業務的影響。完成此步基本完成全部業務邏輯遷移。
第三期
第三期：對結構進行微調，主要是對相關功能進一步拆解、重構，使功能內部更為內聚，降低耦合，令整個系統最終達成設計之初的預期效果。
分多步進行重構的益處主要在于控制影響范圍，能夠迅速見到成效。每次改動范圍有限，更易于定位問題，也能夠極為便利地支持產品需求。
每次上線之前，核心主要通過三種測試，即白盒測試、黑盒測試、日志對比。
a：黑盒測試，校驗新老流程處理后的數據是否一致。
b：白盒測試。測試每一行代碼的覆蓋率，并觀察新老流程數據是否一致。
c：調用接口前數據對比。在調用更新接口之處打印日志，對比新老流程調用更新接口的傳參是否一致。
測試僅是一方面，上線后皆需關注整個系統的運行狀況，并做好關鍵方面的報警。此外，會同步一線客服人員，收集是否存在用戶反饋的問題，依照原來Consumer的顆粒度進行灰度。
此系統乃是一個與 MQ 消費相關的重構項目，在每個消費模塊皆需確保消費的冪等性，然而遷移而來的 Consumer 眾多，若在每個地方皆書寫一遍冪等相關處理，極為不便。我主要借助了 Spring 的 AOP 能力來達成。
圖片
主要是定義規范，定義冪等注解、統一返回值（泛型）以及撰寫注解處理類。通過環繞注解來實現，處理類在處理之前會進行規范檢測，不規范則直接放過（相當于使用注解失效），消費成功后我們會將返回結果通過緩存存儲起來，下次再來時，直接消費成功，無需重復處理，達成處理冪等性和減少重復消費的情況。冪等緩存的顆粒度為msgId。（灰度控制方案原理相同，此處不再贅述）
圖片
我們在設計下游商品更新時進行了收攏處理，以方便操作，但也帶來一個問題，即可能我們的業務信息已更新，而下游可能處理失敗，對此我們使用轉轉封裝的基于 RocketMQ 的消費重試組件來實現。（簡單來講，同步消費失敗，就會利用 RocketMQ，創建一個MQ消費信息來異步處理）。未更新成功的數據，通過 MQ 重試來保障消費成功。
更新失敗報警
我們還設有報警機制，未更新商品的信息，通過企業微信發送報警，以提示技術人員，并提供商品數據信息，方便在出現特殊異常情況時，人工兜底補足來處理此類情形。
新的Consumer在消費時提供了單獨的線程池處理，便于監控邏輯處理消費情況，提升整體邏輯處理能力的并發度。
線程池監控
建立豐富的監控指標和報警通知機制。通過日志查詢平臺、數據看板、異常企業微信報警通知，輔助我們在上線后實時觀察新流程的具體狀況，迅速定位問題。
MQ生成消費監控
上游查詢失敗報警
項目上線后，下游核心接口的調用量顯著降低，降幅 50%至80% 之間。其中，更新類接口的調用量降低了 80%，查詢類接口的調用量減少了 50%。
關于作者
許志芳，轉轉訂單業務后端研發工程師
本文鏈接：http://m.www897cc.com/showinfo-26-96749-0.html轉轉游戲MQ重構：思考與心得之旅
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 如何解決“Future不能安全地在線程之間發送”的問題？
下一篇： OpenAI宣布斷服，警惕血本無歸
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號