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