騰訊遊戲實時計算應用平臺建設實踐

導讀： 本文由騰訊遊戲增值服務部數據中心許振文分享，主要介紹騰訊遊戲實時計算應用平臺的建設實踐。

內容包括：

• 建設背景

• 統一實時大數據開發 OneData

• 統一大數據接口服務 OneFun

• 數據服務微服務化 & ServiceMesh 管理

遊戲是一個即時刺激反饋的項目，離線數據運營的痛點包括：延遲大，體驗差，反饋慢。而通過實時數據運營，可以提高用戶體驗，增加遊戲收入，解決離線指標運營痛點，運營幹預越及時，效果越好。

下圖是基於我們數據應用平臺衍生出來的一個數據服務任務系統。很多時候有一個比較好的任務引擎去驅動一件事情，事情的結果會向一個比較好的方向去發展。比如遊戲內的任務系統，玩家有任務可以領取，有獎勵和反饋，這是遊戲中很熟悉的場景。

另外一個是排行榜，也是一種刺激性的措施，是對大家努力、潛力或者是能力的一種認可。這種場景非常常見，在遊戲裏面我們用的也非常多。這是一個典型的遊戲的運營場景，當然這個背後缺離不了數據，尤其缺離不了實時數據。

以下是我們數據平臺演化的過程。

最開始是手工作坊式開發，我們在接到遊戲的數據營銷活動開發時，去分析需求、數據接入、邏輯編碼開發、資源申請、發佈驗證交付，接口開發測試，線上監控，資源回收。這種開發過程門檻高，成本高，效率低，而且數據複用性差，易出錯，不易沉澱系統。所以一定要往平臺方向去走。

但同時也需要具備一定的前提，首先是數據的標準化和數據字典統一。我們在 10 年到 15 年基本上完成了遊戲數據標準化的過程，包括標準化的接入和標準化的字段映射。在此之上，我們有統一的遊戲數據服務，包括數據計算和接口服務。我今天講的主要就是這一部分，然後在上面能夠去支撐各種各樣的業務。所以我們的最終目標也是能夠建立一個一站式的開發環境，開發者只關注如何實現邏輯即可，其餘聯調、運維發佈、線上運營保障都由平臺提供配置化解決方案。

 我們的開發思路主要有三點。

• 第一點是規範化。流程規範，數據開發規範和開發框架。

• 第二點是自動化，包括資源分配，發佈上線，監控部署。

• 第三點是一體化。從數據開發到數據接口開發，到測試發佈和運維監控，要一站式完成。

所以我們抽象出來兩個核心的服務，一個是數據服務，一個是統一的接口服務開發。因爲在我的思考當中，大家做數據給誰去用，用什麼樣的方式提供數據給大家用，我認爲最好的方式是 API 的方式，所有的實時數據能夠以 API 的方式提供出去，在數據應用的主動、被動場景之下都可以覆蓋到。另外，在這兩種場景下必須有一個流程系統來協調它。

以上是主要的思路，爲各種數據應用場景提供一站式的數據開發和應用解決服務，統一活動管理、數據指標計算開發管理和各種數據應用接口自動化生產管理的一站式服務。

02

首先來看一下游戲數據的鏈路。數據產生之後，我們會有一個 data server，然後會把數據傳輸到消息隊列，消息隊列現在主要是 Kafka，Pulsar 也在逐步跟上。再到計算層，然後在儲存部分去做一個隔離。再到數據 API 這一層，計算的數據能夠直接對外產生場景化的應用。這應該也是大家很多場景當中會想到的一種思路。但是我們把整個過程都能串起來，在一個站點裏面就能完成完成，不需要在多個站點裏面跳來跳去，會大大降低技術棧的門檻。

首先是大數據這一塊。原來用 C++, Java 去消費 Kafka 消息隊列，但是現在比較少了。我們現在從編譯測試到提交發布的過程要做到三點，

• 第一個是指標配置 SQL 化。因爲 SQL 化對很多產品人員來說門檻是比較低的，但是我們比 SQL 化還要更低，即圖形化的 SQL。大家只要選哪張表，哪些字段，計算條件，聚合維度是什麼就可以了。明確告訴你要填的就是這些字段，從這張表裏面選出來就可以。這張表其實就是我們剛纔說的接進來的 Kafka 表，所以我們這塊就做了兩個方面，一方面是支持基本的 SQL，另一方面大家都不需要懂 SQL，你只需要懂這張表，怎麼去設計算法就可以了。

• 第二個是在線 WebIDE。udf 這一塊其實是很麻煩的，完全開放是不受控的。我們到目前爲止積累的 udf 函數不到 100 個。如果這 100 個函數官方提供，就不需要去做了。所以我們提供在線 WebIDE 的方式。

• 第三個就是數據場景化配置，後面詳細介紹。

剛纔說了兩個 SQL，一個是 Flink SQL，我們要原生支持。另外一種就是自研 SQL，它可以圖形化的配置，拖拉拽就可以配置出來，填表單就可以配置出來。除此之外，我們還提供在線函數的 Jar 包的方式，在這裏面我們要做 SQL 的解析和代碼的生成，另外還要做到 JIT 和隔離性，還有日誌的統一上報告警。

