王者榮耀背後的實時大數據平臺用了什麼黑科技？

你們好我是許振文，今天分享的主題是《基於 Flink+ServiceMesh 的騰訊遊戲大數據服務應用實踐》，內容主要分爲如下四個部分：

1. 背景和解決框架介紹
2. 實時大數據計算 OneData
3. 數據接口服務 OneFun
4. 微服務化& ServiceMesh

1、背景和解決框架介紹

一、離線數據運營和實時數據運營

首先介紹下背景，咱們作遊戲數據運營的時間是比較久的了，在 13 年的時候就已經在作遊戲離線數據分析，而且能把數據運用到遊戲的運營活動中去。

但那時候的數據有一個缺陷，就是大部分都是離線數據，好比今天產生的數據咱們算完後，次日纔會把這個數據推到線上。因此數據的實時性，和對遊戲用戶的實時干預、實時運營效果就會很是很差。尤爲是好比我今天中的獎，明天才能拿到禮包，這點是玩家很不爽的。

如今提倡的是：「我看到的就是我想要的」或者「我想要的我立馬就要」，因此咱們從 16 年開始，整個遊戲數據逐漸從離線運營轉到實時運營，但同時咱們在作的過程當中，離線數據確定少不了，由於離線的一些計算、累計值、數據校準都是很是有價值的。

實時方面主要是補足咱們對遊戲運營的體驗，好比說在遊戲裏玩完一局或者作完一個任務後，立馬就能獲得相應的獎勵，或者下一步的玩法指引。對用戶來講，這種及時的刺激和干預，對於他們玩遊戲的體驗會更好。

其實不僅僅是遊戲，其餘方面也是同樣的，因此咱們在作這套系統的時候，就是離線+實時結合着用，但主要仍是往實時方面去靠攏，將來大數據的方向也是，儘可能會往實時方向去走。

二、應用場景

■ 1）遊戲內任務系統

這個場景給你們介紹一下，是遊戲內的任務系統，你們都應該看過。好比第一個是吃雞裏的，每日完成幾局？分享沒有？還有其餘一些活動都會作簡歷，但這種簡歷咱們如今都是實時的，尤爲是須要全盤計算或者分享到其餘社區裏的。之前咱們在作數據運營的時候，都是任務作完回去計算，次日纔會發到獎勵，而如今全部任務均可以作到實時干預。

遊戲的任務系統是遊戲中特別重要的環節，你們不要認爲任務系統就是讓你們完成任務，收你們錢，其實任務系統給了玩家很好的指引，讓玩家在遊戲中能夠獲得更好的遊戲體驗。

■ 2）實時排行版

還有一個很重要的應用場景就是遊戲內的排行榜，好比說王者榮耀裏要上星耀、王者，其實都是用排行榜的方式。但咱們這個排行榜可能會更具體一些，好比說是今天的戰力排行榜，或者今天的對局排行榜，這些都是全局計算的實時排行榜。並且咱們有快照的功能，好比 0 點 00 分 的時候有一個快照，就能立馬給快照裏的玩家發獎勵。

這些是實時計算的典型應用案例，一個任務系統一個排行榜，其餘的咱們後面還會慢慢介紹。

三、遊戲對數據的需求

再說一下爲何會有這樣一個平臺，其實咱們最初在作數據運營的時候，是筒倉式或者手工做坊式的開發。當接到一個需求後，咱們會作一個資源的評審、數據接入、大數據的編碼，編碼和數據開發完後，還要作線上資源的申請、發佈、驗證，再去開發大數據計算完成後的服務接口，而後再開發頁面和線上的系統，這些都完了後再發到線上去，作線上監控，最後會有一個資源回收。

其實這種方式在很早期的時候是沒有問題的，那爲何說如今不適應了？主要仍是流程太長了。咱們如今對遊戲運營的要求很是高，好比說咱們會接入數據挖掘的能力，大數據實時計算完成以後，咱們還要把實時的用戶畫像，離線畫像進行綜合，接着推薦給他這我的適合哪些任務，而後指引去完成。

