本文從零開始介紹了游戲推薦項目的發展歷程，闡述了大型項目建設中遇到的業務與架構問題以及開發工程師們的解決方案，描繪了游戲推薦項目的特點以及業務發展方向，有著較好的參考與借鑒意義。

一、游戲推薦的背景與意義

從信息獲取的角度來看，搜索和推薦是用戶獲取信息的兩種主要手段，也是有效幫助產品變現的兩種方式，搜索是一個非常主動的行為，并且用戶的需求十分明確，在搜索引擎提供的結果里，用戶也能通過瀏覽和點擊來明確的判斷是否滿足了用戶需求。

然而，推薦系統接受信息是被動的，需求也都是模糊而不明確的。推薦系統的作用就是建立更加有效率的連接，更有效率地連接用戶與內容和服務，節約大量的時間和成本。以此背景，游戲推薦系統由此誕生。

游戲推薦系統從設計之初就作為游戲分發的平臺，向公司內所有主要流量入口（游戲中心、應用商店、瀏覽器、jovi等）分發游戲，系統通過各種推薦算法及推薦策略，為用戶推薦下載付費意愿較高且兼顧商業價值的游戲，從而為公司帶來收入。發展至今天，該系統還具備類游戲內容與素材的推薦功能。

二、游戲推薦的初期模型

游戲推薦的目的是推出用戶想要且兼顧商業價值的游戲，以此來提高業務的收入指標。此處的商業價值是由運營側通過策略規則去把控的，而用戶意向游戲則是通過算法排序得到的，算法排序所需要的特征數據，以及推薦效果的反饋數據則由埋點信息上報以供計算分析。

因此我們的模型可以分成四大塊：

運營推薦規則配置

算法模型訓練

推薦策略生效

數據埋點上報

模塊間的交互如下：在策略生效前，運營會先在配置中心生成對應的配置規則，這些規則會以緩存的形式存儲以供推薦高并接口調用。當用戶訪問app應用某些特定頁面時，其后臺會帶著對應的場景信息來請求游戲推薦后臺，推薦后臺根據場景信息映射相關配置（召回，標簽，過期，算法等..........）調用算法服務并進行資源排序，最終將推薦的結果反饋給app應用。

app應用在展示推薦頁面的同時，也將用戶相應的行為數據以及推薦數據的相關埋點進行上報。

三、業務增長與架構演進

隨著接入系統帶來的正向收益的提升，越來越多的業務選擇接入游戲推薦系統，這使得我們支持的功能日益豐富。

目前游戲推薦覆蓋的場景有分類、專題、榜單、首頁、搜索等；包含的策略類型有干預、打散、資源配比、保量；支持的推薦類型更是豐富：聯運游戲、小游戲、內容素材、推薦理由。

這些豐富的使用場景使得業務的復雜度成本增長，令我們在性能，擴展性，可用性上面臨著新的挑戰，也推動著我們架構變革。

3.1 熵增環境下的通用組合策略

在0 到 1 的過程中，游戲推薦聚焦于提高分發量，這時候考慮得更多的是怎么把游戲推出去，在代碼實現上使用分層架構來劃分執行的業務。

但是在1 到 2 的過程中， 我們游戲推薦不僅僅推薦游戲，也推薦內容和素材；同時在策略調用上也更加靈活，不同場景其調用的策略是不同的，執行順序也是不同的；更重要的是加入了很多用戶個性化業務與動態規則，這些都使得現有業務代碼急劇膨脹，擴展起來捉襟見肘，無從下手。因此我們急需一個高復用，易擴展，低代碼的策略框架去解決這些問題。

如圖所示，通用組合策略負責流轉的角色有兩個acceptor和executor，通訊媒介是推薦上下文context。負責執行邏輯的角色有三個matcher，listener和process，它們都有多個不同邏輯的實現類。當請求游戲推薦系統時，acceptor會先從配置中動態查詢策略模板進行匹配，接著listener組件會執行相應的預處理邏輯。處理后acceptor通過上下文context將任務流轉給executor處理器。executor再根據配置，將process根據前置條件進行篩選并排列組合，最后埋點返回。

