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

前言

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

在這種大規(guī)模平臺化的后臺系統(tǒng)和復雜多樣的業(yè)務架構下，還要持續(xù)創(chuàng)造更大的業(yè)務價值，這給團隊帶來了較大的挑戰(zhàn)和壓力。

簡單列舉幾個問題：

·機器資源利用率極低，集群內(nèi)CPU峰值平均利用率不足20%；

·服務治理能力不足，由于存在多套研發(fā)框架且服務管理方式不同，導致整體業(yè)務的維護以及基礎服務治理能力的研發(fā)成本較高；

·服務部署十分繁瑣，自動化不足，耗時耗力，且容易出外網(wǎng)問題；

·大量的陳舊業(yè)務服務缺乏維護，陳舊服務可視化能力不足，質(zhì)量不易保證；

·整體架構較為復雜，新人上手成本較高，可維護性不足；

·每年機房裁撤都要耗費較大人力成本；

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

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

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

研發(fā)框架以及架構升級，實現(xiàn)低成本無感平滑演進至服務網(wǎng)格

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

1.存量業(yè)務代碼無需調(diào)整，重編即可支持gRPC協(xié)議;

2.網(wǎng)格服務之間調(diào)用，使用gRPC通信；

3.云下服務調(diào)用網(wǎng)格服務，既可以使用私有協(xié)議也可以使用gRPC協(xié)議；

4.網(wǎng)格服務調(diào)用云下服務，使用gRPC協(xié)議；

5.舊業(yè)務可平滑灰度遷移至網(wǎng)格內(nèi)；

6.兼容Client側的私有協(xié)議請求；

接下來，對其中部分內(nèi)容做簡要說明。

原有架構引入gRPC

考慮到需要更全面應用Istio的服務治理能力，我們在已有開發(fā)框架中引入了gRPC協(xié)議棧。同時為了兼容原有的私有協(xié)議的通信能力，使用gRPC包裝私有協(xié)議，并在開發(fā)框架層以及架構層都做了兼容性處理。

開發(fā)框架結構示意圖如下所示：

使用MeshGate橋接網(wǎng)格以及云下服務

為了使得云上Istio中的服務，能夠與云下服務互通，我們研發(fā)了MeshGate服務橋接云上網(wǎng)格以及云下服務。

MeshGate主要功能是實現(xiàn)服務在網(wǎng)格內(nèi)外的雙邊代理注冊，并實現(xiàn)gRPC與私有協(xié)議之間的互轉(zhuǎn)適配，架構如下圖所示：

架構演變

基于業(yè)務重編支持gRPC能力，以及網(wǎng)格內(nèi)外服務兼容性的打通，我們就可以實現(xiàn)新舊業(yè)務無感平滑的遷移上云了。

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

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

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

整體架構的演變?nèi)缦聢D所示：

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

網(wǎng)格內(nèi)私有協(xié)議的接入服務

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

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

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

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

為此，我們基于CNCF旗下的開源項目Envoy[3]的基礎之上，支持私有協(xié)議的轉(zhuǎn)發(fā)，并對接Istio控制面，使之適配我們原有的業(yè)務模型，并實現(xiàn)私有通信鑒權，加解密，客戶端鏈接管理等等能力，最終完成接入服上云的工作。

整體技術框架如下圖所示：

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

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

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

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

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

架構演變

有了云上接入集群，整體架構演變?nèi)缟蠄D所示。接下來再以游戲業(yè)務中的GameSvr作為游戲強狀態(tài)服務的代表，簡單介紹其上云方案。

GameSvr上云

歡樂工作室以往大都是單局房間類的游戲（注：目前已經(jīng)遠不止這些了，也有MMO，大世界，SLG等等各種游戲品類）。

云下GameSvr架構如下圖所示：

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

1.運維繁瑣；單臺GameSvr上下架需十余步人工操作，每年不停服機器裁撤需要耗費數(shù)周的人力，且容易發(fā)生事故；

2.資源利用率低；同樣因為擴縮不易，就需預留足夠的資源，做冗余部署，導致高峰期CPU利用率僅20%左右；

3.整體的容災能力弱，宕機后需人工介入處理；

4.對局調(diào)度不靈活，都是依靠人工配置靜態(tài)策略；

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

在整個遷移上云的過程中，我們是不停服，不變更前端，用戶無感地平滑過渡至云上網(wǎng)格GameSvr集群。最終實現(xiàn)了：

1.資源利用率上獲得大幅提升；整體CPU以及內(nèi)存的使用都減少了近2/3。

