最佳案例 | 游戲知幾AI助手的云原生容器化之路

游戲知幾

隨著業(yè)務(wù)不斷的拓展，游戲知幾AI智能問(wèn)答機(jī)器人業(yè)務(wù)已經(jīng)覆蓋了自研游戲、二方、海外的多款游戲。游戲知幾研發(fā)團(tuán)隊(duì)主動(dòng)擁抱云原生，推動(dòng)后臺(tái)業(yè)務(wù)全量上云，服務(wù)累計(jì)核心1w+。

通過(guò)云上的容器化部署、自動(dòng)擴(kuò)縮容、健康檢查、可觀測(cè)性等手段，提高了知幾項(xiàng)目的持續(xù)交付能力和穩(wěn)定性，形成了一套適合游戲知幾自身的上云實(shí)踐方案。本文將會(huì)介紹游戲知幾項(xiàng)目中遇到的痛點(diǎn)以及探索出的一套可靠的上云實(shí)踐方案。

知幾項(xiàng)目背景

游戲知幾[1]是一款游戲智能AI產(chǎn)品和運(yùn)營(yíng)解決方案，它基于自然語(yǔ)言處理、知識(shí)圖譜、深度學(xué)習(xí)等前沿技術(shù)，為游戲玩家提供一站式服務(wù)，包括游戲內(nèi)外實(shí)時(shí)智能問(wèn)答、游戲語(yǔ)音陪伴、自助流水查詢(xún)、游戲內(nèi)外數(shù)據(jù)互通、主動(dòng)關(guān)懷防流失、產(chǎn)品合規(guī)保護(hù)等多種能力，目前已經(jīng)接入包括王者榮耀、和平精英、PUBG mobile、天刀手游等六星游戲在內(nèi)的80+款游戲，為海內(nèi)外數(shù)以?xún)|計(jì)的游戲用戶提供服務(wù)，獲得眾多游戲項(xiàng)目和廣大用戶的持續(xù)好評(píng)。

同時(shí)游戲知幾還提供了簡(jiǎn)便易用、性能良好的客戶端SDK和功能完備的運(yùn)營(yíng)平臺(tái)系統(tǒng)，支持模塊化接入，顯著降低了用戶運(yùn)營(yíng)中的人力成本，提升了玩家的交互體驗(yàn)。

隨著知幾業(yè)務(wù)的不斷發(fā)展，知幾的部署架構(gòu)也在不斷地演進(jìn)，逐步從最初的IDC部署架構(gòu)遷移到當(dāng)前的云原生部署架構(gòu)，實(shí)現(xiàn)了業(yè)務(wù)服務(wù)的全面上云。

上云前的知幾

docker部署方案

知幾在最初采用docker部署的方案來(lái)部署服務(wù)，服務(wù)的CI/CD通過(guò)夸克平臺(tái)實(shí)現(xiàn)，平臺(tái)將編譯打包好的服務(wù)推送到docker機(jī)進(jìn)行部署。為了實(shí)現(xiàn)機(jī)器的水平擴(kuò)容，運(yùn)維同學(xué)會(huì)將docker環(huán)境整體打包成基準(zhǔn)鏡像，包括IDC的機(jī)器環(huán)境所依賴(lài)的環(huán)境，比如CL5 agent，gse agent等。當(dāng)需要擴(kuò)容時(shí)，將基準(zhǔn)環(huán)境發(fā)布到擴(kuò)容機(jī)器上進(jìn)行擴(kuò)容操作。

知幾整體的部署架構(gòu)如下圖所示：

1.外部請(qǐng)求統(tǒng)一通過(guò)stgw接入，rs到后臺(tái)服務(wù)的vip上，通常會(huì)區(qū)分移動(dòng)、聯(lián)通、電信和小流量運(yùn)營(yíng)商；

2.vip下掛載的機(jī)器IP、端口通過(guò)tgw平臺(tái)配置，請(qǐng)求通過(guò)一定的負(fù)載均衡策略發(fā)送到IDC機(jī)器的后臺(tái)服務(wù)上；

3.服務(wù)的CI/CD通過(guò)夸克平臺(tái)操作，完成服務(wù)的編譯、打包、發(fā)布等操作，也支持操作回滾，進(jìn)程監(jiān)控等；

4.監(jiān)控告警、日志系統(tǒng)接入的是mo監(jiān)控平臺(tái)和駿鷹。

服務(wù)遇到的問(wèn)題

知幾項(xiàng)目會(huì)對(duì)接IEG下的眾多游戲，伴隨著游戲接入的增多，流量也變得越來(lái)越大，知幾項(xiàng)目的流量狀況有以下特點(diǎn)：

1.平時(shí)流量平穩(wěn)，節(jié)假日流量隨游戲流量增大，通常達(dá)到3倍以上；

