游戲案例｜Service Mesh 在歡樂游戲的應用演變和實踐

作者

陳智偉，騰訊 12 級后臺專家工程師，現負責歡樂游戲作業室公共后臺技術研發以及團隊管理作業，在微服務分布式架構以及游戲后臺運維研發有豐富的經驗，

前言

歡樂游戲作業室后臺是分布式微服務架構，目前穩定承載著多款游戲，數千萬 DAU 以及數百萬級在線，原有云下架構脫胎于 QQGame 后臺，核心架構已有 10 多年的歷史，其中使用了多套目的不同的自研開發框架，自研基礎組件，并為適應繁雜的業務場景，衍生出不同的服務模型，最侄訓累了數百個微服務，整體簡化架構如下所示：

在這種大規模平臺化的后臺系統和復雜多樣的業務架構下，還要持續創造更大的業務價值，這給團隊帶來了較大的挑戰和壓力，簡單列舉幾個問題：

• 機器資源利用率極低，集群內 CPU 峰值平均利用率不足 20%；
• 服務治理能力不足，由于存在多套研發框架且服務管理方式不同，導致整體業務的維護以及基礎服務治理能力的研發成本較高；
• 服務部署十分繁瑣，自動化不足，耗時耗力，且容易出外網問題；
• 大量的陳舊業務服務缺乏維護，陳舊服務可視化能力不足，質量不易保證；
• 整體架構較為復雜，新人上手成本較高，可維護性不足；
• 每年機房裁撤都要耗費較大人力成本；

在云原生時代，借著公司全面“擁抱云原生”的東風，我們深度結合 K8s 以及 Istio 能力，逐模塊拆分，細致梳理，經歷過各類有狀態、無狀態服務的上云，協議改造，框架改造適配，服務模型云原生化，資料遷移，完善云上周邊服務組件，建立云上服務 DevOps 流程等等眾多系統性工程改造，最終，在不停服、平滑兼容過渡的前提下，將整體架構的服務云化以及網格化，

在整體架構上云技術方案選型上，我們權衡了各類方案的完備性、可擴展性以及改造維護成本等因素，最終選擇使用 Istio 服務網格作為整體上云的技術方案，

接下來，我將按照原有架構演進的線路，簡單介紹部分模塊的上云方案，

研發框架以及架構升級，實作低成本無感平滑演進至服務網格

為了接入 Istio 以及服務能夠平滑過渡，在基礎框架和架構上做了較多適配性調整，最終可以實作：

1. 存量業務代碼無需調整，重編即可支持 gRPC 協議;
2. 網格服務之間呼叫，使用 gRPC 通信；
3. 云下服務呼叫網格服務，既可以使用私有協議也可以使用 gRPC 協議；
4. 網格服務呼叫云下服務，使用 gRPC 協議；
5. 舊業務可平滑灰度遷移至網格內；
6. 兼容 Client 側的私有協議請求；

接下來，對其中部分內容做簡要說明，

原有架構引入 gRPC

考慮到需要更全面應用 Istio 的服務治理能力，我們在已有開發框架中引入了 gRPC 協議堆疊，同時為了兼容原有的私有協議的通信能力，使用 gRPC 包裝私有協議，并在開發框架層以及架構層都做了兼容性處理，開發框架結構示意圖如下所示：

使用 MeshGate 橋接網格以及云下服務

為了使得云上 Istio 中的服務，能夠與云下服務互通，我們研發了 MeshGate 服務橋接云上網格以及云下服務，

MeshGate 主要功能是實作服務在網格內外的雙邊代理注冊，并實作 gRPC 與私有協議之間的互轉適配，架構如下圖所示：

架構演變

基于業務重編支持 gRPC 能力，以及網格內外服務兼容性的打通，我們就可以實作新舊業務無感平滑的遷移上云了，

當然在遷移程序中，我們也并非一味無腦的容器化上云，會對各類服務做針對性的云原生化處理以及服務質量加固，并提高服務的可觀測性，最終提升服務的可維護性以及資源利用率，

