游戲知幾
隨著業(yè)務(wù)不斷的拓展，游戲知幾AI智能問答機(jī)器人業(yè)務(wù)已經(jīng)覆蓋了自研游戲、二方、海外的多款游戲。游戲知幾研發(fā)團(tuán)隊(duì)主動(dòng)擁抱云原生，推動(dòng)后臺業(yè)務(wù)全量上云，服務(wù)累計(jì)核心1w+。
通過云上的容器化部署、自動(dòng)擴(kuò)縮容、健康檢查、可觀測性等手段，提高了知幾項(xiàng)目的持續(xù)交付能力和穩(wěn)定性，形成了一套適合游戲知幾自身的上云實(shí)踐方案。本文將會(huì)介紹游戲知幾項(xiàng)目中遇到的痛點(diǎn)以及探索出的一套可靠的上云實(shí)踐方案。
知幾項(xiàng)目背景
游戲知幾[1]是一款游戲智能AI產(chǎn)品和運(yùn)營解決方案，它基于自然語言處理、知識圖譜、深度學(xué)習(xí)等前沿技術(shù)，為游戲玩家提供一站式服務(wù)，包括游戲內(nèi)外實(shí)時(shí)智能問答、游戲語音陪伴、自助流水查詢、游戲內(nèi)外數(shù)據(jù)互通、主動(dòng)關(guān)懷防流失、產(chǎn)品合規(guī)保護(hù)等多種能力，目前已經(jīng)接入包括王者榮耀、和平精英、PUBG mobile、天刀手游等六星游戲在內(nèi)的80+款游戲，為海內(nèi)外數(shù)以億計(jì)的游戲用戶提供服務(wù)，獲得眾多游戲項(xiàng)目和廣大用戶的持續(xù)好評。
同時(shí)游戲知幾還提供了簡便易用、性能良好的客戶端SDK和功能完備的運(yùn)營平臺系統(tǒng)，支持模塊化接入，顯著降低了用戶運(yùn)營中的人力成本，提升了玩家的交互體驗(yàn)。
隨著知幾業(yè)務(wù)的不斷發(fā)展，知幾的部署架構(gòu)也在不斷地演進(jìn)，逐步從最初的IDC部署架構(gòu)遷移到當(dāng)前的云原生部署架構(gòu)，實(shí)現(xiàn)了業(yè)務(wù)服務(wù)的全面上云。
上云前的知幾
docker部署方案
知幾在最初采用docker部署的方案來部署服務(wù)，服務(wù)的CI/CD通過夸克平臺實(shí)現(xiàn)，平臺將編譯打包好的服務(wù)推送到docker機(jī)進(jìn)行部署。為了實(shí)現(xiàn)機(jī)器的水平擴(kuò)容，運(yùn)維同學(xué)會(huì)將docker環(huán)境整體打包成基準(zhǔn)鏡像，包括IDC的機(jī)器環(huán)境所依賴的環(huán)境，比如CL5 agent，gse agent等。當(dāng)需要擴(kuò)容時(shí)，將基準(zhǔn)環(huán)境發(fā)布到擴(kuò)容機(jī)器上進(jìn)行擴(kuò)容操作。
知幾整體的部署架構(gòu)如下圖所示：
1.外部請求統(tǒng)一通過stgw接入，rs到后臺服務(wù)的vip上，通常會(huì)區(qū)分移動(dòng)、聯(lián)通、電信和小流量運(yùn)營商；
2.vip下掛載的機(jī)器IP、端口通過tgw平臺配置，請求通過一定的負(fù)載均衡策略發(fā)送到IDC機(jī)器的后臺服務(wù)上；
3.服務(wù)的CI/CD通過夸克平臺操作，完成服務(wù)的編譯、打包、發(fā)布等操作，也支持操作回滾，進(jìn)程監(jiān)控等；
4.監(jiān)控告警、日志系統(tǒng)接入的是mo監(jiān)控平臺和駿鷹。
服務(wù)遇到的問題
知幾項(xiàng)目會(huì)對接IEG下的眾多游戲，伴隨著游戲接入的增多，流量也變得越來越大，知幾項(xiàng)目的流量狀況有以下特點(diǎn)：
1.平時(shí)流量平穩(wěn)，節(jié)假日流量隨游戲流量增大，通常達(dá)到3倍以上；
2.主動(dòng)關(guān)懷類的消息推送，運(yùn)營活動(dòng)會(huì)通過知幾直接觸達(dá)給玩家，帶來可觀的突發(fā)流量，極端情況10倍以上；
因此，知幾對服務(wù)的穩(wěn)定性、可觀測性以及服務(wù)治理的能力有很高的要求，需保證項(xiàng)目在流量突發(fā)的情況下能夠正常運(yùn)行，故障時(shí)能及時(shí)發(fā)現(xiàn)。
在docker部署的架構(gòu)下，很難做到快速地自動(dòng)擴(kuò)縮容，主要問題有以下幾個(gè)方面：
1.擴(kuò)容前的機(jī)器申請、環(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.依賴的權(quán)限（mysql等）需要申請；
4.平臺操作繁瑣，容易出錯(cuò)；
5.需要人工完成運(yùn)營活動(dòng)后機(jī)器的縮容操作。
這些問題都會(huì)造成服務(wù)在擴(kuò)容時(shí)的不及時(shí)，從而帶來服務(wù)穩(wěn)定性的隱患，同時(shí)也帶來了業(yè)務(wù)同學(xué)的運(yùn)維負(fù)擔(dān)。除此之外，每年一次的機(jī)器裁撤也很痛苦，涉及機(jī)器確認(rèn)、服務(wù)遷移、環(huán)境梳理等方方面面的操作。
因此，我們希望通過上云遷移，利用云原生的HPA能力來解決服務(wù)穩(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ù)通過ingress暴露外網(wǎng)流量，tapisix網(wǎng)關(guān)混連接入一區(qū)、二區(qū)服務(wù)的ingress；
·新增上海災(zāi)備集群，極端情況下可快速接入；
·CI/CD方面通過藍(lán)盾流水線實(shí)現(xiàn)，打包服務(wù)鏡像推送到鏡像倉庫，在STKE上進(jìn)行部署。
基于上述的部署方案，利用云原生的自動(dòng)擴(kuò)縮容能力可以方便地解決上述問題：
1.STKE提供的定時(shí)HPA和動(dòng)態(tài)擴(kuò)縮容能力，可以很好的解決節(jié)假日、運(yùn)營活動(dòng)的流量突增帶來的服務(wù)穩(wěn)定性問題，且流量平穩(wěn)后的自動(dòng)縮容可以有效的節(jié)約資源；
2.STKE提供自動(dòng)鑒權(quán)流程，可以解決依賴權(quán)限申請的問題，通常鑒權(quán)流程的耗時(shí)在分鐘級；
3.引入tapsix統(tǒng)一網(wǎng)關(guān)，接入分區(qū)流量，可以對流量進(jìn)行快速切換，當(dāng)一個(gè)區(qū)的服務(wù)有問題時(shí)，可以通過tapsix的路由快速切換到另外一個(gè)區(qū)；
遷移方案
知幾服務(wù)的上云遷移涉及外網(wǎng)和內(nèi)網(wǎng)的眾多服務(wù)，外網(wǎng)服務(wù)遷移的過程可通過運(yùn)營商逐步對流量進(jìn)行灰度：
1.首先在stke集群新部署服務(wù)進(jìn)行測試，提供移動(dòng)、聯(lián)通、電信和CAP四類公網(wǎng)CLB；
2.先灰度CAP小運(yùn)營商流量，服務(wù)穩(wěn)定后再通過gslb逐步灰度其他運(yùn)營商；
3.回滾則通過gslb快速切換回IDC服務(wù)的VIP；
內(nèi)網(wǎng)服務(wù)的遷移則通過STKE支持的北極星、CL5 serivce自動(dòng)將pod ip注入到老服務(wù)的負(fù)載均衡當(dāng)中，首先通過一個(gè)pod進(jìn)行灰度，再逐步增加pod完成放量，最后摘除IDC的機(jī)器即可。通過這種方式，我們在三個(gè)月內(nèi)完成了所有外網(wǎng)服務(wù)和后臺服務(wù)的全量上云，并保證了遷移的平穩(wěn)進(jìn)行。
上云實(shí)踐
標(biāo)準(zhǔn)化部署實(shí)踐
業(yè)務(wù)上云基礎(chǔ)的點(diǎn)就是考慮怎么做標(biāo)準(zhǔn)化的容器部署和彈性服務(wù)。知幾服務(wù)主要有三類，業(yè)務(wù)服務(wù)通常是Go服務(wù)，算法服務(wù)為C++服務(wù)，需要考慮模型加載的問題，平臺服務(wù)主要為PHP服務(wù)。在容器的標(biāo)準(zhǔn)化上，我們采用的是單容器模式，這樣做的好處是每個(gè)container間互不影響，進(jìn)程是作為容器的一號進(jìn)程存在，一旦有問題k8s會(huì)自動(dòng)把服務(wù)拉起，另外也便于資源的復(fù)用。
富容器的模式是把所有的進(jìn)程都放在一個(gè)容器內(nèi)，這樣看似方便，能實(shí)現(xiàn)業(yè)務(wù)的無縫平滑的快速上云，但無論從未來的維護(hù)效率、安全還是健康檢查、服務(wù)彈性上看都有問題，是中間態(tài)，違反了容器單一功能原則，也不符合云原生的理念。
·PHP的服務(wù)將nginx，pfp-fpm，業(yè)務(wù)代碼都打成了獨(dú)立的container，代碼通過文件共享的形式共享給php-fpm的container實(shí)現(xiàn)。
·Go服務(wù)較簡單，采用常規(guī)的應(yīng)用container+sidecar的標(biāo)準(zhǔn)化容器。
·算法服務(wù)主要是模型，模型文件掛載到cephfs上，共享給C++服務(wù)的容器使用。
知幾在服務(wù)部署的過程中，積累了一些實(shí)踐經(jīng)驗(yàn)，通過云原生的對資源利用的優(yōu)勢，提升資源的利用率，降低運(yùn)營成本。針對不同場景最小實(shí)例的配置如下：
·測試環(huán)境、預(yù)發(fā)布環(huán)境流量較少，統(tǒng)一0.1核0.25G，1實(shí)例。
·生產(chǎn)環(huán)境，業(yè)務(wù)后臺服務(wù)采用1核2G，2實(shí)例。
·生產(chǎn)環(huán)境，算法后臺服務(wù)采用8核16G（個(gè)別如在線推理服務(wù)會(huì)采用32核以上的機(jī)器）。
通過降低單pod的CPU，MEM request，滿足日常運(yùn)營需求，流量高峰期則通過stke的HPA能力來滿足業(yè)務(wù)的需要，使日常CPU利用率能達(dá)到40%。由于HPA會(huì)導(dǎo)致業(yè)務(wù)容器的擴(kuò)縮容，如果流量在服務(wù)未完成啟動(dòng)時(shí)接入或者流量還在訪問時(shí)接銷毀pod，會(huì)導(dǎo)致流量的損失，因此需要開啟就緒檢測和prestop配置。
這里需要注意的是，就緒檢查的啟動(dòng)延時(shí)設(shè)置不宜過短，這樣系統(tǒng)會(huì)認(rèn)為pod啟動(dòng)失敗而不斷重啟，導(dǎo)致服務(wù)無法正常啟動(dòng)。
此外，stke提供的其他特性可以很好的滿足知幾的業(yè)務(wù)需求：
·提供鑒權(quán)流程，可以在pod拉起時(shí)，動(dòng)態(tài)的申請mysql等依賴的權(quán)限，規(guī)避繁瑣的權(quán)限申請流程。
·configmap可解決配置服務(wù)配置更新的問題。
·可對內(nèi)核進(jìn)行調(diào)優(yōu)，業(yè)務(wù)可根據(jù)服務(wù)、流量的特點(diǎn)針對性地對內(nèi)核參數(shù)進(jìn)行優(yōu)化，如net.core.somaxconn,net.ipv4.tcp_tw_reuse等等。
當(dāng)前知幾在線上部署了超過1w核，支撐知幾Sdk，第五人等多個(gè)應(yīng)用服務(wù)，整體的利用率在40%左右。
HPA
STKE提供的HPA能力能夠很好的滿足知幾對擴(kuò)縮容的需求，知幾同時(shí)使用了定時(shí)HPA和動(dòng)態(tài)HAP滿足不同的場景：
·針對突發(fā)流量，知幾采用CPU request和內(nèi)存request作為觸發(fā)擴(kuò)容的條件。
·節(jié)假日和周五、六晚未成年人游戲上線，知幾采用周定時(shí)HPA提前擴(kuò)容。
這樣很大程度上減少了開發(fā)、運(yùn)維同學(xué)面對運(yùn)營活動(dòng)和突發(fā)流量時(shí)的心智負(fù)擔(dān)，提高了服務(wù)穩(wěn)定性。特別是定時(shí)HPA，可以很方便的滿足知幾在未成年人保護(hù)方面對擴(kuò)縮容的要求，系統(tǒng)可以在特定時(shí)間段完成系統(tǒng)容量的擴(kuò)容和縮容，在保證系統(tǒng)平穩(wěn)應(yīng)對流量的同時(shí)也不會(huì)造成對資源的浪費(fèi)。遷移上云后，知幾通過這種方式保證了周末時(shí)段和線上多場運(yùn)營活動(dòng)的平穩(wěn)進(jìn)行。
可觀測性
系統(tǒng)的可觀測性能夠讓開發(fā)同學(xué)根據(jù)系統(tǒng)輸出快速監(jiān)控、定位問題?？捎^測性可以從Metrics、Log、Trace三個(gè)方面來看。
·Metrics，知幾服務(wù)大部分對接的是Monitor系統(tǒng)，通過自定義metircs上報(bào)實(shí)現(xiàn)模調(diào)信息、服務(wù)狀態(tài)、業(yè)務(wù)等指標(biāo)的監(jiān)控，知幾封裝了Monitor的標(biāo)準(zhǔn)庫實(shí)現(xiàn)指標(biāo)模板的標(biāo)準(zhǔn)化和上報(bào)。Monitor上報(bào)需要通過http請求獲取上報(bào)的ip再將數(shù)據(jù)通過tcp形式發(fā)送到Monitor側(cè)，這種形式的上報(bào)對業(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ī)閣來對請求做traceing，記錄系統(tǒng)的請求鏈路等上下文信息。通過traceId對請求進(jìn)行標(biāo)記染色很大程度上提升了問題定位的效率。在此基礎(chǔ)上，知幾同時(shí)也在嘗試dapr[2]這類新的分布式應(yīng)用開發(fā)組件，dapr提供的可觀測性的無感知接入，相比天機(jī)閣等侵入式的接入方式，成本更低。
總結(jié)
知幾整個(gè)上云遷移的過程隨著公司云原生體系的基礎(chǔ)設(shè)施的完善在不斷的完善和優(yōu)化，公司在相關(guān)領(lǐng)域的共建使得業(yè)務(wù)在實(shí)施過程中有了更多的選擇。希望知幾的實(shí)踐能給更多的業(yè)務(wù)團(tuán)隊(duì)帶來價(jià)值。未來在云原生的深入實(shí)踐方面，團(tuán)隊(duì)還會(huì)在云原生標(biāo)準(zhǔn)化方向上（mecha理念）做出更多的嘗試。
參考資料
[1]游戲知幾:【https://gbot.qq.com/#/home】
[2]dapr:【https://github.com/dapr】
騰訊云
專欄
閩公網(wǎng)安備 35010202001226號