這種狀況下，原來的作法門檻就比較高了，每個都要單獨去作，並且成本高效率低，在數據的複用性上也比較差，容易出錯，並且沒有辦法沉澱。每個作完以後代碼回收就扔到一塊，最多下次作的時候，想起來我有這個代碼了能夠稍微借鑑一下，但這種借鑑基本上也都是一種手工的方式。

因此咱們但願能有一個平臺化的方式，從項目的建立、資源分配、服務開發、在線測試、獨立部署、服務上線、線上監控、效果分析、資源回收、項目結項整個綜合成一站式的服務。

其實這塊咱們是借鑑 DevOps 的思路，就是你的開發和運營應該是一我的就能夠獨立完成的，有這樣一個系統可以去支撐這件事。當一個服務在平臺上呈現出來的時候，有可能會複用到計算的數據，比說實時的登陸次數或擊殺數，那這個指標在後面的服務中就能夠共用。

並且有了這樣一個平臺以後，開發者只需主要關注他的開發邏輯就好了，其他兩條運維發佈和線上運營都由平臺來保證。因此咱們但願有一個平臺化的方式，把數據計算和接口服務統一塊兒來，經過數據的標準化和數據字典的統一，可以造成上面不一樣的數據應用，這個是咱們的第一個目標。

其實咱們如今都是這種方式了，第一是要在 DevOps 的指導思想下去作，尤爲是騰訊去作的時候數據服務的量是很是大的，好比咱們去年一共作了 五、6 萬的營銷服務，在這種狀況下若是沒有平臺支撐，沒有平臺去治理和管理這些服務，單靠人的話成本很是大。

四、思路

3 個現代化，大數據應用的 DevOps。

咱們的思路也是這樣，三個現代化，並且把大數據應用的 DevOps 思路實現起來。

• 規範化：流程規範、數據開發規範和開發框架；
• 自動化：資源分配、發佈上線、監控部署（這是 DevOps 裏不可缺乏的）；
• 一體化：數據開發、數據接口開發、測試發佈、運維監控。

因此咱們針對大數據的應用系統，會把它拆成這樣三塊，一個是大數據的開發，另一個是數據服務接口的開發，固然接口後面就是一些頁面和客戶端，這些完了後這些開發還要有一個完整的開發流程支持。

這樣咱們就可以爲各類數據應用場景提供一站式的數據開發及應用解決服務、統一的活動管理、數據指標計算開發管理和各類數據應用接口自動化生產管理的一站式的服務。

這樣的系統能保障這些的事情，並且咱們這裏也合理拆分，不要把大數據和接口混到一塊去，必定要作解耦，這是一個很是關鍵的地方。

五、數據服務平臺總體架構

■ 1）計算存儲 

這個框架你們能夠看一下，我認爲能夠借鑑，若是你內部要去作一個數據服務平臺的話，基本上思路也是這樣的，底層的 Iass 能夠不用管，直接用騰訊雲或者阿里雲或者其餘雲上的服務就能夠了。

咱們主要是作上層這一塊的東西，最下面的計算存儲這個部分咱們內部在作系統的時候也不是 care 的，這塊最好是能承包出去。如今 Iass 發展到這個程度，這些東西在雲上能夠直接像 MySQL 數據庫或者 Redis 數據庫同樣購買就好了，好比 Kafka、Pulsar、Flink、Storm。

存儲這塊咱們內部的有 TRedis、TSpider，其實就是 Redis 和 MySQL 的升級版本。基礎這塊我建議你們若是本身構建的話，也不須要太過於關注。

■ 2）服務調度

系統核心主要是在中間的服務調度這個部分，它是統一的調度 API，就是上層的一些服務能發下來，而後去統一調度。另一個就是流程的開發，咱們有一個不可缺乏的調度系統，這裏咱們使用的是 DAG 調度引擎，這樣咱們能夠把離線任務、實時任務、實時+離線、離線+函數接口的服務可以組合起來，來完成更復雜實時數據應用場景。

好比咱們如今作的實時排行榜，把實時計算任務下發到 Flink 後，同時會給 Flink 下發一個 URL，Flink 拿到 URL 後，它會把符合條件的數據都發送到 URL，這個 URL 其實就是函數服務，這些函數服務把數據，在 Redis 裏作排序，最終生成一個排行榜。