我們的一個思路是數據計算必須要服務於場景，必須要能夠在某些地方輸出。所以我們在有了核心引擎層之後，上面是產品化服務層。比如說實時統計分析服務，用戶選擇這幾張表和字段，平臺給出統計結果。另外一個就是實時指標計算服務，就是很多特徵值的計算。還有通用規則觸發服務，比如說用戶一登錄，我們立馬就要判斷彈窗內容是什麼，給他送禮包、還是給他推薦一個活動或者任務。再往上是應用系統層，包括任務系統，用戶實時干預系統，等等。

以對下游的 qps 的控制爲例，比如下游只能承受 500qps，但是當活動時用戶量達到 1000 人，是否仍能按照 500qps 的調用速度，剩下的慢慢調，但保證服務正常運行等，這種場景也需要有一些通用的干預的用戶關懷類的服務。

下面介紹一下我們自研的 SQL。我們當前用 SQL 解析的方式去做代碼的生成，最終生成一串代碼，而不是執行一個語法樹，因爲執行語法樹的成本太高。所以我們通過 SQL 解析進行這樣的一些判斷。如下圖所示，最下面就是判斷結果。最終生成了如下一串代碼。

這是一個執行過程，自研 SQL 和 Flink SQL 之間的一個對比。

• FlinkSql 適合的場景：狀態值不能太大，最好不要超過 1G。ETL、數據轉發等非常適合。

• 自研 Sql 適合的場景：狀態值非常大，超過 10G，甚至 100G，借用三方存儲進行狀態存儲。

舉個例子，某個用戶最近幾天的行爲表現，如累計殺人數、對局數等，用戶數量上億。我們的遊戲業務場景需要支持大維度和長累加計算，無論多大的數據量，只要存儲介質能夠承受得住，採用自研 SQL 都沒問題。

 這裏提到一個問題，包括兩點：

• 配置的同表 SQL 重複消費數據。 

• 相同緯度的數據指標每個保存一份浪費存儲。我們整個平臺有 13,000 多個指標，如果每個指標都要起任務的話，13,000 多個任務的消耗是非常巨大的。很多任務計算的是同表同維度的，比如說兩個 SQL 語句都是查詢的同一張表，而且聚合的維度也相同。這種情況下其實可以把它們合成一個 SQL 去算，如下圖所示。

但是這裏面坑也很多，因爲一個 SQL 出問題，就全掛了。我們要做到一個 SQL 出問題，也不要影響其他 SQL。雖然我們把性能和效率提升上去，資源也節省了，但是帶來的程序管理上的成本也是非常高的。目前我們的總指標 13000+，緯度 3200+，實際節省計算和存儲約 60% 以上。

這個是我們在線的 WebIDE 的做法，無需搭建本地開發環境，在線開發測試，嚴格的輸入輸出管理，標準化輸入和輸出，一站式開發測試發佈監控。有兩種方式，第一種，我們有一個 Java 文件暴露出來，這個文件可以修改，但修改的幅度有限，提前用到的庫已經固定了，不能隨便亂加。我們在系統上做了一些控制，常用的一些 udf 或者是用戶要去做的一些個性化的開發都可以滿足。另外一種就是直接提交 Jar 包了，但需要做一些審覈。

下面是一個非常典型的場景，我們做遊戲運營的時候，通過這種渠道去通知用戶，比如說今天有活動你來參與。他登錄之後有日誌，我們立馬能夠感知到。通過 Flink 去做計算，我們可以定規則，用戶是今天第幾次登錄，或本月累計登錄多少次，或者是其他的一些離線的指標、實時的指標。算完之後就可以給用戶去做任務系統推薦之類的事情，這是一個基本的遊戲運營的過程。

下面是 Flink 特性的應用。

• 首先是時間特性：基於事件時間水印的監控，減少計算量，提高準確性。

• 另外一個是異步化 IO：提高吞吐量，確保順序性和一致性。

下圖是我們的一些案例介紹。

03

統一大數據接口服務 OneFun

 第三部分是遊戲數據接口服務。有了前面的鋪墊之後，大數據開發的門檻很低了。但是開發數據服務接口的門檻仍然很高。有沒有一種服務讓我能夠把數據以 API 的方式提供出去，讓別人繼續來操作。在經過探索之後，我們有這樣一種思路，就是函數化的服務。函數化服務是一種構建和部署服務端軟件的新方式，是面向部署單個的函數的一種方式。

所以我們開發了這樣一個服務，在這塊也是一個類似的核心層，底層是 K8s。執行引擎主要是兩種，一種是快速的規則表達式的判斷，還有一些比較複雜的困難表達式的判斷。另外還有一個就是 JavaScript、Golang 的這種函數支持。然後在上面能夠形成產品化服務，包括規則接口服務，函數接口服務，函數推薦服務，實時排行服務。

下面是函數引擎的一個執行，目前我們支持了這 4 種，分別是 Privileged V8，V8，Go VM，Lua VM。然後有統一的接入層，所有的函數片段能夠動態加載進來，然後在這裏面去執行。