服務上云之后，其資源配置粒度變為 Pod 級別，并支持自動伸縮能力，因此無需為具體的服務預留過多資源，絕大部分服務都可以共用 Node 資源，進而可以大幅提高機器資源的利用率，整體的資源使用降幅可達 60-70% 左右，

除了機器資源的減少好處之外，服務使用 helm 宣告式一鍵部署模式，從而 K8s 可以較好地維持服務的可用性，同時架構也獲得了 Istio 強大的服務治理能力，最終極好地提升了業務的 DevOps 效能，

整體架構的演變如下圖所示：

但心細的同學可能會發現，服務上了網格之后，業務和 Client 側的通信需要從自研接入集群 Lotus 轉發至 MeshGate，并做多次的協議轉換以及轉發，導致通信鏈路的性能開銷以及時延加大，而對于游戲中時延敏感的業務場景，其中時延的損失，是難以接受的，因此我們迫切需要一個網格內的網關接入服務，接下來就介紹一下網關接入的改造方案，

網格內私有協議的接入服務

原有云下的自研接入集群 Lotus，是基于私有協議的 TCP 長鏈接的 Client 側接入服務，具備服務注冊，大規模用戶鏈接管理，通信鑒權，加解密，轉發等等能力，

除了前述服務遷移至網格后，導致通信效果損耗之外，還存在一些其他問題：

1. Lotus 集群的運維十分繁瑣；因為為了防止用戶游戲程序中出現鏈接的斷開導致的不好體驗，Lotus 行程的停止，需要等待用戶側主動斷開，而新鏈接則不會發送給待停的 Lotus 中，簡而言之，Lotus 的停止需要排空已有長鏈接，這也導致 Lotus 的更新需要等待較長的時間，我們有統計過，每次全網跟新發布 Lotus 版本需要持續數天的時間，而遇到問題、裁撤或者新增節點時，其變更需要人工調整全網配置策略，且需要執行十多項步驟，整體效率較低，

2. Lotus 集群的資源利用率低；由于 Lotus 是最基礎的服務，且部署不方便，因此為了應對業務流量的變化，就要預留出充足的機器資源，但這也導致了 Lotus 的資源利用率較低，日常 CPU 峰殖澩利用率僅 25% 左右；

為此，我們基于 CNCF 旗下的開源專案 Envoy 的基礎之上，支持私有協議的轉發，并對接 Istio 控制面，使之適配我們原有的業務模型，并實作私有通信鑒權，加解密，客戶端鏈接管理等等能力，最終完成接入服上云的作業，整體技術框架如下圖所示：

改造完畢之后，云上接入集群在各方面都獲得了較好的提升，

1. 核心業務場景下的私有協議轉發性能以及延遲開銷與云下環境接近；
   針對核心的業務場景，我們做過相應的壓力測驗，Envoy 在支持私有協議之后，其接入轉發的性能開銷以及時延與云下直連屬于同一個量級，其中測驗時延，如下表所示：

   場景	平均耗時	P95 耗時
   云下直連	0.38ms	0.67ms
   K8s pod 間轉發	0.52ms	0.90ms
   Istio + TCP 轉發(私有協議)	0.62ms	1.26ms
   Istio + gRPC 轉發	6.23ms	14.62ms

2. 天然支持 Istio 的服務治理能力，更貼近云原生 Istio 下的使用方式；

3. 通過 Helm 部署以及定義 Controller 管理，實作一鍵服務上架以及滾動更新；整個升級是自動的，且程序中實作排空更新能力，并考慮會負載能力，排空效率更優，

4. 由于支持自動伸縮能力，接入服務無需預留過多的資源，因此可以大幅降低資源開銷；全量云化后接入集群的 CPU 節省 50%-60%，記憶體節省了近 70% 左右，

架構演變

有了云上接入集群，整體架構演變如上圖所示，接下來再以游戲業務中的 GameSvr 作為游戲強狀態服務的代表，簡單介紹其上云方案，

GameSvr 上云