2.主動(dòng)關(guān)懷類(lèi)的消息推送，運(yùn)營(yíng)活動(dòng)會(huì)通過(guò)知幾直接觸達(dá)給玩家，帶來(lái)可觀的突發(fā)流量，極端情況10倍以上；

因此，知幾對(duì)服務(wù)的穩(wěn)定性、可觀測(cè)性以及服務(wù)治理的能力有很高的要求，需保證項(xiàng)目在流量突發(fā)的情況下能夠正常運(yùn)行，故障時(shí)能及時(shí)發(fā)現(xiàn)。

在docker部署的架構(gòu)下，很難做到快速地自動(dòng)擴(kuò)縮容，主要問(wèn)題有以下幾個(gè)方面：

1.擴(kuò)容前的機(jī)器申請(qǐng)、環(huán)境準(zhǔn)備很耗時(shí)，突發(fā)流量的情況下這個(gè)準(zhǔn)備時(shí)間難以接受，提前準(zhǔn)備好機(jī)器平時(shí)又會(huì)造成資源的浪費(fèi)；

2.運(yùn)維制作的基準(zhǔn)鏡像通常不是最新的版本，需要發(fā)布最新版本才能擴(kuò)容；

3.依賴(lài)的權(quán)限（mysql等）需要申請(qǐng)；

4.平臺(tái)操作繁瑣，容易出錯(cuò)；

5.需要人工完成運(yùn)營(yíng)活動(dòng)后機(jī)器的縮容操作。

這些問(wèn)題都會(huì)造成服務(wù)在擴(kuò)容時(shí)的不及時(shí)，從而帶來(lái)服務(wù)穩(wěn)定性的隱患，同時(shí)也帶來(lái)了業(yè)務(wù)同學(xué)的運(yùn)維負(fù)擔(dān)。除此之外，每年一次的機(jī)器裁撤也很痛苦，涉及機(jī)器確認(rèn)、服務(wù)遷移、環(huán)境梳理等方方面面的操作。

因此，我們希望通過(guò)上云遷移，利用云原生的HPA能力來(lái)解決服務(wù)穩(wěn)定性、裁撤等問(wèn)題。

上云遷移

知幾云原生方案

針對(duì)以上問(wèn)題，當(dāng)前知幾實(shí)踐了一套基于云原生的多機(jī)房部署方案。具體方案如下：

·引入tapisix統(tǒng)一網(wǎng)關(guān)，借助限流等網(wǎng)關(guān)插件管理南北流量，stgw接入tapisix網(wǎng)關(guān)的ingress；

·服務(wù)分南京一區(qū)和南京二區(qū)進(jìn)行部署，各區(qū)服務(wù)通過(guò)ingress暴露外網(wǎng)流量，tapisix網(wǎng)關(guān)混連接入一區(qū)、二區(qū)服務(wù)的ingress；

·新增上海災(zāi)備集群，極端情況下可快速接入；

·CI/CD方面通過(guò)藍(lán)盾流水線實(shí)現(xiàn)，打包服務(wù)鏡像推送到鏡像倉(cāng)庫(kù)，在STKE上進(jìn)行部署。

基于上述的部署方案，利用云原生的自動(dòng)擴(kuò)縮容能力可以方便地解決上述問(wèn)題：

1.STKE提供的定時(shí)HPA和動(dòng)態(tài)擴(kuò)縮容能力，可以很好的解決節(jié)假日、運(yùn)營(yíng)活動(dòng)的流量突增帶來(lái)的服務(wù)穩(wěn)定性問(wèn)題，且流量平穩(wěn)后的自動(dòng)縮容可以有效的節(jié)約資源；

2.STKE提供自動(dòng)鑒權(quán)流程，可以解決依賴(lài)權(quán)限申請(qǐng)的問(wèn)題，通常鑒權(quán)流程的耗時(shí)在分鐘級(jí)；

3.引入tapsix統(tǒng)一網(wǎng)關(guān)，接入分區(qū)流量，可以對(duì)流量進(jìn)行快速切換，當(dāng)一個(gè)區(qū)的服務(wù)有問(wèn)題時(shí)，可以通過(guò)tapsix的路由快速切換到另外一個(gè)區(qū)；

遷移方案

知幾服務(wù)的上云遷移涉及外網(wǎng)和內(nèi)網(wǎng)的眾多服務(wù)，外網(wǎng)服務(wù)遷移的過(guò)程可通過(guò)運(yùn)營(yíng)商逐步對(duì)流量進(jìn)行灰度：

1.首先在stke集群新部署服務(wù)進(jìn)行測(cè)試，提供移動(dòng)、聯(lián)通、電信和CAP四類(lèi)公網(wǎng)CLB；

2.先灰度CAP小運(yùn)營(yíng)商流量，服務(wù)穩(wěn)定后再通過(guò)gslb逐步灰度其他運(yùn)營(yíng)商；