再往下的這個調度器，你能夠不斷地去橫向拓展，好比我能夠作 Storm 的調度器、Flink 的調度器、Spark 的調度器等等一系列。在這塊能夠造成本身算法庫，這個算法庫能夠根據場景去作，好比有些是 Flink 的 SQL 的分裝，也就是把 SQL 傳進來，它就可以計算和封裝的 Jar 包。另外好比一些簡單的數據出發、規則判斷也能夠去作，直接把算法庫分裝到這塊就行。

其實這塊和業務場景沒有直接關係的，但算法庫必定是和場景是有關係的，另外下層咱們會有寫文件通道，好比說一些 Jar 包的分發，這裏騰訊用的是 COS，可以去作一些數據的傳輸和 Jar 包的提交。

還有一個命令管道，它主要針對機器，好比提交 Flink 任務的時候必定是經過命令管道，而後在一臺機器去把 Jar 包拉下來，而後同時把任務提交到 Flink 集羣裏去。數據管道也是相似的一個做用。

■ 3）各類管理

另外還要將一個蠻重要的內容，右邊綠色這塊的運營監控、集羣管理、系統管理（用戶權限管理，業務管理，場景管理，菜單配置管理等等），還有消息中心、幫助文檔，這些都是配套的，整個系統不可缺乏的。

還有一部分是組件管理，包括大數據組件管理、函數管理、服務的二進制管理均可以在這裏可以作統一的管理。

數據資產，好比咱們經過 Flink 或者 Storm 可以生成的數據指標，它的計算邏輯的管理都在這裏面，包括咱們計算出來後，把這些指標打上標籤或者劃後，咱們也做爲數據資產。

還有一個最重要的是數據表的管理，咱們不管是 Flink 或 Storm，它的計算最終的落地點必定是經過一個數據表能算出來的。其餘都還好，數據報表，好比天天計算多少數據，成功計算多少，天天有多少任務在跑，新增多少任務，這些都在裏面能夠作，包括咱們版本的發佈變動。還有一個是外部管理端，這個根據業務場景去作就好了，等會演示咱們管理端的時候你們就能夠看到，其實咱們的菜單相對來講比較簡單，根據好比咱們的數據接入，從源頭把數據接入到 Kafka 或者 Pulsar 裏去。而後數據指標基於接入的數據表，進行數據指標的計算，好比一些特性的 Jar 包，它是多張表的數據混合計算，或者是加上的表的混合計算，等等一系列經過硬場景作的一些分裝。

咱們最終把這些作完後，全部的大數據都是經過對外的服務 API 暴露出去的，好比最終遊戲任務是否完成，用戶 ID 過來後咱們能看這個用戶的任務是否完成，這樣的一些應用場景能夠直接使用 API 去操做。

這是整個流程，講得比較細後面你們纔會更清晰。

2、實時大數據計算 OneData

一、數據開發流程

這是咱們總體的數據應用流程：

咱們的 Game Server 先把數據上傳到日誌 Server（數據接入部分），日誌 Server 再把數據轉到 Kafka 或者 Pulsar，就是消息隊列裏。

接進來後是數據表，數據表是描述，基於描述的表去開發指標、數據。好比咱們這裏一共有三類，一類是 SQL，另一類是咱們已經分裝好的框架，你能夠本身去填充它的個性代碼，而後就能夠在線完成 Flink 程序的編寫。

還有一種是本身全新的在本地把代碼寫好，再發到系統裏去調測。以前說了在大數據計算和數據接口必定要作解耦，咱們解耦的方式是存儲，存儲咱們用 Redis。它這種作法是把 Redis 和 SSD 盤可以結合起來，而後再加上 RockDB，就是 Redis 裏面它 hold 熱點數據，同時它把這些數據都經過這個 RockDB 落地到 SSD 盤裏去，因此它的讀寫性很是好，就是把整個磁盤做爲數據庫存儲，而不像普通的 Redis 同樣再大數據狀況下智能把內存做爲存儲對象。

