大家好我是許振文，今天分享的主題是《基于Flink+ServiceMesh的騰訊游戲大數(shù)據(jù)服務(wù)應(yīng)用實(shí)踐》，主要會(huì)分為以下四個(gè)部分進(jìn)行分享：

首先介紹下背景，我們做游戲數(shù)據(jù)運(yùn)營(yíng)的時(shí)間是比較久的了，在13年的時(shí)候就已經(jīng)在做游戲離線數(shù)據(jù)分析，并且能把數(shù)據(jù)運(yùn)用到游戲的運(yùn)營(yíng)活動(dòng)中去。

但那時(shí)候的數(shù)據(jù)有一個(gè)缺陷，就是大部分都是離線數(shù)據(jù)，比如今天產(chǎn)生的數(shù)據(jù)我們算完后，第二天才會(huì)把這個(gè)數(shù)據(jù)推到線上。所以數(shù)據(jù)的實(shí)時(shí)性，和對(duì)游戲用戶的實(shí)時(shí)干預(yù)、實(shí)時(shí)運(yùn)營(yíng)效果就會(huì)非常不好。尤其是比如我今天中的獎(jiǎng)，明天才能拿到禮包，這點(diǎn)是玩家很不爽的。

現(xiàn)在提倡的是：“我看到的就是我想要的”或者“我想要的我立馬就要”，所以我們從16年開(kāi)始，整個(gè)游戲數(shù)據(jù)逐漸從離線運(yùn)營(yíng)轉(zhuǎn)到實(shí)時(shí)運(yùn)營(yíng)，但同時(shí)我們?cè)谧龅倪^(guò)程中，離線數(shù)據(jù)肯定少不了，因?yàn)殡x線的一些計(jì)算、累計(jì)值、數(shù)據(jù)校準(zhǔn)都是非常有價(jià)值的。

實(shí)時(shí)方面主要是補(bǔ)足我們對(duì)游戲運(yùn)營(yíng)的體驗(yàn)，比如說(shuō)在游戲里玩完一局或者做完一個(gè)任務(wù)后，立馬就能得到相應(yīng)的獎(jiǎng)勵(lì)，或者下一步的玩法指引。對(duì)用戶來(lái)說(shuō)，這種及時(shí)的刺激和干預(yù)，對(duì)于他們玩游戲的體驗(yàn)會(huì)更好。

其實(shí)不單單是游戲，其他方面也是一樣的，所以我們?cè)谧鲞@套系統(tǒng)的時(shí)候，就是離線+實(shí)時(shí)結(jié)合著用，但主要還是往實(shí)時(shí)方面去靠攏，未來(lái)大數(shù)據(jù)的方向也是，盡量會(huì)往實(shí)時(shí)方向去走。

1）游戲內(nèi)任務(wù)系統(tǒng)

這個(gè)場(chǎng)景給大家介紹一下，是游戲內(nèi)的任務(wù)系統(tǒng)，大家都應(yīng)該看過(guò)。比如第一個(gè)是吃雞里的，每日完成幾局？分享沒(méi)有？還有其他一些活動(dòng)都會(huì)做簡(jiǎn)歷，但這種簡(jiǎn)歷我們現(xiàn)在都是實(shí)時(shí)的，尤其是需要全盤(pán)計(jì)算或者分享到其他社區(qū)里的。以前我們?cè)谧鰯?shù)據(jù)運(yùn)營(yíng)的時(shí)候，都是任務(wù)做完回去計(jì)算，第二天才會(huì)發(fā)到獎(jiǎng)勵(lì)，而現(xiàn)在所有任務(wù)都可以做到實(shí)時(shí)干預(yù)。

游戲的任務(wù)系統(tǒng)是游戲中特別重要的環(huán)節(jié)，大家不要認(rèn)為任務(wù)系統(tǒng)就是讓大家完成任務(wù)，收大家錢(qián)，其實(shí)任務(wù)系統(tǒng)給了玩家很好的指引，讓玩家在游戲中可以得到更好的游戲體驗(yàn)。

2）實(shí)時(shí)排行版

還有一個(gè)很重要的應(yīng)用場(chǎng)景就是游戲內(nèi)的排行榜，比如說(shuō)王者榮耀里要上星耀、王者，其實(shí)都是用排行榜的方式。但我們這個(gè)排行榜可能會(huì)更具體一些，比如說(shuō)是今天的戰(zhàn)力排行榜，或者今天的對(duì)局排行榜，這些都是全局計(jì)算的實(shí)時(shí)排行榜。而且我們有快照的功能，比如0點(diǎn)00分的時(shí)候有一個(gè)快照，就能立馬給快照里的玩家發(fā)獎(jiǎng)勵(lì)。

這些是實(shí)時(shí)計(jì)算的典型應(yīng)用案例，一個(gè)任務(wù)系統(tǒng)一個(gè)排行榜，其他的我們后面還會(huì)慢慢介紹。

再說(shuō)一下為什么會(huì)有這樣一個(gè)平臺(tái)，其實(shí)我們最初在做數(shù)據(jù)運(yùn)營(yíng)的時(shí)候，是筒倉(cāng)式或者手工作坊式的開(kāi)發(fā)。當(dāng)接到一個(gè)需求后，我們會(huì)做一個(gè)資源的評(píng)審、數(shù)據(jù)接入、大數(shù)據(jù)的編碼，編碼和數(shù)據(jù)開(kāi)發(fā)完后，還要做線上資源的申請(qǐng)、發(fā)布、驗(yàn)證，再去開(kāi)發(fā)大數(shù)據(jù)計(jì)算完成后的服務(wù)接口，然后再開(kāi)發(fā)頁(yè)面和線上的系統(tǒng)，這些都完了后再發(fā)到線上去，做線上監(jiān)控，最后會(huì)有一個(gè)資源回收。