經過這套通用的策略，我們在實現一般業務的時候，只要擴展具體matcher和process，并在配置中心將場景和處理優先級綁定起來，就能完成大部分的場景開發，這樣研發者可以更聚焦于某個邏輯流程的開發，而不用疲于梳理代碼，并進行擴展設計。

3.2 多級緩存與近實時策略

游戲推薦系統服務于手機游戲用戶，處于整個系統鏈路的下游，峰值流量在3W TPS左右 ，是個讀遠多于寫的系統。“讀”流量來自于用戶在各種推薦場景，列表、搜索、下載錢下載后、榜單等，寫數據主要來源于運營相關策略的變更，所以我們面臨的一個重大挑戰就是如何在保證可用性的前提下應對高頻的讀請求。

為了保證系統的讀性能，我們采用了redis + 本地緩存的設計。配置更新后先寫mysql，寫成功后再寫redis。本地緩存定時失效，使用懶加載的方式從redis中讀取相關數據。這種設計能保證最終一致性，軟狀態時服務集群數據存在短暫不一致的情況，早期對業務影響不大，可以認為是一個逐步放量的過程。

早期原先部署節點較少，整個系統達到最終一致性的時間較短，但隨著節點增加到數百臺，這個時間就變得不是那么和諧了。

同時隨著業務復雜度的增加，常常是多個配置策略決定這一個推薦結果，此時本地緩存的狀態極大影響了測試和點檢的便利，如果配置更改不能做到立馬更新本地緩存，那就要等待漫長的一段時間才能開始驗證邏輯。因此，我們對緩存結構做出了如下的調整：

與先前不同的是，我們加入消息隊列并通過配置版本號的比對來實現策略的實時更新同步，取得了很好的效果。

3.3 高并服務的垃圾回收處理

任何一個java服務都逃離不了FGC的魔咒，高并服務更是如此。很多服務每天兩位數的FGC更是家常便飯，顯然這對業務的穩定性和服務性能影響是巨大的。游戲推薦這邊通過不斷實踐總結了一套較為通用的方法很好地解決了這個問題：

可以看到起初jvm配置較為常規：1G的年輕代，2G的老年代以及一些其他常見的多線程回收的配置，其結果就是每天10次的FGC，YGC單次耗時在100ms，FGC耗時在350 - 400ms。我們知道線上接口容忍的范圍一般是200ms以內，不超過300ms，這樣顯然是不達標的。

通過分析，我們發現高并服務的高頻FGC來源于這幾個方面：

大量的本地緩存（堆內）占據了老年代的空間，大大增加了老年代疊滿的頻率。

高并請求導致了對象的急速生成，年輕代空間不足以容納這劇增的對象，導致其未達到存活閾值（15次）就晉升至老年代。

引入的監控組件為了性能，常常延遲 1 - 2 min再將數據上報服務端，導致這部分數據也無法在年輕代被回收。

當然這還不是問題的全部，FGC還有個致命問題就是stop the world，這會導致業務長時間無法響應，造成經濟損失。反過來，就算FGC頻繁，stop the world 只有1ms，也是不會對業務造成影響的，因此不能單單以FGC的頻率來判斷jvm服務的gc性能的好壞。經過上面的探討，我們在實踐中得到了如下的解決方案：

不常變化的緩存（小時級別）移到堆外，以此減少老年代疊滿的基礎閾值。

變化不那么頻繁的緩存（分鐘級別）更新的時候進行值對比，如果值一樣則不更新，以此減少老年代的堆積。

使用G1回收器：-XX:+UseG1GC

-XX:MaxGCPauseMillis=200

-XX:InitiatingHeapOccupancyPercent=25

-XX:MaxNewSize=3072M -Xms4608M -Xmx4608M -XX:MetaspaceSize=512M

-XX:MaxMetaspaceSize=512M

其效果如上所示，調整后各項指標都有很大的進步：由于年輕代中的復制算法使其垃圾清理速度較快，所以調大其容量使對象盡量在其中回收，同時設置每次清理的時間，使得mix gc控制在200ms以內。

3.4 限流降級與兜底策略