在大數據把數據計算存儲進去後，後面的就簡單了，咱們提供查詢的服務有兩種，一種是計算的指標，點一下就能夠生成接口，咱們叫規則接口；而後咱們另一種，也提供特性化的存儲到介質裏，我能夠本身去定義他的 SQL 或者查詢方式，而後在數據進行加工處理，生成接口 。

還有一種方式，是咱們在 Flink 和 Storm 直接把數據配置咱們這邊的一個函數接口，好比我剛纔講的排行榜的方式，就給一個接口，他直接在 Flink 這邊處理完成以後，把數據吐到函數接口裏面，函數接口對這個數據進行二次處理。

這個是整個處理方式，因此咱們前面講的就是，基於 Flink 和 Storm 構建一個全面的、託管的、可配置化的大數據處理服務。主要消費的是 Kafka 的數據，Pulsar 如今在少許的使用。

這樣作就是咱們把數據的開發門檻下降，不須要不少人懂 Flink 或者 Storm，他只要會 SQL 或者一些簡單的邏輯函數編寫，那就能夠去完成大數據的開發。

二、數據計算統一

其實咱們以前在作的時候，有一些優化的過程，原來每個計算任務都是用 Jar 包去寫，寫完以後就是編輯、打包、開發、發佈。後來咱們劃分了三種場景，一種是 SQL 化，就是一些咱們能用 SQL 表示的咱們就儘可能分裝成 SQL，而後有一個 Jar 包能去執行這個提交的 SQL 就能夠了。

還有一種是在線的 WebIDE，是處理函數的邏輯，舉例子 Storm 裏能夠把 blot 和 spout 暴露出來，你把這兩函數寫完後，再把並行度提交就能夠運行。但這裏咱們具體實現的時候是基於 Flink 去作的。

另外一個是場景化的配置，咱們個性化的 Jar 包可以統一調度，根據調度邏輯去執行。

三、數據計算服務體系

這是咱們整個 OneData 計算體系的過程，支持三種，一種的自研的 SQL，一種是 Flink SQL，還有是 Jar 包。

咱們自研的 SQL 是怎麼存儲，最先是使用 Storm，但 StormSQL 的效率很是低，因此咱們根據 SQL Parser 作的 SQL 的分裝，咱們對 SQL 本身進行解析，本身造成函數，在 SQL 提交以後，咱們用這樣的方式直接把它編譯成 Java 的字節碼，再把字節碼扔到 Storm 裏去計算。

Flink 這塊咱們也繼承了這種方式，後面會講一下兩種方式有什麼區別。其實咱們自研 SQL 在靈活性上比 Flink SQL 要好一點。

這裏是作平臺化，不能說直接放一個 FlinkSQL 去跑，由於咱們想要在裏面統計整個業務邏輯的執行狀況，好比 SQL 處理的數據量，正確的和錯誤的，包括一些衰減，都是要作統計。

這是基本的過程，完了後咱們在上面造成的一些基本場景，好比實時統計的場景，PV，UV，用獨立的 Jar 包去算就好了，配置一下表就能夠去計算。另外實時指標的服務，好比殺人書，金幣的積累數，遊戲的場次，王者榮耀裏下路走的次數，這種數據均可以做爲實時指標。

還有一種是規則觸發服務，表裏的某個數據知足什麼條件時，觸發一個接口。還有通信實時排行榜和一些定製化的服務。

■ 1）自研 SQL

接下來講咱們自研 SQL 的過程，咱們早期爲了不像 Hive 同樣（函數棧調用），而咱們本身經過 SQL Paser 的語法抽象後，把它生成一段函數，就不須要這麼多的對帳調用。

這個是函數生成過程，最終生成的就是這樣一段代碼，它去作計算邏輯，一個函數完成，不須要函數棧的調用，這樣效率就會大大提高。咱們原來單核跑八萬，放在如今能夠跑二十多萬。

整個處理的時候，咱們把 SQL 編譯成字節碼，Flink 消費了數據後，把數據轉化成 SQL 可以執行的函數，就是 roll 的方式。而後把 Roll 整個數據傳到 class 裏去執行，最後輸出。