其實(shí)這種方式在很早期的時(shí)候是沒(méi)有問(wèn)題的，那為什么說(shuō)現(xiàn)在不適應(yīng)了？主要還是流程太長(zhǎng)了。我們現(xiàn)在對(duì)游戲運(yùn)營(yíng)的要求非常高，比如說(shuō)我們會(huì)接入數(shù)據(jù)挖掘的能力，大數(shù)據(jù)實(shí)時(shí)計(jì)算完成之后，我們還要把實(shí)時(shí)的用戶畫(huà)像，離線畫(huà)像進(jìn)行綜合，接著推薦給他這個(gè)人適合哪些任務(wù)，然后指引去完成。

這種情況下，原來(lái)的做法門(mén)檻就比較高了，每一個(gè)都要單獨(dú)去做，而且成本高效率低，在數(shù)據(jù)的復(fù)用性上也比較差，容易出錯(cuò)，而且沒(méi)有辦法沉淀。每一個(gè)做完之后代碼回收就扔到一塊，最多下次做的時(shí)候，想起來(lái)我有這個(gè)代碼了可以稍微借鑒一下，但這種借鑒基本上也都是一種手工的方式。

所以我們希望能有一個(gè)平臺(tái)化的方式，從項(xiàng)目的創(chuàng)建、資源分配、服務(wù)開(kāi)發(fā)、在線測(cè)試、獨(dú)立部署、服務(wù)上線、線上監(jiān)控、效果分析、資源回收、項(xiàng)目結(jié)項(xiàng)整個(gè)綜合成一站式的服務(wù)。

其實(shí)這塊我們是借鑒DevOps的思路，就是你的開(kāi)發(fā)和運(yùn)營(yíng)應(yīng)該是一個(gè)人就可以獨(dú)立完成的，有這樣一個(gè)系統(tǒng)能夠去支撐這件事。當(dāng)一個(gè)服務(wù)在平臺(tái)上呈現(xiàn)出來(lái)的時(shí)候，有可能會(huì)復(fù)用到計(jì)算的數(shù)據(jù)，比說(shuō)實(shí)時(shí)的登錄次數(shù)或擊殺數(shù)，那這個(gè)指標(biāo)在后面的服務(wù)中就可以共用。

而且有了這樣一個(gè)平臺(tái)之后，開(kāi)發(fā)者只需主要關(guān)注他的開(kāi)發(fā)邏輯就行了，其余兩條運(yùn)維發(fā)布和線上運(yùn)營(yíng)都由平臺(tái)來(lái)保證。所以我們希望有一個(gè)平臺(tái)化的方式，把數(shù)據(jù)計(jì)算和接口服務(wù)統(tǒng)一起來(lái)，通過(guò)數(shù)據(jù)的標(biāo)準(zhǔn)化和數(shù)據(jù)字典的統(tǒng)一，能夠形成上面不同的數(shù)據(jù)應(yīng)用，這個(gè)是我們的第一個(gè)目標(biāo)。

其實(shí)我們現(xiàn)在都是這種方式了，第一是要在DevOps的指導(dǎo)思想下去做，尤其是騰訊去做的時(shí)候數(shù)據(jù)服務(wù)的量是非常大的，比如我們?nèi)ツ暌还沧隽?、6萬(wàn)的營(yíng)銷(xiāo)服務(wù)，在這種情況下如果沒(méi)有平臺(tái)支撐，沒(méi)有平臺(tái)去治理和管理這些服務(wù)，單靠人的話成本非常大。

3個(gè)現(xiàn)代化，大數(shù)據(jù)應(yīng)用的DevOps。

我們的思路也是這樣，三個(gè)現(xiàn)代化，而且把大數(shù)據(jù)應(yīng)用的DevOps思路實(shí)現(xiàn)起來(lái)。

所以我們針對(duì)大數(shù)據(jù)的應(yīng)用系統(tǒng)，會(huì)把它拆成這樣三塊，一個(gè)是大數(shù)據(jù)的開(kāi)發(fā)，另外一個(gè)是數(shù)據(jù)服務(wù)接口的開(kāi)發(fā)，當(dāng)然接口后面就是一些頁(yè)面和客戶端，這些完了后這些開(kāi)發(fā)還要有一個(gè)完整的開(kāi)發(fā)流程支持。

這樣我們就能夠?yàn)楦鞣N數(shù)據(jù)應(yīng)用場(chǎng)景提供一站式的數(shù)據(jù)開(kāi)發(fā)及應(yīng)用解決服務(wù)、統(tǒng)一的活動(dòng)管理、數(shù)據(jù)指標(biāo)計(jì)算開(kāi)發(fā)管理和各種數(shù)據(jù)應(yīng)用接口自動(dòng)化生產(chǎn)管理的一站式的服務(wù)。

這樣的系統(tǒng)能保障這些的事情，而且我們這里也合理拆分，不要把大數(shù)據(jù)和接口混到一塊去，一定要做解耦，這是一個(gè)非常關(guān)鍵的地方。

1）計(jì)算存儲(chǔ) 

這個(gè)框架大家可以看一下，我認(rèn)為可以借鑒，如果你內(nèi)部要去做一個(gè)數(shù)據(jù)服務(wù)平臺(tái)的話，基本上思路也是這樣的，底層的Iass可以不用管，直接用騰訊云或者阿里云或者其他云上的服務(wù)就可以了。