為了保證業務的可用性，大部分業務都會引入hystrix, sentinel, resilience4j 這類熔斷限流組件， 但這些組件也不能解決全部的問題。

對于游戲推薦來說，一臺節點往往承載著不同的業務推薦，有些業務十分核心，有些不是那么重要，限流降級的時候不是簡單的哪個服務限流多少問題，而是在權衡利弊的情況下，將有限的資源向哪些業務傾斜的問題，對此我們在分層限流上下足了功夫。

同時對于個性化業務來說，僅僅返回通用的兜底會使推薦同質化，因此我們的策略是將用戶的歷史數據存儲下來，并在下次兜底的時候作為推薦列表進行返回。

四、精細化運營模式的探索

在經歷過了0 到1 的開疆拓土 與 1 到 2 的高速增長后，游戲的推薦架構已經趨于穩定。這時候我們更加關注效能的提高與成本的下降，因此我們開始著手于系統運營的精細化設計，這對推薦系統的良性發展是意義重大的。

精細化運營不僅能提高尾量游戲的收入，提高運營人員的工作效率，還能實時快速反饋算法在線效果并立馬做出調整，做到一個業務上的閉環。首先就不得不提到游戲推薦系統的分層正交實驗平臺，這是我們做精細化運營的基礎。

4.1 多層 hash 正交實驗平臺

游戲推薦的關鍵就一個"準"字，這就需要通過精細化策略迭代來提升效率和準確度，從而不斷擴大規模優勢，實現正向循環。然而策略的改變并不是通過“頭腦風暴”空想的，而是一種建立在數據反饋上的機制，以帶來預期內的正向變化。這就需要我們分隔對照組來做A/Btest。

一般線上業務常見的A/B test是通過物理方式對流量進行隔離，這種方法常見于H5頁面的分流實驗，但面對復雜業務時卻存在著部署較慢，埋點解析困難等問題，其典型的架構方式如下：

對于游戲推薦來說，其完成一次推薦請求的流程比較復雜，涉及到多組策略，為了保證線上流量的效率與互斥，就不能采用簡單的物理分配流量的方式。

因此在業務層我們建立了一套多層hash正交實驗規則來滿足我們A/B test的要求。

與物理隔離流量，部署多套環境的方式不同，分層模型在分流算法中引入層級編號因子（A）來解決流量饑餓和流量正交問題。每一實驗層可以劃分為多個實驗田，當流量經過每一層實驗時，會先經過Function(Hash(A)) 來計算其分配的實驗田，這樣就能保證層與層之間的流量隨機且相互獨立。其流量走勢如下圖所示，

以上就是推薦業務和一般業務實驗流量隔離的不同之處，在實驗設計上我們又將一個完整的實驗周期分為以下幾個階段。在預備階段需要跟根據業務指標的需求，提出實驗假設，劃分好基線和實驗田的流量比例，并上線配置（放量）。

在實驗階段，線上流量進入后，服務會根據流量號段的匹配響應的策略進行執行，并將實驗數據上報。放量一段時候后，我們會根據上報的埋點數據進行數據分析，以確定此次策略的好壞。

和實驗階段劃分相對應地，我們將實驗平臺劃分為實驗配置，埋點上報和實驗結果分析三個模塊，在實驗配置模塊，我們根據實驗需求來完成分流配置和業務場景的映射關系。

并在hash實驗管理中將業務層級劃分，以便流量的流通。

在埋點上報模塊中，我們通過sdk的方式植入業務代碼中，當流量進入該實驗田時就會進行分析和埋點上報，我們將上報的埋點分為游戲和請求維度，節省上報流量的同時以滿足不同的分析需求：

游戲維度： { "code": 0, "data": [ { "score": 0.016114970572330977, "data": { "gameId": 53154, "appId": 1364982, "recommendReason": null, }, "gameps": "埋點信息", } ], "reqId": "20200810174423TBSIowaU52fjwjjz" } 請求維度： { "reqId":"20200810142134No5UkCibMdAvopoh", "scene": "appstore.idx", "imei": "869868031396914", "experimentInfo": [ { "experimentId": "RECOMMENDATION_SCENE", "salt":"RECOMMENDATION_SCENE", "imei": "3995823625", "sinfo": "策略信息" }, { "experimentId": "AUTO_RECOMMENDATION_REASON", "salt":"RECOMMENDATION_SCENE", "imei": "1140225751", "sid": "3，4，5" } ] }