歡樂作業室以往大都是單局房間類的游戲（注：目前已經遠不止這些了，也有 MMO，大世界，SLG 等等各種游戲品類），云下 GameSvr 架構如下圖所示：

但以上架構在云下存在一些問題：

1. 運維繁瑣；單臺 GameSvr 上下架需十余步人工操作，每年不停服機器裁撤需要耗費數周的人力，且容易發生事故；
2. 資源利用率低；同樣因為擴縮不易，就需預留足夠的資源，做冗余部署，導致高峰期 CPU 利用率僅 20% 左右；
3. 整體的容災能力弱，宕機后需人工介入處理；
4. 對局調度不靈活，都是依靠人工配置靜態策略；

因此借助云原生的能力，我們打造了一套易伸縮、易維護和高可用的單局類 GameSvr 架構，如下圖所示：

在整個遷移上云的程序中，我們是不停服，不變更前端，用戶無感地平滑過渡至云上網格 GameSvr 集群，最終實作了：

1. 資源利用率上獲得大幅提升；整體 CPU 以及記憶體的使用都減少了近 2/3，

2. 運維效率獲大幅提升；通過自定義 CRD 和 Controller 的管理，實作 Helm 一鍵部署整個集群，上下架十分便捷，僅一個業務專案組每個月因發布 GameSvr 都可以有效節省人力近 10 人天；

3. GameSvr 可根據當前集群的負載壓力變化以及歷史負載壓力的時間序列實作可靠自動伸縮；

4. 實作了靈活可靠的單局調度能力；通過簡單的配置，即可實作單局根據不同的屬性，調度到不同的 Set 中，且在調度的程序中，也會考慮負載和服務質量，最終實作整體調度的較優選擇，

架構演變

GameSvr 上云之后，整體架構變遷如上圖所示，接下來再看 CGI 是如何上云的，

數量龐大的 CGI 上云

我們曾大規模使用 Apache 下的 CGI 作為運營類活動開發的框架，但原有 CGI 業務的一些現狀：

1. 業務種類較多，現網部署約 350 種 CGI 服務，且流量巨大；

2. CGI 同步阻塞的行程模型，導致其單行程的吞吐量極低；大部分 CGI 業務的 QPS 僅個位數，且存在 Apache 的服務調度以及訊息分發的性能開銷；

3. CGI 之間的資源隔離性差；因為 CGI 是同機多行程部署，極易出現由于某個業務 CGI 突然資源開銷暴增，影響其他業務 CGI 的情況；

面對數量龐大且性能低效的 CGI 的上云，則需要研發成本以及資源開銷都低的上云方案，一開始我們嘗試過將 Apache 以及 CGI 整體打包成一個鏡像簡單容器化上云，但發現資源開銷和部署模型都十分不理想，因此需要更優雅的上云方案，

接著，我們對 CGI 的流量分布進行分析，發現 90% 的業務流量主要集中在 5% 的 CGI 中，如下圖所示，

因此，我們針對不同流量的 CGI，做了一些區分改造上云，

1. 針對頭部流量 CGI 進行協程異步化改造，剝離 Apache，使框架性能獲數十倍提升，

   • 在框架層實作監聽 http 請求以及異步化：

     • 使用 http-parser 改造，使的框架自身就支持 http 監聽以及處理；
     • 基于 libco 改造，使框架底層支持協程，從而實作異步化；

   • 在業務層，也需要針對性做各類適配性處理：

     • 針對全域變數，進行私有化或者關聯至協程物件管理；
     • 后端網路、io、配置加載以及記憶體等資源做各類復用化優化，提升效率；

     最終業務側做較小的調整，即可協程異步化改造完，但即使改造成本再低，已有的 CGI 數量還是太多了，全量異步化改造性價比十分低，

2. 針對剩余長尾流量 CGI，與 Apache 一并打包，使用腳本一次性搬遷上云，為了提升可觀測性，還對這種單容器內，超多行程的 metrics 采集 export 做了特殊處理，