我們主要是做上層這一塊的東西，最下面的計(jì)算存儲(chǔ)這個(gè)部分我們內(nèi)部在做系統(tǒng)的時(shí)候也不是care的，這塊最好是能承包出去?，F(xiàn)在Iass發(fā)展到這個(gè)程度，這些東西在云上可以直接像MySQL數(shù)據(jù)庫(kù)或者Redis數(shù)據(jù)庫(kù)一樣購(gòu)買(mǎi)就行了，比如Kafka、Pulsar、Flink、Storm。

存儲(chǔ)這塊我們內(nèi)部的有TRedis、TSpider，其實(shí)就是Redis和MySQL的升級(jí)版本。基礎(chǔ)這塊我建議大家如果自己構(gòu)建的話，也不需要太過(guò)于關(guān)注。

2）服務(wù)調(diào)度

系統(tǒng)核心主要是在中間的服務(wù)調(diào)度這個(gè)部分，它是統(tǒng)一的調(diào)度API，就是上層的一些服務(wù)能發(fā)下來(lái)，然后去統(tǒng)一調(diào)度。另外一個(gè)就是流程的開(kāi)發(fā)，我們有一個(gè)不可缺少的調(diào)度系統(tǒng)，這里我們使用的是DAG調(diào)度引擎，這樣我們可以把離線任務(wù)、實(shí)時(shí)任務(wù)、實(shí)時(shí)+離線、離線+函數(shù)接口的服務(wù)能夠組合起來(lái)，來(lái)完成更復(fù)雜實(shí)時(shí)數(shù)據(jù)應(yīng)用場(chǎng)景。

比如我們現(xiàn)在做的實(shí)時(shí)排行榜，把實(shí)時(shí)計(jì)算任務(wù)下發(fā)到Flink后，同時(shí)會(huì)給Flink下發(fā)一個(gè)URL，F(xiàn)link拿到URL后，它會(huì)把符合條件的數(shù)據(jù)都發(fā)送到URL，這個(gè)URL其實(shí)就是函數(shù)服務(wù)，這些函數(shù)服務(wù)把數(shù)據(jù)，在Redis里做排序，最終生成一個(gè)排行榜。

再往下的這個(gè)調(diào)度器，你可以不斷地去橫向拓展，比如我可以做Storm的調(diào)度器、Flink的調(diào)度器、Spark的調(diào)度器等等一系列。在這塊可以形成自己算法庫(kù)，這個(gè)算法庫(kù)可以根據(jù)場(chǎng)景去做，比如有些是Flink的SQL的分裝，也就是把SQL傳進(jìn)來(lái)，它就能夠計(jì)算和封裝的Jar包。另外比如一些簡(jiǎn)單的數(shù)據(jù)出發(fā)、規(guī)則判斷也可以去做，直接把算法庫(kù)分裝到這塊就行。

其實(shí)這塊和業(yè)務(wù)場(chǎng)景沒(méi)有直接關(guān)系的，但算法庫(kù)一定是和場(chǎng)景是有關(guān)系的，另外下層我們會(huì)有寫(xiě)文件通道，比如說(shuō)一些jar包的分發(fā)，這里騰訊用的是COS，能夠去做一些數(shù)據(jù)的傳輸和Jar包的提交。

還有一個(gè)命令管道，它主要針對(duì)機(jī)器，比如提交Flink任務(wù)的時(shí)候一定是通過(guò)命令管道，然后在一臺(tái)機(jī)器去把Jar包拉下來(lái)，然后同時(shí)把任務(wù)提交到Flink集群里去。數(shù)據(jù)管道也是類似的一個(gè)作用。

3）各種管理

另外還要將一個(gè)蠻重要的內(nèi)容，右邊綠色這塊的運(yùn)營(yíng)監(jiān)控、集群管理、系統(tǒng)管理（用戶權(quán)限管理，業(yè)務(wù)管理，場(chǎng)景管理，菜單配置管理等等），還有消息中心、幫助文檔，這些都是配套的，整個(gè)系統(tǒng)不可缺少的。

還有一部分是組件管理，包括大數(shù)據(jù)組件管理、函數(shù)管理、服務(wù)的二進(jìn)制管理都可以在這里能夠做統(tǒng)一的管理。

數(shù)據(jù)資產(chǎn)，比如我們通過(guò)Flink或者Storm能夠生成的數(shù)據(jù)指標(biāo)，它的計(jì)算邏輯的管理都在這里面，包括我們計(jì)算出來(lái)后，把這些指標(biāo)打上標(biāo)簽或者劃后，我們也作為數(shù)據(jù)資產(chǎn)。

還有一個(gè)最重要的是數(shù)據(jù)表的管理，我們無(wú)論是Flink或Storm，它的計(jì)算最終的落地點(diǎn)一定是通過(guò)一個(gè)數(shù)據(jù)表能算出來(lái)的。其他都還好，數(shù)據(jù)報(bào)表，比如每天計(jì)算多少數(shù)據(jù)，成功計(jì)算多少，每天有多少任務(wù)在跑，新增多少任務(wù)，這些都在里面可以做，包括我們版本的發(fā)布變更。

還有一個(gè)是外部管理端，這個(gè)根據(jù)業(yè)務(wù)場(chǎng)景去做就行了，等會(huì)演示我們管理端的時(shí)候大家就可以看到，其實(shí)我們的菜單相對(duì)來(lái)說(shuō)比較簡(jiǎn)單，根據(jù)比如我們的數(shù)據(jù)接入，從源頭把數(shù)據(jù)接入到Kafka或者Pulsar里去。然后數(shù)據(jù)指標(biāo)基于接入的數(shù)據(jù)表，進(jìn)行數(shù)據(jù)指標(biāo)的計(jì)算，比如一些特性的Jar包，它是多張表的數(shù)據(jù)混合計(jì)算，或者是加上的表的混合計(jì)算，等等一系列通過(guò)硬場(chǎng)景做的一些分裝。