執行的時候我們通過 Common Library 的一個公共庫在這塊去做。比如說，數據  redis，http， SQL 等，在公共庫我只要實現一遍，其它地方做一個應用就可以直接過來。通過這樣的一個執行引擎，我們的數據指標能夠以 API 的方式規範化的提供給用戶。

這是函數開發的一個接口。通過函數接口開發，降低啓動成本，更快的部署流水線，更快的開發速度，系統安全性更高，適應微服務架構，自動擴展能力。這塊做了之後，我們把數據到應用層，到用戶層的通路打通了。原來我們的數據都是在後臺計算完了之後放到數據庫裏面，等着別人來寫接口。現在一個人通過圖形化的頁面去配指標，再通過這種頁面方式去配接口，或者寫少量的代碼，完成一個數據接口服務的開發，就可以上線了。

這是一個 Flink 實時計算和函數服務結合的例子。比如，等級達到 15 級，且一個月之內活躍天數少於 5 天的用戶，贈送皮膚。玩家的登錄日誌過來之後，Flink 計算的時候要判斷等級，再判斷登錄天數。登錄天數是用自研的 SQL 算出來的結果值。滿足條件的話進行一個 RPC call，調用的結果需要依靠函數服務。

下圖爲遊戲內基於實時數據的社交關係推薦。比如說，活躍期的在線好友推薦，成熟期的在線站隊推薦，流失衰退期的好友召回，都會通過離線和實時的方式，以及 API 接口去完成。

 以下是我們整體的一個架構圖。底層灰色的部分不是這個平臺的一部分。只有上面這一部分是整個平臺的內容，包括服務場景，配置管理系統，服務調度系統。這個平臺不關注底層的 Flink 在哪，K8s 在哪，只要有人能提供類似的計算資源即可，但前提是穩定。整體架構就不詳細介紹了。

04

數據服務微服務化 & ServiceMesh 管理

 目前線上總上線活動 8.5K+，平均每週新上線 100+。如何保障應用服務支撐公司數百款業務的數據應用，如何快速複用，靈活開發同時還要穩定服務。

我們的業務開發場景面臨的困難包括：

• 功能模塊快速組合。

• 功能模塊各自獨立開發迭代。

• 不同功能根據實際情況獨立部署運營。

所以我們引入了微服務，微服務化帶來的便利包括：

• 開發更加靈活高效。

• 去中心化效率更高。

• 能力得到沉澱和複用。

下圖爲我們針對線上流量的一個管理平臺。我們參考業界比較著名的 ServiceMesh 框架，做東西南北流量的管控。在整個體系當中，如果數據 API 開發門檻過低，大量的 API 會很容易生成。但是 API 的使用是否規範、API 安全等是我們關注的問題。

所以我們花了很多功夫，希望把這些安全問題、管理問題解決好。我們在內部做了這個東西南北流量的管控，構建了這樣一個平臺專門去做流量的一個管控。

如下所示，東西流量的管控依靠我們的流量治理系統，一個平臺能夠支持多個集羣。我們在去年花了差不多半年時間把多集羣的問題解決掉，能夠嚴格控制 data API 的接口允許哪些人訪問，以及允許哪些服務訪問。數據很多時候是高敏感性的，包括一些用戶的畫像數據，不能存在安全問題。所以我們基於 istiod 和 K8s 的一些功能，去做東西流量的治理。東西流量主要是集羣類的流量。

對於南北向的流量管理，主要是出口流量。比如說，出去的流量一般都需要加密和鑑權，至少要啓用簡單的 acl 鑑權。所以做了這樣一個管控的方式，把各種信息能夠更快的下發到數據面，能夠在數據面這塊去做一些鑑權，還有一些告警日誌追蹤。

另外，在線服務很容易出現一些問題，在我們預知的流量波動或者未知的流量波動的情況之下，如何知道下游的服務應該做多大量的擴容。在我們上線的時候經常會出現這樣的問題，上線了突然來一波流量，需要擴容但結果我們只擴了一個服務，其他服務沒擴，或者是漏掉了一些服務。這種情況下漏掉的服務肯定會成爲整個服務的一個瓶頸點。

所以我們用 ServiceMesh 的技術來做全鏈路流量的分析。全鏈路前端通過上報數據，自動生成 DAG 圖形展示，經過壓測後，將鏈路數據生成快照， 通過時間點對比，可以快速的分析出各個模塊的流量放大與瓶頸點。如此，我們就知道了入口如果要擴容一倍，或者增加一臺機器的時候，相應的服務是否需要擴容，以及需要增加多少。在測試了這個功能，包括可觀察性、安全性以後，我們認爲這塊還是非常有必要去做的。

以下是內部的一些案例介紹。整個遊戲板塊都是基於我們的實時加離線的數據，包括現在所有的 170 多款遊戲，比較活躍的遊戲裏面中還會涉及營銷活動，缺了數據玩不轉，缺了我們的平臺，缺了我們的實驗數據也玩不轉。

今天的分享就到這裏，謝謝大家。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/kteVhQDXKTLur3gna-qv8A