這種場景適合於，好比 FlinkSQL 它有狀態值，咱們要統計某個最大值的話，要一直把用戶的最大值 hold 到內存裏去。而咱們自研的 SQL 呢，本身寫的函數，它把數據藉助第三方存儲，好比剛纔說的 TRedis 存儲。每次只須要讀取和寫入數據便可，不須要作過多的內存的 hold。

當前作到狀態的實時落地，就算掛掉也能立馬起來接着去執行，因此超過 10G、100G 的數據計算，都不成問題，可是 FlinkSQL 若是要算的話，它的狀態值就一直要 hould 到內存裏去了，並且掛掉後只能用它的 check point 去恢復。

因此這是這兩種 SQL 的應用場景。

■ 2）SQL 化

另外 SQL 裏咱們還能夠作些其餘的事情。咱們的數據是持久化保存在存儲裏的，那存儲裏若是是同一張表，同一個緯度，好比咱們都是用 QQ，在這個緯度上咱們配置了兩個指標，那能不能一次算完？只消費一次把數據算完，而後存儲一次。

其實這種在大數據計算裏是不少的，目前在咱們在作的平臺化就能夠，好比一個是計算登陸次數，另外一個是計算最高等級，這兩個計算邏輯不同，可是消費的數據表是同樣的，而後聚合緯度也是同樣的，聚合關鍵字也是同樣。那這個數據就能夠進行一次消費，同時把數據計算出來同時去落地，大大減小了存儲和計算成本。

咱們如今整個遊戲裏面有一萬一千多個指標，就是計算出來的，存儲的緯度有兩千六百多，實際節省計算和存儲約有 60%以上。

兩個 SQL，甚至更多的 SQL，咱們一張表算十幾個指標很正常，原來要消費十幾回如今只須要一次就能夠算出來。並且這種狀況對用戶是無感知的。A 用戶在這張表上配了指標是 A 緯度，B 用戶在這張表上配了指標也是 A 緯度，那這兩個用戶的數據，咱們在底層計算的時候就消費一次計算兩次存儲一次，最終拿到的數據也是同樣的。

**■ 3）在線實時編程

**

• 無需搭建本地開發環境；
• 在線開發測試；
• 嚴格的輸入輸出管理；
• 標準化輸入和輸出；
• 一站式開發測試發佈監控。

再介紹下剛纔提到的在線實時編程，其實不少時候對開發者來講，搭建一個本地的 Flink 集羣作開發調測也是很是麻煩的，因此咱們如今就是提供一種測試環境，上層的代碼都是固定的，不能修改。好比數據已經消費過來了，進行數據的加工處理，最終往存儲裏去塞就能夠了。

經過這種方式，咱們能夠對簡單邏輯進行分裝，須要函數代碼，但比 SQL 複雜，比自動的 Jar 包開發要簡單一些，能夠在線寫代碼，寫完代碼直接提交和測試就能完成結果的輸出。並且這種的好處是，數據的上報邏輯，數據的統計邏輯，我都在這裏面分裝好了。只要管業務邏輯的開發就行了。

四、Flink 特性應用

• 時間特性：基於事件時間水印的監控，減小計算量，提升準確性；
• 異步化 IO：提升吞吐量，確保順序性和一致性。

咱們最先在 Storm 裏作的時候，數據產生的時間和數據進到消息隊列的時間，都是經過這種消息裏自帶的時間戳，每個消息都是要對比的。有了 Flink 以後，有了 watermark 這個機制以後，這一部分的計算就能夠減小了。

實際測試下來的效果也是比較理想的，咱們原來在 Storm 裏單核計算，大概是之前的 QPS，加上讀寫和處理性能，單核五個線程的狀況下。可是 Flink 的時候咱們能夠到一萬，還加上 Redis 存儲 IO 的開銷。

另外一個咱們原來數據想要從 Redis 裏取出來，再去算最大值最小值，完了算了再寫到 Redis 裏，這個都是同步去寫的，可是同步 IO 有一個問題就是性能不高。因此咱們如今在把它改爲異步 IO，可是異步 IO 也有個特色就是整個一條數據的處理必須是同步的，必須先從 Redis 裏把數據取出來，而後再把值計算完，再塞到裏面去，保證塞完後再處理下一個統一的數據。