我們最終把這些做完后，所有的大數(shù)據(jù)都是通過(guò)對(duì)外的服務(wù)API暴露出去的，比如最終游戲任務(wù)是否完成，用戶ID過(guò)來(lái)后我們能看這個(gè)用戶的任務(wù)是否完成，這樣的一些應(yīng)用場(chǎng)景可以直接使用API去操作。

這是整個(gè)流程，講得比較細(xì)后面大家才會(huì)更清晰。

這是我們整體的數(shù)據(jù)應(yīng)用流程：

我們的Game Server先把數(shù)據(jù)上傳到日志Server（數(shù)據(jù)接入部分），日志Server再把數(shù)據(jù)轉(zhuǎn)到Kafka或者Pulsar，就是消息隊(duì)列里。

接進(jìn)來(lái)后是數(shù)據(jù)表，數(shù)據(jù)表是描述，基于描述的表去開(kāi)發(fā)指標(biāo)、數(shù)據(jù)。比如我們這里一共有三類，一類是SQL，另外一類是我們已經(jīng)分裝好的框架，你可以自己去填充它的個(gè)性代碼，然后就可以在線完成Flink程序的編寫(xiě)。

還有一種是自己全新的在本地把代碼寫(xiě)好，再發(fā)到系統(tǒng)里去調(diào)測(cè)。之前說(shuō)了在大數(shù)據(jù)計(jì)算和數(shù)據(jù)接口一定要做解耦，我們解耦的方式是存儲(chǔ)，存儲(chǔ)我們用Redis。它這種做法是把Redis和SSD盤(pán)能夠結(jié)合起來(lái)，然后再加上RockDB，就是Redis里面它hold熱點(diǎn)數(shù)據(jù)，同時(shí)它把這些數(shù)據(jù)都通過(guò)這個(gè)RockDB落地到SSD盤(pán)里去，所以它的讀寫(xiě)性非常好，就是把整個(gè)磁盤(pán)作為數(shù)據(jù)庫(kù)存儲(chǔ)，而不像普通的Redis一樣再大數(shù)據(jù)情況下智能把內(nèi)存作為存儲(chǔ)對(duì)象。

在大數(shù)據(jù)把數(shù)據(jù)計(jì)算存儲(chǔ)進(jìn)去后，后面的就簡(jiǎn)單了，我們提供查詢的服務(wù)有兩種，一種是計(jì)算的指標(biāo)，點(diǎn)一下就可以生成接口，我們叫規(guī)則接口；然后我們另外一種，也提供特性化的存儲(chǔ)到介質(zhì)里，我可以自己去定義他的SQL或者查詢方式，然后在數(shù)據(jù)進(jìn)行加工處理，生成接口 。

還有一種方式，是我們?cè)贔link和Storm直接把數(shù)據(jù)配置我們這邊的一個(gè)函數(shù)接口，比如我剛才講的排行榜的方式，就給一個(gè)接口，他直接在Flink這邊處理完成之后，把數(shù)據(jù)吐到函數(shù)接口里面，函數(shù)接口對(duì)這個(gè)數(shù)據(jù)進(jìn)行二次處理。

這個(gè)是整個(gè)處理方式，所以我們前面講的就是，基于Flink和Storm構(gòu)建一個(gè)全面的、托管的、可配置化的大數(shù)據(jù)處理服務(wù)。主要消費(fèi)的是Kafka的數(shù)據(jù)，Pulsar現(xiàn)在在少量的使用。

這樣做就是我們把數(shù)據(jù)的開(kāi)發(fā)門(mén)檻降低，不需要很多人懂Flink或者Storm，他只要會(huì)SQL或者一些簡(jiǎn)單的邏輯函數(shù)編寫(xiě)，那就可以去完成大數(shù)據(jù)的開(kāi)發(fā)。

其實(shí)我們之前在做的時(shí)候，有一些優(yōu)化的過(guò)程，原來(lái)每一個(gè)計(jì)算任務(wù)都是用Jar包去寫(xiě)，寫(xiě)完之后就是編輯、打包、開(kāi)發(fā)、發(fā)布。后來(lái)我們劃分了三種場(chǎng)景，一種是SQL化，就是一些我們能用SQL表示的我們就盡量分裝成SQL，然后有一個(gè)Jar包能去執(zhí)行這個(gè)提交的SQL就可以了。

還有一種是在線的WebIDE，是處理函數(shù)的邏輯，舉例子Storm里可以把blot和spout暴露出來(lái)，你把這兩函數(shù)寫(xiě)完后，再把并行度提交就可以運(yùn)行。但這里我們具體實(shí)現(xiàn)的時(shí)候是基于Flink去做的。

另一個(gè)是場(chǎng)景化的配置，我們個(gè)性化的Jar包能夠統(tǒng)一調(diào)度，根據(jù)調(diào)度邏輯去執(zhí)行。

這是我們整個(gè)OneData計(jì)算體系的過(guò)程，支持三種，一種的自研的SQL，一種是Flink SQL，還有是Jar包。

