1 背景

游戲業(yè)務(wù)自 2017 年啟航，至今已近乎走過七個春秋，歷經(jīng)漫長歲月的發(fā)展，不知不覺間背負(fù)起沉重的歷史包袱。猶如一棵大樹，既有繁茂精壯的枝椏，亦有諸多枯敗凋零的枝葉。此文主要聚焦于商品更新 MQ 消費(fèi)這一細(xì)微模塊，詳述游戲業(yè)務(wù)如何對原有代碼予以重構(gòu)，令游戲這棵大樹重?zé)ㄅ畈鷻C(jī)。

1.1 起始之由

一日，驟然收到線上對下游接口 RPC 調(diào)用限流之警報，限流警報閾值為600k/min。遂著手排查觸發(fā)限流警報之因由。追根溯源，發(fā)覺乃外部存有更新操作，而更新接口調(diào)用閾值大約3K/min。明明更新流量不高，緣何觸發(fā)限流？于是開啟了對系統(tǒng)的調(diào)研與排查。

1.2 重構(gòu)前現(xiàn)狀

經(jīng)過對限流原因的初步探索，我們進(jìn)一步對商品消費(fèi) MQ 進(jìn)行了全面梳理，發(fā)現(xiàn)游戲已有19個訂閱商品更新 MQ 的 Consumer，分布在不同集群。這些 Consumer 各自存有內(nèi)部的查詢與更新相關(guān)操作，因其部分更新操作會催生新的 Message，致使接口調(diào)用進(jìn)一步擴(kuò)增。

調(diào)研還發(fā)現(xiàn)有的廢棄 Consumer 還在線上持續(xù)消費(fèi)，有的相同的消費(fèi)邏輯被多個 Consumer 在消費(fèi)。

針對上面問題簡單梳理總結(jié)，問題如下：

圖片

a. 邏輯分散，可維護(hù)性差

b. 服務(wù)調(diào)用量成倍放大

c. 存在并發(fā)更新和覆蓋的情況

d. 存在廢棄或者重復(fù)消費(fèi)情況

1.3 問題分析

為什么會形成這樣的現(xiàn)狀？

作者認(rèn)為：前期需求快速迭代，新增新的 Consumer 可迅速響應(yīng)需求，且開發(fā)便捷。然而，伴隨需求的演變與迭代，新增的 Consumer 漸多，需求與人員的變更，使得系統(tǒng)全貌愈發(fā)難以全面掌控。不斷變更的邏輯，致使整個系統(tǒng)的維護(hù)愈發(fā)艱難，從而衍生出形形色色的問題。