咱們再作這樣的一些優化。Flink 這裏有些特性能夠保證咱們數據的一致性，並且提高效率。

五、統一大數據開發服務—服務案例

接着介紹下更多的案例，若是你們玩英雄聯盟的話，那這個任務系統就是咱們設計的，下次玩作這個任務的時候，你就能夠想起我。還有天龍八部、CF、王者榮耀 LBS 榮耀戰區（經過大數據實時計算+LBS 的數據排行）、王者榮耀的平常活動（實時數據+接口+規則計算）、有哪些好友是實時在線的，跟你匹配的。

3、數據接口服務 OneFun

一、數據應用的出口

下面介紹下函數，咱們原來在作的時候也是存在着一些問題，把數據存到存儲裏面，若是存儲直接開放出去，讓別人任意去使用的話，其實對存儲的壓力和管理程度都是頗有問題的。因此後來咱們採用了一種相似於 Fass 的的解決方式。咱們把存儲在裏面的元數據進行管理，完了以後接口再配置化的方式，你要使用我這個 DB，這個 DB 最大 QPS 多少，我就進行對比，容許你以後才能使用這個量。

好比我這個 DB 的最大 QPS 只有 10 萬，你要申請 11 萬，那我就給你申請不了，我就只能通知 DB 把這個 Redis 進行擴容，擴容後纔給你提供使用。因此這裏面牽扯到咱們的指標數據的元數據管理和接口之間的打通。

二、一體化函數執行引擎—OneFun

這個和剛纔 OneData 的方式是同樣的，好比這塊提供了快速的函數，還有一些在線函數編程的方式的接口，你能夠在上面寫一點 JavaScript 或者 Golang 代碼，而後就生成接口，接口裏面能夠直接對外提供服務，把他造成產品化的包裝，在上層根據接口衍生出更多其餘的一些應用系統。

三、基於 ssa 的在線 Golang 函數執行引擎

這裏重點介紹下 Golang，其實咱們是基於 Golang 語言自己 ssa 的特色去作的，咱們有一個執行器，這個執行器已經寫好的，它的做用就是能夠把你寫的 Golang 代碼提交過來，加載到它的執行器裏。

而且咱們能夠把咱們寫的代碼做爲函數庫，積累下來而後放進去，它能夠在執行的時候去調用這些函數庫，而這裏面寫的代碼語法和 Golang 是徹底同樣的。

同時咱們在這裏面執行的時候，指定了一個協程，每個協程咱們規定它的做用域，就是以沙箱機制的方式來去執行，最早實現的就是外部 context 去實現的，咱們就能夠實現 Web 化的 Golang 開發，這種有點像 Lua 那種腳本語言同樣，你在線寫完語言直接提交執行。

四、基於 V8 引擎的在線函數服務引擎

這是咱們的 Javascript 的執行引擎，咱們主要是作了 V8 引擎的池子，全部 Javascript 寫完以後，丟到 V8 引擎上去執行，這應該你們都可以理解，若是你們玩過 JS 的能夠理解這種方式，就是 V8 引擎裏直接去執行。

五、一體化函數執行引擎--函數即服務

這是咱們的在線函數編寫過程：

右下角是咱們的函數代碼編寫區，寫完後左邊的黑框是點擊測試，輸出能夠在這裏寫，點擊測試就會把結果輸出出來，經過這種方式，咱們極大地擴張了咱們數據平臺的開發能力。原來是本地要把 Golang 代碼寫完，而後調試完再發到線上環境去測試，而如今咱們能夠很大的規範化，好比說數據源的引入，咱們就直接能夠在這裏去規定了，你只能引入申請過的數據源，你不能隨便亂引入數據源，包括你數據源引入的時候，QPS 放大我均可以經過這種方式知道。

• 下降啓動成本；
• 更快的部署流水線；
• 更快的開發速度；
• 系統安全性更高；
• 適應微服務架構；
• 自動擴展能力。

這個是咱們一站式，把函數開發完後，直接提交，咱們用 Prometheus + Grafana 能夠裏面看到實時報表。

六、案例介紹