我們自研的SQL是怎么存儲(chǔ)，最早是使用Storm，但StromSQL的效率非常低，所以我們根據(jù)SQL Parser做的SQL的分裝，我們對(duì)SQL自己進(jìn)行解析，自己形成函數(shù)，在SQL提交之后，我們用這樣的方式直接把它編譯成Java的字節(jié)碼，再把字節(jié)碼扔到Strom里去計(jì)算。

Flink這塊我們也繼承了這種方式，后面會(huì)講一下兩種方式有什么區(qū)別。其實(shí)我們自研SQL在靈活性上比Flink SQL要好一點(diǎn)。

這里是做平臺(tái)化，不能說(shuō)直接放一個(gè)FlinkSQL去跑，因?yàn)槲覀兿胍诶锩娼y(tǒng)計(jì)整個(gè)業(yè)務(wù)邏輯的執(zhí)行情況，比如SQL處理的數(shù)據(jù)量，正確的和錯(cuò)誤的，包括一些衰減，都是要做統(tǒng)計(jì)。

這是基本的過(guò)程，完了后我們?cè)谏厦嫘纬傻囊恍┗緢?chǎng)景，比如實(shí)時(shí)統(tǒng)計(jì)的場(chǎng)景，PV，UV，用獨(dú)立的Jar包去算就行了，配置一下表就可以去計(jì)算。另外實(shí)時(shí)指標(biāo)的服務(wù)，比如殺人書(shū)，金幣的積累數(shù)，游戲的場(chǎng)次，王者榮耀里下路走的次數(shù)，這種數(shù)據(jù)都可以作為實(shí)時(shí)指標(biāo)。

還有一種是規(guī)則觸發(fā)服務(wù)，表里的某個(gè)數(shù)據(jù)滿足什么條件時(shí)，觸發(fā)一個(gè)接口。還有通訊實(shí)時(shí)排行榜和一些定制化的服務(wù)。

1）自研SQL

接下來(lái)說(shuō)我們自研SQL的過(guò)程，我們?cè)缙跒榱吮苊庀馠ive一樣（函數(shù)棧調(diào)用），而我們自己通過(guò)SQL Paser的語(yǔ)法抽象后，把它生成一段函數(shù)，就不需要這么多的對(duì)賬調(diào)用。

這個(gè)是函數(shù)生成過(guò)程，最終生成的就是這樣一段代碼，它去做計(jì)算邏輯，一個(gè)函數(shù)完成，不需要函數(shù)棧的調(diào)用，這樣效率就會(huì)大大提升。我們?cè)瓉?lái)單核跑八萬(wàn)，放在現(xiàn)在可以跑二十多萬(wàn)。

整個(gè)處理的時(shí)候，我們把sql編譯成字節(jié)碼，F(xiàn)link消費(fèi)了數(shù)據(jù)后，把數(shù)據(jù)轉(zhuǎn)化成sql能夠執(zhí)行的函數(shù)，就是roll的方式。然后把Roll整個(gè)數(shù)據(jù)傳到class里去執(zhí)行，最后輸出。

這種場(chǎng)景適合于，比如flinksql它有狀態(tài)值，我們要統(tǒng)計(jì)某個(gè)最大值的話，要一直把用戶的最大值hold到內(nèi)存里去。而我們自研的SQL呢，自己寫(xiě)的函數(shù)，它把數(shù)據(jù)借助第三方存儲(chǔ)，比如剛才說(shuō)的TRedis存儲(chǔ)。每次只需要讀取和寫(xiě)入數(shù)據(jù)即可，不需要做過(guò)多的內(nèi)存的hold。

當(dāng)前做到狀態(tài)的實(shí)時(shí)落地，就算掛掉也能立馬起來(lái)接著去執(zhí)行，所以超過(guò)10G、100G的數(shù)據(jù)計(jì)算，都不成問(wèn)題，但是Flinksql如果要算的話，它的狀態(tài)值就一直要hould到內(nèi)存里去了，而且掛掉后只能用它的check point去恢復(fù)。

所以這是這兩種SQL的應(yīng)用場(chǎng)景。

2）SQL化

另外SQL里我們還可以做些其他的事情。我們的數(shù)據(jù)是持久化保存在存儲(chǔ)里的，那存儲(chǔ)里如果是同一張表，同一個(gè)緯度，比如我們都是用QQ，在這個(gè)緯度上我們配置了兩個(gè)指標(biāo)，那能不能一次算完？只消費(fèi)一次把數(shù)據(jù)算完，然后存儲(chǔ)一次。

其實(shí)這種在大數(shù)據(jù)計(jì)算里是很多的，目前在我們?cè)谧龅钠脚_(tái)化就可以，比如一個(gè)是計(jì)算登錄次數(shù)，另一個(gè)是計(jì)算最高等級(jí)，這兩個(gè)計(jì)算邏輯不一樣，但是消費(fèi)的數(shù)據(jù)表是一樣的，然后聚合緯度也是一樣的，聚合關(guān)鍵字也是一樣。那這個(gè)數(shù)據(jù)就可以進(jìn)行一次消費(fèi)，同時(shí)把數(shù)據(jù)計(jì)算出來(lái)同時(shí)去落地，大大減少了存儲(chǔ)和計(jì)算成本。

我們現(xiàn)在整個(gè)游戲里面有一萬(wàn)一千多個(gè)指標(biāo)，就是計(jì)算出來(lái)的，存儲(chǔ)的緯度有兩千六百多，實(shí)際節(jié)省計(jì)算和存儲(chǔ)約有60%以上。