3.回滾則通過(guò)gslb快速切換回IDC服務(wù)的VIP；

內(nèi)網(wǎng)服務(wù)的遷移則通過(guò)STKE支持的北極星、CL5 serivce自動(dòng)將pod ip注入到老服務(wù)的負(fù)載均衡當(dāng)中，首先通過(guò)一個(gè)pod進(jìn)行灰度，再逐步增加pod完成放量，最后摘除IDC的機(jī)器即可。通過(guò)這種方式，我們?cè)谌齻€(gè)月內(nèi)完成了所有外網(wǎng)服務(wù)和后臺(tái)服務(wù)的全量上云，并保證了遷移的平穩(wěn)進(jìn)行。

上云實(shí)踐

標(biāo)準(zhǔn)化部署實(shí)踐

業(yè)務(wù)上云基礎(chǔ)的點(diǎn)就是考慮怎么做標(biāo)準(zhǔn)化的容器部署和彈性服務(wù)。知幾服務(wù)主要有三類(lèi)，業(yè)務(wù)服務(wù)通常是Go服務(wù)，算法服務(wù)為C++服務(wù)，需要考慮模型加載的問(wèn)題，平臺(tái)服務(wù)主要為PHP服務(wù)。在容器的標(biāo)準(zhǔn)化上，我們采用的是單容器模式，這樣做的好處是每個(gè)container間互不影響，進(jìn)程是作為容器的一號(hào)進(jìn)程存在，一旦有問(wèn)題k8s會(huì)自動(dòng)把服務(wù)拉起，另外也便于資源的復(fù)用。

富容器的模式是把所有的進(jìn)程都放在一個(gè)容器內(nèi)，這樣看似方便，能實(shí)現(xiàn)業(yè)務(wù)的無(wú)縫平滑的快速上云，但無(wú)論從未來(lái)的維護(hù)效率、安全還是健康檢查、服務(wù)彈性上看都有問(wèn)題，是中間態(tài)，違反了容器單一功能原則，也不符合云原生的理念。

·PHP的服務(wù)將nginx，pfp-fpm，業(yè)務(wù)代碼都打成了獨(dú)立的container，代碼通過(guò)文件共享的形式共享給php-fpm的container實(shí)現(xiàn)。

·Go服務(wù)較簡(jiǎn)單，采用常規(guī)的應(yīng)用container+sidecar的標(biāo)準(zhǔn)化容器。

·算法服務(wù)主要是模型，模型文件掛載到cephfs上，共享給C++服務(wù)的容器使用。

知幾在服務(wù)部署的過(guò)程中，積累了一些實(shí)踐經(jīng)驗(yàn)，通過(guò)云原生的對(duì)資源利用的優(yōu)勢(shì)，提升資源的利用率，降低運(yùn)營(yíng)成本。針對(duì)不同場(chǎng)景最小實(shí)例的配置如下：

·測(cè)試環(huán)境、預(yù)發(fā)布環(huán)境流量較少，統(tǒng)一0.1核0.25G，1實(shí)例。

·生產(chǎn)環(huán)境，業(yè)務(wù)后臺(tái)服務(wù)采用1核2G，2實(shí)例。

·生產(chǎn)環(huán)境，算法后臺(tái)服務(wù)采用8核16G（個(gè)別如在線推理服務(wù)會(huì)采用32核以上的機(jī)器）。

通過(guò)降低單pod的CPU，MEM request，滿足日常運(yùn)營(yíng)需求，流量高峰期則通過(guò)stke的HPA能力來(lái)滿足業(yè)務(wù)的需要，使日常CPU利用率能達(dá)到40%。由于HPA會(huì)導(dǎo)致業(yè)務(wù)容器的擴(kuò)縮容，如果流量在服務(wù)未完成啟動(dòng)時(shí)接入或者流量還在訪問(wèn)時(shí)接銷(xiāo)毀pod，會(huì)導(dǎo)致流量的損失，因此需要開(kāi)啟就緒檢測(cè)和prestop配置。

這里需要注意的是，就緒檢查的啟動(dòng)延時(shí)設(shè)置不宜過(guò)短，這樣系統(tǒng)會(huì)認(rèn)為pod啟動(dòng)失敗而不斷重啟，導(dǎo)致服務(wù)無(wú)法正常啟動(dòng)。

此外，stke提供的其他特性可以很好的滿足知幾的業(yè)務(wù)需求：

·提供鑒權(quán)流程，可以在pod拉起時(shí)，動(dòng)態(tài)的申請(qǐng)mysql等依賴(lài)的權(quán)限，規(guī)避繁瑣的權(quán)限申請(qǐng)流程。

·configmap可解決配置服務(wù)配置更新的問(wèn)題。