最后在上云程序中，充分利用 Apache 的轉發機制，實作灰度可回滾上云，
上云后，CGI 的整體資源利用率以及可維護性均獲大幅提升，全量云化之后 CPU 可節省近 85% 的核數，記憶體可節省 70% 左右，

架構演變

搬遷完 CGI 之后，整體架構如上圖所示，接下來介紹一下自研存盤 CubeDB 的改造方案，

自研存盤業務遷移

我們云下有具有數十 T 的自研存盤資料，自建數百張 MySQL 表，整體的維護成本較高，且上云困難，因此我們的解決方案是“專業的事交給專業的人做”，將存盤遷移托管至 TcaplusDB（騰訊 IEG 自研公共存盤服務），整體的遷移步驟簡要描述如下：

1. 研發了適配代理服務，即上圖所示的 Cube2TcaplusProxy，將 CubeDB 私有協議適配轉換至 TcaplusDB，那么新業務的存盤就可以直接使用 TcaplusDB 了；

2. 在 CubeDB 的備機同步業務的熱資料，在開啟同步之后，TcaplusDB 就有業務的最新資料；

3. 將冷資料匯入至 TcaplusDB，如果 TcaplusDB 中有記錄資料，說明它是最新的，則不覆寫；

4. 全量比對 MySQL 與 TcaplusDB 的資料，多次校驗全量通過后則切換 Proxy 的路由；

最終通過這種方案，我們實作 DB 存盤的無損平滑遷移，

架構演變

我們自研存盤服務改造完畢之后，絕大部分服務均可以上云了，同時我們還做了很多云上周邊能力的建設和應用，例如云上統一配置中心，grafana as code，promethues，日志中心，染色呼叫鏈等等能力，

最終架構演變為：

多集群的部署模式

在云下，我們是一個全區全服的架構，所有的游戲業務都在一個集群之中，但由于我們組織架構以及業務形態的原因，期望上云之后，不同的業務團隊作業在不同的業務 K8s 集群，而對于大家共用的服務，則放到公共集群下管理，因此在遷移上云的程序中，則還需要做更多的適配遷移作業，

在 Istio 層面，由于我們的 Istio 服務托管給 TCM 團隊（騰訊云服務網格 TCM），在 TCM 同學的大力支持下，結合我們目前的組織架構以及業務形態，實作 Istio 多集群下控制面資訊的互通，由此我們在多集群之間的互相呼叫，成本就很低了，如下是 TCM 相關的后臺架構：

總結

最終，我們在復雜的游戲業務架構下，經過細致分析和基于云原生技術的持續重構演進，深度結合 K8s 以及 Istio 的能力，最終實作游戲業務場景下架構平穩平滑的高質量上云以及網格化，擁有多框架多語言的微服務框架，自動化，服務發現，彈性伸縮，服務管控，流量調度治理，立體度量監控等等能力，并沉淀游戲各類業務場景上云經驗，對于業務模塊的可靠性、可觀測性、可維護性大幅提高，整體研運效率提升十分明顯，

歡樂游戲作業室旗下擁有歡樂斗地主，歡樂麻將，歡樂升級等數款國民棋牌類游戲，同時在研大世界，MMO，SLG 等多種品類游戲，現大量招聘研發、策劃以及美術等各類崗位，歡迎猛戳招聘鏈接，推薦或者投遞簡歷，

關于我們

更多關于云原生的案例和知識，可關注同名【騰訊云原生】公眾號~

福利：

①公眾號后臺回復【手冊】，可獲得《騰訊云原生路線圖手冊》&《騰訊云原生最佳實踐》~

②公眾號后臺回復【系列】，可獲得《15個系列100+篇超實用云原生原創干貨合集》，包含Kubernetes 降本增效、K8s 性能優化實踐、最佳實踐等系列，

③公眾號后臺回復【白皮書】，可獲得《騰訊云容器安全白皮書》&《降本之源-云原生成本管理白皮書v1.0》

【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

標籤：其他

上一篇：瀏覽器插件推薦-油猴腳本,讓你的瀏覽器擁有無限可能

下一篇：圖資料挖掘：社區檢測演算法（一）