兩個(gè)SQL，甚至更多的SQL，我們一張表算十幾個(gè)指標(biāo)很正常，原來(lái)要消費(fèi)十幾次現(xiàn)在只需要一次就可以算出來(lái)。而且這種情況對(duì)用戶是無(wú)感知的。A用戶在這張表上配了指標(biāo)是A緯度，B用戶在這張表上配了指標(biāo)也是A緯度，那這兩個(gè)用戶的數(shù)據(jù)，我們?cè)诘讓佑?jì)算的時(shí)候就消費(fèi)一次計(jì)算兩次存儲(chǔ)一次，最終拿到的數(shù)據(jù)也是一樣的。

3）在線實(shí)時(shí)編程

再介紹下剛才提到的在線實(shí)時(shí)編程，其實(shí)很多時(shí)候?qū)﹂_(kāi)發(fā)者來(lái)說(shuō)，搭建一個(gè)本地的Flink集群做開(kāi)發(fā)調(diào)測(cè)也是非常麻煩的，所以我們現(xiàn)在就是提供一種測(cè)試環(huán)境，上層的代碼都是固定的，不能修改。比如數(shù)據(jù)已經(jīng)消費(fèi)過(guò)來(lái)了，進(jìn)行數(shù)據(jù)的加工處理，最終往存儲(chǔ)里去塞就可以了。

通過(guò)這種方式，我們可以對(duì)簡(jiǎn)單邏輯進(jìn)行分裝，需要函數(shù)代碼，但比SQL復(fù)雜，比自動(dòng)的Jar包開(kāi)發(fā)要簡(jiǎn)單一些，可以在線寫(xiě)代碼，寫(xiě)完代碼直接提交和測(cè)試就能完成結(jié)果的輸出。而且這種的好處是，數(shù)據(jù)的上報(bào)邏輯，數(shù)據(jù)的統(tǒng)計(jì)邏輯，我都在這里面分裝好了。只要管業(yè)務(wù)邏輯的開(kāi)發(fā)就好了。

我們最早在Strom里做的時(shí)候，數(shù)據(jù)產(chǎn)生的時(shí)間和數(shù)據(jù)進(jìn)到消息隊(duì)列的時(shí)間，都是通過(guò)這種消息里自帶的時(shí)間戳，每一個(gè)消息都是要對(duì)比的。有了Flink之后，有了watermark這個(gè)機(jī)制之后，這一部分的計(jì)算就可以減少了。

實(shí)際測(cè)試下來(lái)的效果也是比較理想的，我們?cè)瓉?lái)在Storm里單核計(jì)算，大概是以前的QPS，加上讀寫(xiě)和處理性能，單核五個(gè)線程的情況下。但是Flink的時(shí)候我們可以到一萬(wàn)，還加上Redis存儲(chǔ)IO的開(kāi)銷(xiāo)。

另一個(gè)我們?cè)瓉?lái)數(shù)據(jù)想要從Redis里取出來(lái)，再去算最大值最小值，完了算了再寫(xiě)到Redis里，這個(gè)都是同步去寫(xiě)的，但是同步IO有一個(gè)問(wèn)題就是性能不高。

所以我們現(xiàn)在在把它改成異步IO，但是異步IO也有個(gè)特點(diǎn)就是整個(gè)一條數(shù)據(jù)的處理必須是同步的，必須先從Redis里把數(shù)據(jù)取出來(lái)，然后再把值計(jì)算完，再塞到里面去，保證塞完后再處理下一個(gè)統(tǒng)一的數(shù)據(jù)。

我們?cè)僮鲞@樣的一些優(yōu)化。Flink這里有些特性可以保證我們數(shù)據(jù)的一致性，而且提升效率。

接著介紹下更多的案例，如果大家玩英雄聯(lián)盟的話，那這個(gè)任務(wù)系統(tǒng)就是我們?cè)O(shè)計(jì)的，下次玩做這個(gè)任務(wù)的時(shí)候，你就可以想起我。還有天龍八部、CF、王者榮耀LBS榮耀戰(zhàn)區(qū)（通過(guò)大數(shù)據(jù)實(shí)時(shí)計(jì)算+LBS的數(shù)據(jù)排行）、王者榮耀的日?；顒?dòng)（實(shí)時(shí)數(shù)據(jù)+接口+規(guī)則計(jì)算）、有哪些好友是實(shí)時(shí)在線的，跟你匹配的。

下面介紹下函數(shù)，我們?cè)瓉?lái)在做的時(shí)候也是存在著一些問(wèn)題，把數(shù)據(jù)存到存儲(chǔ)里面，如果存儲(chǔ)直接開(kāi)放出去，讓別人任意去使用的話，其實(shí)對(duì)存儲(chǔ)的壓力和管理程度都是很有問(wèn)題的。所以后來(lái)我們采用了一種類似于Fass的的解決方式。我們把存儲(chǔ)在里面的元數(shù)據(jù)進(jìn)行管理，完了之后接口再配置化的方式，你要使用我這個(gè)DB，這個(gè)DB最大QPS多少，我就進(jìn)行對(duì)比，允許你之后才能使用這個(gè)量。

比如我這個(gè)DB的最大QPS只有10萬(wàn)，你要申請(qǐng)11萬(wàn)，那我就給你申請(qǐng)不了，我就只能通知DB把這個(gè)Redis進(jìn)行擴(kuò)容，擴(kuò)容后才給你提供使用。

所以這里面牽扯到我們的指標(biāo)數(shù)據(jù)的元數(shù)據(jù)管理和接口之間的打通。

