摘要：本文整理自網易互娛技術中心計費實時平臺與 SDK 技術負責人林佳在 Flink Forward Asia 2021 行業實踐專場的演講。本篇內容主要分為三個部分：
- 從一次 APP 內購買支付聊起
- 實時 SDK 與平臺化的雙線發展
- 走向實時全關聯
說到網易互娛，大家首先想到的肯定是遊戲。作為網易的核心業務線之一，讓遊戲業務可以穩定可靠地執行自然是重中之重，而遊戲業務中最重要就是 APP 內購買服務的可靠性。本文的分享，就從一次 APP 內購買聊起。
一、從一次 APP 內購買支付聊起
玩家在遊戲內購買道具的操作，首先會觸發客戶端行為與渠道商、計費中心進行通訊，完成下單與支付。計費中心也會與渠道商進行互動，驗證客戶端訂單的合法性以及支付狀態。只有訂單合法，遊戲服務才會被通知發貨。而這一整套流程下來，每一個參與者產生的日誌、資料監控點等等，它們的來源、資料結構、時間步調可能是千差萬別的。此外，這個過程中還有通訊網路、資料庫、監控系統等的參與，使得整個過程非常複雜。
資料持續而大量地產生，資料之間會話的關聯、資料來源之間的異構、資料結構的異構還有時間步調的不一致等等，都是我們選擇用實時方式去處理的原因。
2017 年之前我們的處理方式相對落後，其中還有一些比較陳舊的處理方式，比如網盤、rsync、T+1 處理離線任務等。
元件繁多、技術棧的割裂、時效性低、資源使用情況粗糙等，都會使資源無法被均勻地利用，而這正是帶來時效性低的原因之一，也使程式碼能效、資料能效和資源能效都相對較低。
上圖是我們之前的離線計算業務執行時的資源情況示意，在凌晨的時候去計算前一天的資料包表。在流式計算普及之前，這是一種非常大規模使用的模式，在凌晨的時候用一大批機器執行 Spark 離線任務去計算前一天的結果。為了使報表可以按時交付，整個離線叢集需要大算力，堆疊大量的機器資源，而這些機器資源在許多時間段卻是空閒的，這便造成了資源能效低下。
如果這類計算任務可以被實時化，那麼它所需要的算力即可被分攤到每一個時間片上，避免在凌晨的時候資源使用嚴重傾斜。這些機器算力可以被託管在資源管理的平臺上，所以它們也可以被其他業務所使用，進而提升能效。
那麼如何選擇實時化的框架？經過深刻的調研和嘗試之後，我們最終選擇了 Flink，它所提供的特性，可以說是完全適配了我們的場景，下圖列舉了我們關於技術架構選型的一些考慮。
二、實時 SDK 與平臺化的雙線發展
網易互娛從 2018 年開始便制定了雙線發展計劃，全面推進資料中心 JFlink 的實時化程式。
經過多次迭代，目前我們已經形成了一個一站式的運維平臺 + 一個支援配置化開發的 SDK，且已經完成了從可用到實用的進階，下一步就是讓使用者愛用。
如何提高人力以及程式碼的效能，是我們從一開始設計 JFlink 的時候就極其注重的。我們希望可以用有限的人力最大化地發揮出能效，所以 SDK 的配置化、模組化變得尤為重要，要實現每一個實時作業都可以用一套配置語義來描述。
SDK 中封裝了 JFlink SDK 常用的聯結器處理函式以及資料的流轉物件，使得可以以配置化的形式來組裝和使用它們。SDK 還提供了統一的配置文法，能夠將作業以配置的形式描述後，動態地去組織構造 Flink DAG，以實現一個 SDK 程式包覆蓋各類資料業務的特性，提高程式碼的複用和能效。
在 SDK 上，可以通過編寫或生成 Kafka source、TiDB sink 以及中間聚合視窗的 UDF，即可拉起一個實時業務，不需要任何額外的開發。
為了配合 SDK 作業的統一文法，我們也構建了一個一站式的處理平臺，資料運維人員可以一站式、便捷、視覺化地構造自己的資料業務。
即便 DAG 如此錯綜複雜，也依然可以用解析文法來生成。
SDK 化戰略實現了功能模組化、作業配置化、資料檢視化以及流批一體化，讓模組複用成為日常，讓每個人都能相互理解彼此的作業，讓異構的資料能為每一種寫好的 UDF 模組進行處理，更重要的是讓歷史作業可以過渡到 Flink 上。
SDK 化還為我們提供了快速跟隨社群升級 Flink 版本的能力。SDK 隔離了業務邏輯和 Stream API，且絕大多數擴充套件功能都是在 SDK 側對 Flink 原生類的擴充。這在跟隨 Flink 進行大版本升級時，一方面業務側可以做到近乎零改動升級，另一方面也解決了內部關於 Flink 的擴充功能需要不斷從各個版本的內部分支向新版分支上做合併的巨大代價。
而雙線發展計劃中的另一側則是網易互娛的一站式平臺，它完全基於 K8s 實現了作業的獨立叢集化執行。
上圖是平臺的技術架構圖，它配套的 Nexus、HDFS 等大資料元件來作為基礎設施，維護了版本化的軟體倉庫，裡面託管了包括 SDK 以及其他業務 jar 包。執行層面，Flink 使用了 k8s 獨立叢集的理念，即每一個作業都執行在自己獨立的 k8s 名稱空間下，擁有自己的資源配套以及依賴集合，實現了業務作業的完全隔離執行以及資源的精細化調配。
為跟蹤業務的迭代、作業的執行以及日誌集分析等等的平臺化功能，JFlink 平臺還封裝好了各種運維介面，通過無狀態的 rest 服務節點對外提供。平臺還為運維人員提供了視覺化建立實時作業的功能，這也正是我們把平臺與 SDK 相互配合而產生的優秀成果。
在一站式平臺上，使用者可以監視自己的作業實時狀態，查閱執行日誌，回滾歷史版本，甚至可以查閱歷史的異常、記錄與統計、風險控制、生命週期的詳細管理。
除了上述提到的能力，我們的一站式平臺上還有相當多其他功能，所有的功能與 SDK 相互配合共同組成了我們的實時計算體系。
三、走向實時全關聯
接下來，從資料業務的角度出發，分析闡述網易互娛在計費這一關鍵領域上開展實時業務的經驗與實踐。
我們最早的實踐是對計費節點上產生的資料日誌進行統計分析。不同來源的日誌往往形式各異、千奇百怪，尤其是外部渠道商的回撥，更是難以規範其日誌格式，應該如何處理這些雜亂的格式，將它們變成一種可以統一處理的資料？這是我們第一個探索目標。
為此， SDK 封裝了可以通過定義抽象語法樹來處理半結構化資料的 UDF Message Unified Parse，也制定了一些可以處理 Group By 以及聚合函式的 UDF。這樣的需求，以配置文法的形式實現了這個統計業務，並通過封裝的 Sink，寫入自研的 TSDB 中。
日誌分析監控是從點的角度對計費業務介面、模組的訪問量、法規情況和時延等來進行監控，以此實現對業務的無侵入式實時監視，降低了原先通過微批處理的時延以及業務伺服器上監控指令碼導致的 CPU 開銷，也提高了監控發現率，使業務更可靠。
緊接著，我們把目光投向了做通用的 ETL 框架。
異構資料通過 Parser 可以轉化為統一的檢視和統一的流轉物件，隨後可以被內建的符合協議的 UDF 進行處理轉換，我們還實現了一個 JavaScript UDF，通過靈活地 JS 指令碼的嵌入，實現了輕鬆便捷地處理資料的轉換工作。
通過 Flink 處理的資料流入我們自研的異構資料倉儲中，可以讓業務方很方便地使用。還可以直接使用 SQL 來對實時產生的日誌進行查詢，甚至對這些日誌進行聚合。而這些業務是以點的角度，將支付環境上的介面模組產生的資料實時地利用起來，每日處理的資料量大約在 30 Billion 級別，它為後續展開更深一步的資料業務實時化提供了有力的保障。
在 2019 年左右，我們開始考慮如何把這些點關聯成有機的線？即將在支付環境上發生的支付，會從頭到尾進行一個全鏈路的關聯分析，這其中的服務是否會發生問題？
這些服務的日誌來源千差百怪，可能是來自於客戶端的日誌，可能是計費的日誌，也可能是閘道器的日誌。而針對這些與上下文分析有關的鏈路式的日誌，其實 Flink 已經為我們提供了非常方便的 API，就是 keyed stream + session window。
上圖是全鏈路監控的架構圖。鏈路分析的知識被封裝成了模型，並載入到 Flink 實時分析的程式中。它會把一條支付鏈路上的資料進行實時串聯，然後寫入到我們自研的圖資料庫中，供下游繼續使用。此外，它還提供了 Daily Spark Job 來處理異常鏈路，以完成一些鏈路補全的需求，這也是對於 Lambda 架構的一種實踐。
上圖展示了全鏈路串聯的效果。一筆支付訂單可以被串聯和展示，這種方式非常有利於 DBA 和產品去定位支付問題。
2020 年左右，網易互娛開始了對實時數倉的探索，其中一個很重要的應用就是使用者畫像系統。
此前 T+1 的形式展示資料包表，時效性比較低。將報表升級改造和實時化之後，現在已經可以通過介面的形式做到即時查詢。而這種時效性的提升使得產品可以去做精細化的運營，更及時地響應營銷需求，進而提升收益。
這些千差萬別的計算，也是通過配置 +SDK 的形式來實現的。
尤其是流式的資料打寬，利用 Flink 提供的 Async IO 去外表進行 Lookup Join，都是實時處理資料的得力助手。
實時使用者數倉和實時數倉指標為產品提供了玩家級的微觀查詢和報表級的巨集觀查詢。這些使用者資料可以對接到視覺化工具，通過資料視覺化直觀地進行展示，讓產品運營可以發現從數字中無法發現的規律，進一步挖掘出其中的資料價值。
有了上述實踐之後，我們開始思考，在一筆鏈路、一個使用者的層次上，能否能將整個支付環境上的各種資料都關聯起來，實現支付環境的巨集觀監控。
我們將支付環境會話上各種異構術語，比如支付資料庫 TiDB、支付中介軟體產生的各種日誌資料，都通過 Flink 的 Interval Join 特性來進行關聯分析。
比如在 TiDB 中，儲存有下單與付款的資料庫 40 行，日誌中有使用者從客戶端下單到渠道回撥等支付過程的記錄，對它們分別關聯即可分析出對應服務模組的情況。
進一步可以把各個模組情況產生的鏈路再進行關聯合並，最終得到整個支付環境上的關聯分析結果。
例如，存在一種可能的異常，資料日誌發貨完畢後，數量驟減或錯誤碼的情況很多，那麼運維人員可以很快發現發貨服務存在異常。如上圖展示這類關聯分析的情況，在生成環境的一些複雜場景中，這套全關聯分析框架處理了近十種異構源的資料、關聯分析出幾十種情況的業務場景會話。基於關聯分析的能力做出的許多支付環境上的實時報表，以協助運營修復問題，指導產品制定策略，最終提升收益。
資料業務實時化之後帶來的資源能效和資料能效的提升有目共睹，而高時效性帶來了全新的資料使用靈感的迸發，這也正是 Flink 帶來的全新的大資料未來。
更多 Flink 相關技術問題，可掃碼加入社群釘釘交流群
第一時間獲取最新技術文章和社群動態，請關注公眾號～