這是一個典型的應用，Flink 裏面去計算的時候，他對這個數據進行過濾，完了以後進行一個遠程的 call，這個遠程調用執行函數代碼，大多數這種狀況就是一個開發就能夠完成大數據的開發和這個函數接口的開發，就能夠完成這樣一個活動的開發，整個活動開發的門檻就低了不少，真正實現了咱們 DevOps，就是開發可以把整個流程本身走完。

4、微服務化 & ServiceMesh

一、數據應用必走之路—微服務化

上面講的是 OneData 和 OneFun 的實現原理和機制，咱們在內部是怎麼去應用的，這套系統咱們在遊戲內部是大力推廣。

這裏尤爲是接口這塊，其實若是說要微服務化的話，大數據咱們能作的也就是那樣了，可以用 yarn 或者 K8S 去作資源的管控，和任務的管控，但真正去作服務治理仍是在接口這塊。目前咱們上下接口大概是三千五百個，每週新增 50 個接口。

因此咱們在作的時候也考慮到。原來咱們服務是一個個開發，可是沒有治理，如今咱們加上服務仍是一個個去開發，甚至有些服務咱們會把它變成一個服務，可是咱們加入了這個服務的治理。

好多人在提微服務，微服務若是沒有一個平臺去治理的話，將會是一種災難。因此微服務化給咱們帶來便利的同時，也會給咱們帶來一些問題，因此在咱們的場景裏面，微服務是很是好的，每個接口就能夠做爲一個服務，這種是自然的微服務。

二、一體化服務治理設計

可是這種微服務的治理將會是咱們很大的一個問題，因此咱們花了很大的精力去作了一個微服務的治理系統，從項目註冊的時候，他就把項目註冊的微服務中心，而且把 API 註冊上來，而後在服務發佈的時候，發到集羣裏的時候，這些服務都要主動的註冊到咱們的名冊服務，就是 Consoul。

但註冊到服務裏不是做爲服務路由來用的，而是到服務裏後，咱們在普羅米修斯這塊去作它的健康檢查和狀態採集，只要註冊上來，我立馬就能感知和把狀態採集過來，而後主要作實時報表和告警。

首先在服務的穩定性和健康度這塊咱們有一個保障，另一個就是服務的信息註冊到 Consul 裏去後，咱們有一個服務的網關，咱們用的是 envoy，其實內部咱們還把它做爲 SideCar 使用，後面會介紹。

註冊完了以後，envoy 會把這個全部的負載進信息加載到這塊來，它去作它服務的路由，同時咱們會把整個日誌上報到日誌中心去，包括網關的日誌也會上傳到日誌中心去，日誌中心再去作離線的報表和實時的一些報警監控。

因此這裏面咱們還加了一個基於 Consul 的一個配置，就是咱們包括 server 的實時控制均可以經過 Consul 去配置，配置完了後立馬可以 watch 到，而後去執行。

這個是基本的服務治理，但如今咱們的服務治理升級了，比這個要更好一點，基本的原理是這樣。

三、南北流量+東西流量的統一管控

而且咱們在這裏面實現了一個對 envoy 的管控，咱們說是服務治理，主要是對流量的一些治理，好比貧富負載策略，路由策略，熔斷，超時控制，故障注入等等一系列。

咱們是經過 Consul 的配置管理，經過它可以下發到咱們的 Agent，這個 Agent 再把這個數據可以經過 Istio 的接口和 K8s 的 API 可以下發到 envoy，這裏面就是 API GeteWay 和 SideCar 都是 envoy，因此咱們經過 Istio 對他的 XDS 的接口寫入，就能夠把全部的配置信息下發到這裏。

這套系統可以整個去管控整個集羣，南北流量和東西流量的統一管控。這套系統咱們將來準備開源，如今主要是內部在使用，並且這裏面咱們也作了圖形化的配置，全部 envoy 和 Istio 的配置咱們都通過 YAML 轉 Istio 再轉 UI 的方式，把它圖形化了，在這塊可以作統一的管控。

並且咱們把 Agent 開發完了以後就是多集羣的支持，就是多個 K8s 集羣只要加入進來，沒問題能夠去支持，咱們管理 API GeteWay。

還有一塊是 SideCar 的管理，就是 ServiceMash 裏的 SideCar 管理。咱們剛纔說的函數接口也好，規則接口也好，是一個 server。

