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