這個(gè)和剛才OneData的方式是一樣的，比如這塊提供了快速的函數(shù)，還有一些在線函數(shù)編程的方式的接口，你可以在上面寫(xiě)一點(diǎn)JavaScript或者 Golang代碼，然后就生成接口，接口里面可以直接對(duì)外提供服務(wù)，把他形成產(chǎn)品化的包裝，在上層根據(jù)接口衍生出更多其他的一些應(yīng)用系統(tǒng)。

這里重點(diǎn)介紹下golang，其實(shí)我們是基于golang語(yǔ)言本身ssa的特點(diǎn)去做的，我們有一個(gè)執(zhí)行器，這個(gè)執(zhí)行器已經(jīng)寫(xiě)好的，它的作用就是可以把你寫(xiě)的golang代碼提交過(guò)來(lái)，加載到它的執(zhí)行器里。

并且我們可以把我們寫(xiě)的代碼作為函數(shù)庫(kù)，積累下來(lái)然后放進(jìn)去，它可以在執(zhí)行的時(shí)候去調(diào)用這些函數(shù)庫(kù)，而這里面寫(xiě)的代碼語(yǔ)法和golang是完全一樣的。

同時(shí)我們?cè)谶@里面執(zhí)行的時(shí)候，指定了一個(gè)協(xié)程，每一個(gè)協(xié)程我們規(guī)定它的作用域，就是以沙箱機(jī)制的方式來(lái)去執(zhí)行，最先實(shí)現(xiàn)的就是外部context去實(shí)現(xiàn)的，我們就可以實(shí)現(xiàn)web化的golang開(kāi)發(fā)，這種有點(diǎn)像lua那種腳本語(yǔ)言一樣，你在線寫(xiě)完語(yǔ)言直接提交執(zhí)行。

這是我們的javascript的執(zhí)行引擎，我們主要是做了V8引擎的池子，所有javascript寫(xiě)完之后，丟到V8引擎上去執(zhí)行，這應(yīng)該大家都能夠理解，如果大家玩過(guò)JS的可以理解這種方式，就是V8引擎里直接去執(zhí)行。

這是我們的在線函數(shù)編寫(xiě)過(guò)程：

右下角是我們的函數(shù)代碼編寫(xiě)區(qū)，寫(xiě)完后左邊的黑框是點(diǎn)擊測(cè)試，輸出可以在這里寫(xiě)，點(diǎn)擊測(cè)試就會(huì)把結(jié)果輸出出來(lái)，通過(guò)這種方式，我們極大地?cái)U(kuò)張了我們數(shù)據(jù)平臺(tái)的開(kāi)發(fā)能力。原來(lái)是本地要把golang代碼寫(xiě)完，然后調(diào)試完再發(fā)到線上環(huán)境去測(cè)試，而現(xiàn)在我們可以很大的規(guī)范化，比如說(shuō)數(shù)據(jù)源的引入，我們就直接可以在這里去規(guī)定了，你只能引入申請(qǐng)過(guò)的數(shù)據(jù)源，你不能隨便亂引入數(shù)據(jù)源，包括你數(shù)據(jù)源引入的時(shí)候，QPS放大我都可以通過(guò)這種方式知道。

這個(gè)是我們一站式，把函數(shù)開(kāi)發(fā)完后，直接提交，我們用Prometheus + grafana可以里面看到實(shí)時(shí)報(bào)表。

這是一個(gè)典型的應(yīng)用，F(xiàn)link里面去計(jì)算的時(shí)候，他對(duì)這個(gè)數(shù)據(jù)進(jìn)行過(guò)濾，完了之后進(jìn)行一個(gè)遠(yuǎn)程的call，這個(gè)遠(yuǎn)程調(diào)用執(zhí)行函數(shù)代碼，大多數(shù)這種情況就是一個(gè)開(kāi)發(fā)就可以完成大數(shù)據(jù)的開(kāi)發(fā)和這個(gè)函數(shù)接口的開(kāi)發(fā)，就可以完成這樣一個(gè)活動(dòng)的開(kāi)發(fā)，整個(gè)活動(dòng)開(kāi)發(fā)的門(mén)檻就低了很多，真正實(shí)現(xiàn)了我們DevOps，就是開(kāi)發(fā)能夠把整個(gè)流程自己走完。

上面講的是OneData和OneFun的實(shí)現(xiàn)原理和機(jī)制，我們?cè)趦?nèi)部是怎么去應(yīng)用的，這套系統(tǒng)我們?cè)谟螒騼?nèi)部是大力推廣。

這里尤其是接口這塊，其實(shí)如果說(shuō)要微服務(wù)化的話，大數(shù)據(jù)我們能做的也就是那樣了，能夠用yarn或者K8S去做資源的管控，和任務(wù)的管控，但真正去做服務(wù)治理還是在接口這塊。目前我們上下接口大概是三千五百個(gè)，每周新增50個(gè)接口。

所以我們?cè)谧龅臅r(shí)候也考慮到。原來(lái)我們服務(wù)是一個(gè)個(gè)開(kāi)發(fā)，但是沒(méi)有治理，現(xiàn)在我們加上服務(wù)還是一個(gè)個(gè)去開(kāi)發(fā)，甚至有些服務(wù)我們會(huì)把它變成一個(gè)服務(wù)，但是我們加入了這個(gè)服務(wù)的治理。

好多人在提微服務(wù)，微服務(wù)如果沒(méi)有一個(gè)平臺(tái)去治理的話，將會(huì)是一種災(zāi)難。所以微服務(wù)化給我們帶來(lái)便利的同時(shí)，也會(huì)給我們帶來(lái)一些問(wèn)題，所以在我們的場(chǎng)景里面，微服務(wù)是非常好的，每一個(gè)接口就可以作為一個(gè)服務(wù)，這種是天然的微服務(wù)。