若要降低 MQ 相關(guān)接口調(diào)用量，有兩個核心要點(diǎn)：其一，減少查詢，實(shí)現(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 消費(fèi)邏輯進(jìn)行重構(gòu)。借由新的結(jié)構(gòu)，不但能夠化解當(dāng)下的問題，還能夠構(gòu)建新的約束，引導(dǎo)未來新的功能撰寫方式，使整個系統(tǒng)更為健康穩(wěn)定。

2 重構(gòu)

2.1 目標(biāo)

在著手重構(gòu)之前，最為關(guān)鍵的是明晰目標(biāo)。目標(biāo)能夠輔助我們擬定方案，明確范圍，指引項(xiàng)目落地而不偏離正軌。

a. 合理的結(jié)構(gòu)

b. 優(yōu)化重復(fù)無效消費(fèi)邏輯

c. 提高消費(fèi)能力

d. 邏輯優(yōu)化

e. 構(gòu)建新體系

期望通過合理的代碼架構(gòu)，令消費(fèi)商品 MQ 消息的邏輯高度內(nèi)聚且低耦合、各個類及方法的職責(zé)清晰明確。重構(gòu)并非對老系統(tǒng)的簡單復(fù)制，更肩負(fù)著為系統(tǒng)未來擴(kuò)展定義新的約束規(guī)范。恰似于這棵游戲大樹中萌生出新的枝干與分支，決定著后續(xù)細(xì)枝的生長方向。

除了架構(gòu)合理，還需優(yōu)化解決此前的重復(fù)和無效消費(fèi)的情況，提升整體消費(fèi)能力，解決原先接口調(diào)用放大的問題。此外，在調(diào)研中發(fā)現(xiàn)系統(tǒng)存在一些已下線的廢棄邏輯和部分有問題的代碼，趁此次重構(gòu)之機(jī)予以優(yōu)化。（注：通常不建議在重構(gòu)中修改邏輯，對于修改邏輯務(wù)必要進(jìn)行充分測試，否則可能引入新的系統(tǒng) Bug）

2.2 制定方案

重構(gòu)的總體方案主要由三部分構(gòu)成：架構(gòu)設(shè)計、實(shí)施計劃、測試計劃。

2.2.1 架構(gòu)設(shè)計

圖片

總體架構(gòu)主要運(yùn)用享元設(shè)計模式和策略設(shè)計模式，整個架構(gòu)自上而下由三部分組成。

a. 數(shù)據(jù)預(yù)處理

b. 按分類調(diào)用Handler進(jìn)行消費(fèi)

c. 收攏調(diào)用更新接口

a：數(shù)據(jù)預(yù)處理主要負(fù)責(zé)過濾和預(yù)查詢數(shù)據(jù)。包含批量消費(fèi) MQ 消息，濾除非游戲的消息，調(diào)用批查詢接口，預(yù)處理后續(xù)可能重復(fù)處理的邏輯，減少重復(fù)查詢，提升接口效率。

b：主要是按分類抽取 Handler 和公共 Handler，以使職責(zé)清晰分明。抽取公共 Handler 以處理一些公共邏輯，例如記錄埋點(diǎn)日志等。各個分類的 Handler 僅處理本分類的業(yè)務(wù)邏輯，實(shí)現(xiàn)邏輯解耦，提升可維護(hù)性。為方便切面的使用以及增強(qiáng)相關(guān)功能的內(nèi)聚性，在 Handler 之下額外抽取了一層 Manage 層。Manage 層主要負(fù)責(zé)實(shí)現(xiàn)具體的消費(fèi)邏輯，并提供可復(fù)用組件，令邏輯更具內(nèi)聚性。

c：對中臺商品相關(guān)的更新邏輯予以收攏，其主要目的在于減少更新接口的調(diào)用。（由于這些更新會產(chǎn)生新的 Message，故而通過調(diào)用批量接口的方式，來降低更新接口的調(diào)用次數(shù)，進(jìn)而有效解決接口調(diào)用頻率放大的問題）

2.2.2 實(shí)施計劃

我們將整個重構(gòu)劃分為以下三期來實(shí)現(xiàn)。

圖片

第一期和第二期

第一期：主要針對非核心業(yè)務(wù) MQ 邏輯進(jìn)行遷移重構(gòu)。非核心業(yè)務(wù)灰度上線，控制影響范圍，迅速驗(yàn)證架構(gòu)的可行性與穩(wěn)定性。

第二期：核心業(yè)務(wù)相關(guān) MQ 遷移重構(gòu)?；叶壬暇€，關(guān)注對核心業(yè)務(wù)的影響。完成此步基本完成全部業(yè)務(wù)邏輯遷移。

第三期

第三期：對結(jié)構(gòu)進(jìn)行微調(diào)，主要是對相關(guān)功能進(jìn)一步拆解、重構(gòu)，使功能內(nèi)部更為內(nèi)聚，降低耦合，令整個系統(tǒng)最終達(dá)成設(shè)計之初的預(yù)期效果。

分多步進(jìn)行重構(gòu)的益處主要在于控制影響范圍，能夠迅速見到成效。每次改動范圍有限，更易于定位問題，也能夠極為便利地支持產(chǎn)品需求。

2.2.3 測試計劃

每次上線之前，核心主要通過三種測試，即白盒測試、黑盒測試、日志對比。

a：黑盒測試，校驗(yàn)新老流程處理后的數(shù)據(jù)是否一致。

b：白盒測試。測試每一行代碼的覆蓋率，并觀察新老流程數(shù)據(jù)是否一致。

c：調(diào)用接口前數(shù)據(jù)對比。在調(diào)用更新接口之處打印日志，對比新老流程調(diào)用更新接口的傳參是否一致。

測試僅是一方面，上線后皆需關(guān)注整個系統(tǒng)的運(yùn)行狀況，并做好關(guān)鍵方面的報警。此外，會同步一線客服人員，收集是否存在用戶反饋的問題，依照原來Consumer的顆粒度進(jìn)行灰度。

2.3 部分細(xì)節(jié)設(shè)計

統(tǒng)一冪等灰度切面處理

此系統(tǒng)乃是一個與 MQ 消費(fèi)相關(guān)的重構(gòu)項(xiàng)目，在每個消費(fèi)模塊皆需確保消費(fèi)的冪等性，然而遷移而來的 Consumer 眾多，若在每個地方皆書寫一遍冪等相關(guān)處理，極為不便。我主要借助了 Spring 的 AOP 能力來達(dá)成。

圖片

主要是定義規(guī)范，定義冪等注解、統(tǒng)一返回值（泛型）以及撰寫注解處理類。通過環(huán)繞注解來實(shí)現(xiàn)，處理類在處理之前會進(jìn)行規(guī)范檢測，不規(guī)范則直接放過（相當(dāng)于使用注解失效），消費(fèi)成功后我們會將返回結(jié)果通過緩存存儲起來，下次再來時，直接消費(fèi)成功，無需重復(fù)處理，達(dá)成處理冪等性和減少重復(fù)消費(fèi)的情況。冪等緩存的顆粒度為msgId。（灰度控制方案原理相同，此處不再贅述）

異常失敗應(yīng)對

圖片

我們在設(shè)計下游商品更新時進(jìn)行了收攏處理，以方便操作，但也帶來一個問題，即可能我們的業(yè)務(wù)信息已更新，而下游可能處理失敗，對此我們使用轉(zhuǎn)轉(zhuǎn)封裝的基于 RocketMQ 的消費(fèi)重試組件來實(shí)現(xiàn)。（簡單來講，同步消費(fèi)失敗，就會利用 RocketMQ，創(chuàng)建一個MQ消費(fèi)信息來異步處理）。未更新成功的數(shù)據(jù)，通過 MQ 重試來保障消費(fèi)成功。

更新失敗報警

我們還設(shè)有報警機(jī)制，未更新商品的信息，通過企業(yè)微信發(fā)送報警，以提示技術(shù)人員，并提供商品數(shù)據(jù)信息，方便在出現(xiàn)特殊異常情況時，人工兜底補(bǔ)足來處理此類情形。

數(shù)據(jù)隔離

新的Consumer在消費(fèi)時提供了單獨(dú)的線程池處理，便于監(jiān)控邏輯處理消費(fèi)情況，提升整體邏輯處理能力的并發(fā)度。

線程池監(jiān)控

數(shù)據(jù)監(jiān)控

建立豐富的監(jiān)控指標(biāo)和報警通知機(jī)制。通過日志查詢平臺、數(shù)據(jù)看板、異常企業(yè)微信報警通知，輔助我們在上線后實(shí)時觀察新流程的具體狀況，迅速定位問題。

MQ生成消費(fèi)監(jiān)控

上游查詢失敗報警

3 總結(jié)

數(shù)據(jù)效果

項(xiàng)目上線后，下游核心接口的調(diào)用量顯著降低，降幅 50%至80% 之間。其中，更新類接口的調(diào)用量降低了 80%，查詢類接口的調(diào)用量減少了 50%。

思考與總結(jié)

1. 明確系統(tǒng)重構(gòu)的緣由，主要涵蓋兩方面。（現(xiàn)有系統(tǒng)存在問題需解決，或者現(xiàn)有系統(tǒng)限制了新的業(yè)務(wù)發(fā)展）
2. 務(wù)必要充分了解自身的系統(tǒng)。在重構(gòu)之前，對于具體的業(yè)務(wù)邏輯和影響范圍等信息需進(jìn)行直接評估與確定。唯有明晰系統(tǒng)的原貌，方能依據(jù)系統(tǒng)的現(xiàn)狀設(shè)計全新的技術(shù)方案。
3. 考慮未來發(fā)展，定義好的規(guī)范。好的規(guī)范和結(jié)構(gòu)，在未來系統(tǒng)迭代發(fā)展起一個引導(dǎo)作用。引導(dǎo)大家按相同的思路開發(fā)，更好的協(xié)作和支持業(yè)務(wù)需求。

關(guān)于作者

許志芳，轉(zhuǎn)轉(zhuǎn)訂單業(yè)務(wù)后端研發(fā)工程師