在實驗結果分析模塊中，我們將采集的埋點的數據上報只大數據側，并由其進行分析計算，其結果指導這我們對實驗策略進行進一步的分析迭代。對于游戲請求的上報格式，我們可以直接通過appId和gameps的信息直接分析得出該類游戲的推薦結果和用戶行為的關系。同時加入請求維度的分析（包含策略信息），可以直接分析出決策對各項指標的影響。

4.2 召回優化之多路召回

召回在游戲推薦業務中就是利用一定的規則去圈選一批游戲，這是為了將海量的候選集快速縮小為幾百到幾千的規模。而召回之后的排序則是對縮小后的候選集進行精準排序，最終達到精準推薦的目的。

然而這種單路的召回在業務上卻有著很大的缺陷：

通常為了保證計算效率，圈選的數量在幾百個左右，由于數量限制其無法完全覆蓋完整的目標用戶候選集。

隨著業務的復雜度變高，召回策略的種類也開始膨脹，其召回規則是剝離的無法統一，這也意味著在某些業務場景下，在種類上無法覆蓋完全。

因此，權衡了計算效率和業務覆蓋度（召回率）的問題，我們逐步上線了多路召回功能。

在業務實現上，多路召回兼容了原有的個性化召回、算法召回、游戲池召回、分類/標簽/專題/同開發者)召回等召回路徑，通過圈選多個游戲池做為召回策略，經過合并、過濾、補量、截斷等策略最終篩選出一批進行算法預估打分的游戲。

本質上，多路召回利用各簡單策略保證候選集的快速召回，從不同角度設計的策略保證召回率接近理想狀態。

4.3 曝光干預之動態調參

一個推薦系統的效能如何，除了運營策略之外很大程度上取決于推薦算法的結果，而推薦算法的結果又是以曝光量，下載量，ctr等作為評價指標的。所以在游戲推薦業務的生命周期中，推薦算法一直致力于優化這些指標。

但是在開發中有個實際問題就是，從算法結果的數據反饋，到代碼改進上線這個時間周期較長，對一些需要快速響應的業務場景來說是不符合要求的。因此我們需要一套規則來對線上的算法結果做動態調整，以滿足業務的要求，這就是動態調參。

目前游戲業務的營收中，曝光量是個極其重要的指標，而大盤在一段時間內的曝光量是確定的，太多或太少都會嚴重影響業務，由此推薦算法就會根據線上實時反饋的一些數據對游戲的曝光進行調整。

經過設計, 我們先將調參游戲劃分為多個等級，并將游戲的生命周期劃分為幾個時間段，同時在每個時間段內以游戲曝光量，評級，數量等因素作為計算因子來計算曝光的分配權重。

接著系統根據實時采集的游戲曝光信息及所計算的游戲目標曝光對實際曝光進行調整，最終實現游戲曝光的動態調控。

對于正向調控來說，動態調參就是最有效的扶持機制，增加了游戲曝光的同時提升了導流能力。對于負向調控，動態調參能對品質和要求不達標的游戲，通過減少曝光的方式進行打壓，提升用戶體驗。

五、展望之智能化建設

經過多年的探索實踐，游戲推薦系統成就了一套完整的推薦體系。

在架構上的演進使得我們能更好地應對復雜多變的業務需求，在精細化運營上的探索與建設令我們能更加敏銳地把握住市場的變化以做出響應，這些建設也很好地反饋的反饋到了業務結果中，提升了眾多效能和收益指標，得到了業務方的一致好評。

但當分發效率和收入效益問題解決了之后，我們在思考自己還能做什么，原先游戲推薦做的比較多的是接入服務，在單鏈路上去做閉環提高效益，但這是遠遠不夠的。

在未來我們會考慮如何打造覆蓋搜廣推+ 智能運營的全棧業務支撐系統（智能禮券，智能push，用戶反饋智能處理系統），以提升平臺和渠道的價值。

審核編輯 ：李倩