固然這裏面還提到一個 chaos mesh 的功能，咱們如今還在研究，咱們準備在這套系統裏把它實現了。

四、基於 ServiceMesh 的全鏈路流量分析

這是一個咱們經過 ServiceMesh 作的分析，咱們雖然能夠宏觀地看出來咱們接口對 DB 的壓力有多大，但實際上咱們把流量導進來是咱們對壓力的監控是不夠的，因此這種狀況咱們經過 ServiceMesh，他對出口流量和進口流量的管控，而後能夠把流量進行詳細的統計，統計完後能夠生成一個快照，此次快照和下次快照之間的數據對比，入流量有多少的時候，對下面各個流量壓力有多少。

這是整個展現圖，咱們有多個測試用例，這兩個測試用例之間咱們能夠算出來對下游的壓力的流量分析，後期對下游壓力的分析和下游資源的擴容、縮容都有很是大的價值。

五、案例介紹

最後再介紹下咱們目前用這套系統實現的一些案例，大數據的遊戲迴歸，好比作一個遊戲數據的回顧 （生涯回顧）、任務系統、排行榜。

Q & A

Q1：ServiceMesh 是怎麼部署的？主要用來解決什麼問題？

目前咱們在使用的 ServiceMesh 技術實現是 Istio，版本是 1.3.6。這個版本還不支持物理機方式部署，因此咱們是在 K8s 中部署使用，部署方式有 2 種，能夠是直接使用 istioctl 命令安裝，或者是生成 Yaml 文件後使用 kubectl 進行安裝。

Servicemesh 的架構主要解決的問題是集羣內東西流量的治理問題。同時 Servicemesh 的 Sidercar 做爲協議代理服務和能夠屏蔽後面的服務開發技術棧， Sidercar 後面的服務能夠是各類語言開發，可是流量的管理和路由能夠有統一的管控。

Q2：微服務治理架構能介紹一下嗎？

微服務治理架構在我看來能夠分爲兩類：

• 服務實例的治理，這個在目前的 K8s 架構下，基本都是由 K8s 來管理了，包含了服務實例的發佈，升級，闊所容，服務註冊發現等等；
• 服務流量的治理，這一個你們一般說的服務治理，目前主要是由微服務網關和服務網格兩種技術來實現。服務網關實現集羣內和集羣外的流量治理，服務網格實現了集羣內的流量治理。

Q3：開發人員主要具備什麼樣的技術背景？

針對大數據開發人員，要使用咱們這套系統只須要會 SQL 語句和基本統計知識就能夠了。

針對應用接口開發人員，要使用咱們這套系統只須要會 JavaScript 或者 Golang，會基本的正則表達式，瞭解 HTTP 協議，會調試 HTTP 的 API 接口就能夠了。

Q4：實時計算，Flink 與 Spark 選擇上有沒啥建議？

Spark 在 15，16 年的時候咱們也在大規模使用，也在實時計算中使用過，可是當時的版本在實時計算上仍是比較弱，在 500ms 的批處理中仍是會出現數據堆積，因此在實時性上會有必定的問題，Spark 擅長在數據迭代計算和算法計算中。可是若是實時性要求不高並且有算法要求的場景中 Spark 仍是不錯的選擇。

Flink 在設計之初就是一種流失處理模型，因此在針對實時性要求較高的場景中 Flink 仍是比較合適的，在咱們內部測試發現 Flink 的流失計算吞吐確實要比 Storm 好不少，比 Spark 也是好不少，並且 Flink 目前的窗口機制針對實時計算中的窗口計算很是好用。因此通常實時計算或者對實時性要求較高的場景 Flink 仍是比較推薦的。

Q5：遊戲回放數據服務端存儲場景有麼？

這種場景也是有的，遊戲回放通常有 2 種方式，一種是錄屏傳輸回放，這種成本很是高，可是簡單且及時性比較好，另一種是控制指令發回 Server，在另外的服務中去恢復當時的場景，這種方式在成本相對較小，可是使用複雜。

Q6：回放場景下客戶端走什麼協議將數據發送到服務端？

通常是遊戲的私有協議。