但是這種微服務(wù)的治理將會(huì)是我們很大的一個(gè)問(wèn)題，所以我們花了很大的精力去做了一個(gè)微服務(wù)的治理系統(tǒng)，從項(xiàng)目注冊(cè)的時(shí)候，他就把項(xiàng)目注冊(cè)的微服務(wù)中心，并且把API注冊(cè)上來(lái)，然后在服務(wù)發(fā)布的時(shí)候，發(fā)到集群里的時(shí)候，這些服務(wù)都要主動(dòng)的注冊(cè)到我們的名冊(cè)服務(wù)，就是Consoul。

但注冊(cè)到服務(wù)里不是作為服務(wù)路由來(lái)用的，而是到服務(wù)里后，我們?cè)谄樟_米修斯這塊去做它的健康檢查和狀態(tài)采集，只要注冊(cè)上來(lái)，我立馬就能感知和把狀態(tài)采集過(guò)來(lái)，然后主要做實(shí)時(shí)報(bào)表和告警。

首先在服務(wù)的穩(wěn)定性和健康度這塊我們有一個(gè)保障，另外一個(gè)就是服務(wù)的信息注冊(cè)到Consul里去后，我們有一個(gè)服務(wù)的網(wǎng)關(guān)，我們用的是envoy，其實(shí)內(nèi)部我們還把它作為SideCar使用，后面會(huì)介紹。

注冊(cè)完了之后，envoy會(huì)把這個(gè)所有的負(fù)載進(jìn)信息加載到這塊來(lái)，它去做它服務(wù)的路由，同時(shí)我們會(huì)把整個(gè)日志上報(bào)到日志中心去，包括網(wǎng)關(guān)的日志也會(huì)上傳到日志中心去，日志中心再去做離線的報(bào)表和實(shí)時(shí)的一些報(bào)警監(jiān)控，

所以這里面我們還加了一個(gè)基于Consul的一個(gè)配置，就是我們包括server的實(shí)時(shí)控制都可以通過(guò)Consul去配置，配置完了后立馬能夠watch到，然后去執(zhí)行。

這個(gè)是基本的服務(wù)治理，但現(xiàn)在我們的服務(wù)治理升級(jí)了，比這個(gè)要更好一點(diǎn)，基本的原理是這樣。

并且我們?cè)谶@里面實(shí)現(xiàn)了一個(gè)對(duì)envoy的管控，我們說(shuō)是服務(wù)治理，主要是對(duì)流量的一些治理，比如貧富負(fù)載策略，路由策略，熔斷，超時(shí)控制，故障注入等等一系列。

我們是通過(guò)Consul的配置管理，通過(guò)它能夠下發(fā)到我們的Agent，這個(gè)Agent再把這個(gè)數(shù)據(jù)能夠通過(guò)Istio的接口和 k8s的API能夠下發(fā)到envoy，這里面就是API GeteWay和SideCar都是envoy，所以我們通過(guò)Istio對(duì)他的XDS的接口寫(xiě)入，就可以把所有的配置信息下發(fā)到這里。

這套系統(tǒng)能夠整個(gè)去管控整個(gè)集群，南北流量和東西流量的統(tǒng)一管控。這套系統(tǒng)我們未來(lái)準(zhǔn)備開(kāi)源，現(xiàn)在主要是內(nèi)部在使用，而且這里面我們也做了圖形化的配置，所有envoy和Istio的配置我們都經(jīng)過(guò)YAML轉(zhuǎn)Istio再轉(zhuǎn)UI的方式，把它圖形化了，在這塊能夠做統(tǒng)一的管控。

而且我們把Agent開(kāi)發(fā)完了之后就是多集群的支持，就是多個(gè)K8s集群只要加入進(jìn)來(lái)，沒(méi)問(wèn)題可以去支持，我們管理API GeteWay。

還有一塊是SideCar的管理，就是ServiceMash里的SideCar管理。我們剛才說(shuō)的函數(shù)接口也好，規(guī)則接口也好，是一個(gè)server。

當(dāng)然這里面還提到一個(gè)chaos mesh的功能，我們現(xiàn)在還在研究，我們準(zhǔn)備在這套系統(tǒng)里把它實(shí)現(xiàn)了。

這是一個(gè)我們通過(guò)ServiceMesh做的分析，我們雖然可以宏觀地看出來(lái)我們接口對(duì)DB的壓力有多大，但實(shí)際上我們把流量導(dǎo)進(jìn)來(lái)是我們對(duì)壓力的監(jiān)控是不夠的，所以這種情況我們通過(guò)ServiceMesh，他對(duì)出口流量和進(jìn)口流量的管控，然后可以把流量進(jìn)行詳細(xì)的統(tǒng)計(jì)，統(tǒng)計(jì)完后可以生成一個(gè)快照，這次快照和下次快照之間的數(shù)據(jù)對(duì)比，入流量有多少的時(shí)候，對(duì)下面各個(gè)流量壓力有多少。

這是整個(gè)展示圖，我們有多個(gè)測(cè)試用例，這兩個(gè)測(cè)試用例之間我們可以算出來(lái)對(duì)下游的壓力的流量分析，后期對(duì)下游壓力的分析和下游資源的擴(kuò)容、縮容都有非常大的價(jià)值。

最后再介紹下我們目前用這套系統(tǒng)實(shí)現(xiàn)的一些案例，大數(shù)據(jù)的游戲回歸，比如做一個(gè)游戲數(shù)據(jù)的回顧 （生涯回顧）、任務(wù)系統(tǒng)、排行榜。