·可對(duì)內(nèi)核進(jìn)行調(diào)優(yōu)，業(yè)務(wù)可根據(jù)服務(wù)、流量的特點(diǎn)針對(duì)性地對(duì)內(nèi)核參數(shù)進(jìn)行優(yōu)化，如net.core.somaxconn,net.ipv4.tcp_tw_reuse等等。

當(dāng)前知幾在線上部署了超過(guò)1w核，支撐知幾Sdk，第五人等多個(gè)應(yīng)用服務(wù)，整體的利用率在40%左右。

HPA

STKE提供的HPA能力能夠很好的滿足知幾對(duì)擴(kuò)縮容的需求，知幾同時(shí)使用了定時(shí)HPA和動(dòng)態(tài)HAP滿足不同的場(chǎng)景：

·針對(duì)突發(fā)流量，知幾采用CPU request和內(nèi)存request作為觸發(fā)擴(kuò)容的條件。

·節(jié)假日和周五、六晚未成年人游戲上線，知幾采用周定時(shí)HPA提前擴(kuò)容。

這樣很大程度上減少了開(kāi)發(fā)、運(yùn)維同學(xué)面對(duì)運(yùn)營(yíng)活動(dòng)和突發(fā)流量時(shí)的心智負(fù)擔(dān)，提高了服務(wù)穩(wěn)定性。特別是定時(shí)HPA，可以很方便的滿足知幾在未成年人保護(hù)方面對(duì)擴(kuò)縮容的要求，系統(tǒng)可以在特定時(shí)間段完成系統(tǒng)容量的擴(kuò)容和縮容，在保證系統(tǒng)平穩(wěn)應(yīng)對(duì)流量的同時(shí)也不會(huì)造成對(duì)資源的浪費(fèi)。遷移上云后，知幾通過(guò)這種方式保證了周末時(shí)段和線上多場(chǎng)運(yùn)營(yíng)活動(dòng)的平穩(wěn)進(jìn)行。

可觀測(cè)性

系統(tǒng)的可觀測(cè)性能夠讓開(kāi)發(fā)同學(xué)根據(jù)系統(tǒng)輸出快速監(jiān)控、定位問(wèn)題?？捎^測(cè)性可以從Metrics、Log、Trace三個(gè)方面來(lái)看。

·Metrics，知幾服務(wù)大部分對(duì)接的是Monitor系統(tǒng)，通過(guò)自定義metircs上報(bào)實(shí)現(xiàn)模調(diào)信息、服務(wù)狀態(tài)、業(yè)務(wù)等指標(biāo)的監(jiān)控，知幾封裝了Monitor的標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)指標(biāo)模板的標(biāo)準(zhǔn)化和上報(bào)。Monitor上報(bào)需要通過(guò)http請(qǐng)求獲取上報(bào)的ip再將數(shù)據(jù)通過(guò)tcp形式發(fā)送到Monitor側(cè)，這種形式的上報(bào)對(duì)業(yè)務(wù)并不友好，Monitor當(dāng)前也已不再接入新的業(yè)務(wù)，目前知幾正逐步將Metrics遷移到智研監(jiān)控系統(tǒng)，trpc提供插件接入智研監(jiān)控能力。

·Log，早期知幾上云時(shí)采用的filebeat采集日志，現(xiàn)在stke提供了統(tǒng)一的日志數(shù)據(jù)解決方案CLS，可以方便的進(jìn)行日志采集、存儲(chǔ)、檢索，運(yùn)維成本較低，體驗(yàn)較好。

·Trace，知幾接入天機(jī)閣來(lái)對(duì)請(qǐng)求做traceing，記錄系統(tǒng)的請(qǐng)求鏈路等上下文信息。通過(guò)traceId對(duì)請(qǐng)求進(jìn)行標(biāo)記染色很大程度上提升了問(wèn)題定位的效率。在此基礎(chǔ)上，知幾同時(shí)也在嘗試dapr[2]這類(lèi)新的分布式應(yīng)用開(kāi)發(fā)組件，dapr提供的可觀測(cè)性的無(wú)感知接入，相比天機(jī)閣等侵入式的接入方式，成本更低。

總結(jié)

知幾整個(gè)上云遷移的過(guò)程隨著公司云原生體系的基礎(chǔ)設(shè)施的完善在不斷的完善和優(yōu)化，公司在相關(guān)領(lǐng)域的共建使得業(yè)務(wù)在實(shí)施過(guò)程中有了更多的選擇。希望知幾的實(shí)踐能給更多的業(yè)務(wù)團(tuán)隊(duì)帶來(lái)價(jià)值。未來(lái)在云原生的深入實(shí)踐方面，團(tuán)隊(duì)還會(huì)在云原生標(biāo)準(zhǔn)化方向上（mecha理念）做出更多的嘗試。

參考資料

[1]游戲知幾:【https://gbot.qq.com/#/home】

[2]dapr:【https://github.com/dapr】