2.運維效率獲大幅提升；通過自定義CRD和Controller的管理，實現(xiàn)Helm一鍵部署整個集群，上下架十分便捷，僅一個業(yè)務項目組每個月因發(fā)布GameSvr都可以有效節(jié)省人力近10人天；

3.GameSvr可根據(jù)當前集群的負載壓力變化以及歷史負載壓力的時間序列實現(xiàn)可靠自動伸縮；

4.實現(xiàn)了靈活可靠的單局調(diào)度能力；通過簡單的配置，即可實現(xiàn)單局根據(jù)不同的屬性，調(diào)度到不同的Set中。且在調(diào)度的過程中，也會考慮負載和服務質(zhì)量，最終實現(xiàn)整體調(diào)度的較優(yōu)選擇。

架構演變

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

數(shù)量龐大的CGI上云

我們曾大規(guī)模使用Apache下的CGI作為運營類活動開發(fā)的框架。但原有CGI業(yè)務的一些現(xiàn)狀：

1.業(yè)務種類較多，現(xiàn)網(wǎng)部署約350種CGI服務，且流量巨大；

2.CGI同步阻塞的進程模型，導致其單進程的吞吐量極低；大部分CGI業(yè)務的QPS僅個位數(shù)，且存在Apache的服務調(diào)度以及消息分發(fā)的性能開銷；

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

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

接著，我們對CGI的流量分布進行分析，發(fā)現(xiàn)90%的業(yè)務流量主要集中在5%的CGI中，如下圖所示。

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

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

·在框架層實現(xiàn)監(jiān)聽http請求以及異步化：

-使用http-parser[4]改造，使得框架自身就支持http監(jiān)聽以及處理；

-基于libco[5]改造，使框架底層支持協(xié)程，從而實現(xiàn)異步化；

·在業(yè)務層，也需要針對性做各類適配性處理：

-針對全局變量，進行私有化或者關聯(lián)至協(xié)程對象管理；

-后端網(wǎng)絡、io、配置加載以及內(nèi)存等資源做各類復用化優(yōu)化，提升效率；

最終業(yè)務側做較小的調(diào)整，即可協(xié)程異步化改造完。但即使改造成本再低，已有的CGI數(shù)量還是太多了，全量異步化改造性價比十分低。

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

最后在上云過程中，充分利用Apache的轉(zhuǎn)發(fā)機制，實現(xiàn)灰度可回滾上云。

上云后，CGI的整體資源利用率以及可維護性均獲大幅提升。全量云化之后CPU可節(jié)省近85%的核數(shù)，內(nèi)存可節(jié)省70%左右。

架構演變

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

自研存儲業(yè)務遷移

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

1.研發(fā)了適配代理服務，即上圖所示的Cube2TcaplusProxy，將CubeDB私有協(xié)議適配轉(zhuǎn)換至TcaplusDB，那么新業(yè)務的存儲就可以直接使用TcaplusDB了；

2.在CubeDB的備機同步業(yè)務的熱數(shù)據(jù)，在開啟同步之后，TcaplusDB就有業(yè)務的最新數(shù)據(jù)；

3.將冷數(shù)據(jù)導入至TcaplusDB，如果TcaplusDB中有記錄數(shù)據(jù)，說明它是最新的，則不覆蓋；

4.全量比對MySQL與TcaplusDB的數(shù)據(jù)，多次校驗全量通過后則切換Proxy的路由；

最終通過這種方案，我們實現(xiàn)DB存儲的無損平滑遷移。

架構演變

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

最終架構演變?yōu)椋?/p>

多集群的部署模式

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

在Istio層面，由于我們的Istio服務托管給TCM團隊（騰訊云服務網(wǎng)格TCM[6]），在TCM同學的大力支持下，結合我們目前的組織架構以及業(yè)務形態(tài)，實現(xiàn)Istio多集群下控制面信息的互通，由此我們在多集群之間的互相調(diào)用，成本就很低了。如下是TCM相關的后臺架構：

總結

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

參考資料

[1]Istio:【https://istio.io/latest/about/service-mesh/】

[2]服務治理能力:【https://istio.io/latest/about/service-mesh/】

[3]Envoy:【https://www.envoyproxy.io/】

[4]http-parser:【https://github.com/nodejs/http-parser】

[5]libco:【https://github.com/Tencent/libco】

[6]騰訊云服務網(wǎng)格TCM:【https://cloud.tencent.com/product/tcm】

歡樂游戲工作室旗下?lián)碛袣g樂斗地主，歡樂麻將，歡樂升級等數(shù)款國民棋牌類游戲，同時在研大世界，MMO，SLG等多種品類游戲。