作者
陳智偉，騰訊 12 級後臺專家工程師，現負責歡樂遊戲工作室公共後臺技術研發以及團隊管理工作。在微服務分散式架構以及遊戲後臺運維研發有豐富的經驗。
前言
歡樂遊戲工作室後臺是分散式微服務架構，目前穩定承載著多款遊戲，數千萬 DAU 以及數百萬級線上。原有云下架構脫胎於 QQGame 後臺，核心架構已有 10 多年的歷史，其中使用了多套目的不同的自研開發框架，自研基礎元件，併為適應繁雜的業務場景，衍生出不同的服務模型，最終積累了數百個微服務，整體簡化架構如下所示：
在這種大規模平臺化的後臺系統和複雜多樣的業務架構下，還要持續創造更大的業務價值，這給團隊帶來了較大的挑戰和壓力。簡單列舉幾個問題：
- 機器資源利用率極低，叢集內 CPU 峰值平均利用率不足 20%；
- 服務治理能力不足，由於存在多套研發框架且服務管理方式不同，導致整體業務的維護以及基礎服務治理能力的研發成本較高；
- 服務部署十分繁瑣，自動化不足，耗時耗力，且容易出外網問題；
- 大量的陳舊業務服務缺乏維護，陳舊服務視覺化能力不足，質量不易保證；
- 整體架構較為複雜，新人上手成本較高，可維護性不足；
- 每年機房裁撤都要耗費較大人力成本；
在雲原生時代，藉著公司全面“擁抱雲原生”的東風，我們深度結合 K8s 以及 Istio 能力，逐模組拆分，細緻梳理，經歷過各類有狀態、無狀態服務的上雲，協議改造，框架改造適配，服務模型雲原生化，資料遷移，完善雲上週邊服務元件，建立雲上服務 DevOps 流程等等眾多系統性工程改造。最終，在不停服、平滑相容過渡的前提下，將整體架構的服務雲化以及網格化。
在整體架構上雲技術方案選型上，我們權衡了各類方案的完備性、可擴充套件性以及改造維護成本等因素，最終選擇使用 Istio 服務網格作為整體上雲的技術方案。
接下來，我將按照原有架構演進的線路，簡單介紹部分模組的上雲方案。
研發框架以及架構升級，實現低成本無感平滑演進至服務網格
為了接入 Istio 以及服務能夠平滑過渡，在基礎框架和架構上做了較多適配性調整，最終可以實現：
- 存量業務程式碼無需調整，重編即可支援 gRPC 協議;
- 網格服務之間呼叫，使用 gRPC 通訊；
- 雲下服務呼叫網格服務，既可以使用私有協議也可以使用 gRPC 協議；
- 網格服務呼叫雲下服務，使用 gRPC 協議；
- 舊業務可平滑灰度遷移至網格內；
- 相容 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 側接入服務，具備服務註冊，大規模使用者連結管理，通訊鑑權，加解密，轉發等等能力。
除了前述服務遷移至網格後，導致通訊效果損耗之外，還存在一些其他問題：
-
Lotus 叢集的運維十分繁瑣；因為為了防止使用者遊戲過程中出現連結的斷開導致的不好體驗，Lotus 程式的停止，需要等待使用者側主動斷開，而新連結則不會傳送給待停的 Lotus 中，簡而言之，Lotus 的停止需要排空已有長連結，這也導致 Lotus 的更新需要等待較長的時間。我們有統計過，每次全網跟新發布 Lotus 版本需要持續數天的時間。而遇到問題、裁撤或者新增節點時，其變更需要人工調整全網配置策略，且需要執行十多項步驟，整體效率較低。
-
Lotus 叢集的資源利用率低；由於 Lotus 是最基礎的服務，且部署不方便，因此為了應對業務流量的變化，就要預留出充足的機器資源。但這也導致了 Lotus 的資源利用率較低，日常 CPU 峰值資源利用率僅 25% 左右；
為此，我們基於 CNCF 旗下的開源專案 Envoy 的基礎之上，支援私有協議的轉發，並對接 Istio 控制面，使之適配我們原有的業務模型，並實現私有通訊鑑權，加解密，客戶端連結管理等等能力，最終完成接入服上雲的工作。整體技術框架如下圖所示：
改造完畢之後，雲上接入叢集在各方面都獲得了較好的提升。
-
核心業務場景下的私有協議轉發效能以及延遲開銷與雲下環境接近；
針對核心的業務場景，我們做過相應的壓力測試，Envoy 在支援私有協議之後，其接入轉發的效能開銷以及時延與雲下直連屬於同一個量級。其中測試時延，如下表所示：場景 平均耗時 P95 耗時 雲下直連 0.38ms 0.67ms K8s pod 間轉發 0.52ms 0.90ms Istio + TCP 轉發(私有協議) 0.62ms 1.26ms Istio + gRPC 轉發 6.23ms 14.62ms -
天然支援 Istio 的服務治理能力，更貼近雲原生 Istio 下的使用方式；
-
通過 Helm 部署以及定義 Controller 管理，實現一鍵服務上架以及滾動更新；整個升級是自動的，且過程中實現排空更新能力，並考慮會負載能力，排空效率更優。
-
由於支援自動伸縮能力，接入服務無需預留過多的資源，因此可以大幅降低資源開銷；全量雲化後接入叢集的 CPU 節省 50%-60%，記憶體節省了近 70% 左右。
架構演變
有了雲上接入叢集，整體架構演變如上圖所示。接下來再以遊戲業務中的 GameSvr 作為遊戲強狀態服務的代表，簡單介紹其上雲方案。
GameSvr 上雲
歡樂工作室以往大都是單局房間類的遊戲（注：目前已經遠不止這些了，也有 MMO，大世界，SLG 等等各種遊戲品類）。雲下 GameSvr 架構如下圖所示：
但以上架構在雲下存在一些問題：
- 運維繁瑣；單臺 GameSvr 上下架需十餘步人工操作，每年不停服機器裁撤需要耗費數週的人力，且容易發生事故；
- 資源利用率低；同樣因為擴縮不易，就需預留足夠的資源，做冗餘部署，導致高峰期 CPU 利用率僅 20% 左右；
- 整體的容災能力弱，當機後需人工介入處理；
- 對局排程不靈活，都是依靠人工配置靜態策略；
因此藉助雲原生的能力，我們打造了一套易伸縮、易維護和高可用的單局類 GameSvr 架構。如下圖所示：
在整個遷移上雲的過程中，我們是不停服，不變更前端，使用者無感地平滑過渡至雲上網格 GameSvr 叢集。最終實現了：
-
資源利用率上獲得大幅提升；整體 CPU 以及記憶體的使用都減少了近 2/3。
-
運維效率獲大幅提升；通過自定義 CRD 和 Controller 的管理，實現 Helm 一鍵部署整個叢集，上下架十分便捷，僅一個業務專案組每個月因釋出 GameSvr 都可以有效節省人力近 10 人天；
-
GameSvr 可根據當前叢集的負載壓力變化以及歷史負載壓力的時間序列實現可靠自動伸縮；
-
實現了靈活可靠的單局排程能力；通過簡單的配置，即可實現單局根據不同的屬性，排程到不同的 Set 中。且在排程的過程中，也會考慮負載和服務質量，最終實現整體排程的較優選擇。
架構演變
GameSvr 上雲之後，整體架構變遷如上圖所示，接下來再看 CGI 是如何上雲的。
數量龐大的 CGI 上雲
我們曾大規模使用 Apache 下的 CGI 作為運營類活動開發的框架。但原有 CGI 業務的一些現狀：
-
業務種類較多，現網部署約 350 種 CGI 服務，且流量巨大；
-
CGI 同步阻塞的程式模型，導致其單程式的吞吐量極低；大部分 CGI 業務的 QPS 僅個位數，且存在 Apache 的服務排程以及訊息分發的效能開銷；
-
CGI 之間的資源隔離性差；因為 CGI 是同機多程式部署，極易出現由於某個業務 CGI 突然資源開銷暴增，影響其他業務 CGI 的情況；
面對數量龐大且效能低效的 CGI 的上雲，則需要研發成本以及資源開銷都低的上雲方案。一開始我們嘗試過將 Apache 以及 CGI 整體打包成一個映象簡單容器化上雲，但發現資源開銷和部署模型都十分不理想，因此需要更優雅的上雲方案。
接著，我們對 CGI 的流量分佈進行分析，發現 90% 的業務流量主要集中在 5% 的 CGI 中，如下圖所示。
因此，我們針對不同流量的 CGI，做了一些區分改造上雲。
-
針對頭部流量 CGI 進行協程非同步化改造，剝離 Apache，使框架效能獲數十倍提升。
-
在框架層實現監聽 http 請求以及非同步化：
- 使用 http-parser 改造，使的框架自身就支援 http 監聽以及處理；
- 基於 libco 改造，使框架底層支援協程，從而實現非同步化；
-
在業務層，也需要針對性做各類適配性處理：
- 針對全域性變數，進行私有化或者關聯至協程物件管理；
- 後端網路、io、配置載入以及記憶體等資源做各類複用化優化，提升效率；
最終業務側做較小的調整，即可協程非同步化改造完。但即使改造成本再低，已有的 CGI 數量還是太多了，全量非同步化改造價效比十分低。
-
-
針對剩餘長尾流量 CGI，與 Apache 一併打包，使用指令碼一次性搬遷上雲。為了提升可觀測性，還對這種單容器內，超多程式的 metrics 採集 export 做了特殊處理。
最後在上雲過程中，充分利用 Apache 的轉發機制，實現灰度可回滾上雲。
上雲後，CGI 的整體資源利用率以及可維護性均獲大幅提升。全量雲化之後 CPU 可節省近 85% 的核數，記憶體可節省 70% 左右。
架構演變
搬遷完 CGI 之後，整體架構如上圖所示。接下來介紹一下自研儲存 CubeDB 的改造方案。
自研儲存業務遷移
我們雲下有具有數十 T 的自研儲存資料，自建數百張 MySQL 表，整體的維護成本較高，且上雲困難。因此我們的解決方案是“專業的事交給專業的人做”，將儲存遷移託管至 TcaplusDB（騰訊 IEG 自研公共儲存服務）。整體的遷移步驟簡要描述如下：
-
研發了適配代理服務，即上圖所示的 Cube2TcaplusProxy，將 CubeDB 私有協議適配轉換至 TcaplusDB，那麼新業務的儲存就可以直接使用 TcaplusDB 了；
-
在 CubeDB 的備機同步業務的熱資料，在開啟同步之後，TcaplusDB 就有業務的最新資料；
-
將冷資料匯入至 TcaplusDB，如果 TcaplusDB 中有記錄資料，說明它是最新的，則不覆蓋；
-
全量比對 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》
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
