騰訊云最佳案例 | 日PV超百億級(jí)的游戲營(yíng)銷(xiāo)服務(wù)云原生容器化之路

背景

游戲營(yíng)銷(xiāo)服務(wù)通過(guò)分析玩家在游戲內(nèi)的行為數(shù)據(jù)，精準(zhǔn)發(fā)起運(yùn)營(yíng)活動(dòng)，實(shí)現(xiàn)拉新、拉活躍、拉付費(fèi)、拉回流等效果，使游戲獲得更大的收益。服務(wù)有如下特點(diǎn)：

·節(jié)奏快，比如五五開(kāi)黑節(jié)，九九戰(zhàn)斗之夜，周年慶，活動(dòng)僅持續(xù)數(shù)日

·數(shù)量多，平均每天都會(huì)有幾十個(gè)活動(dòng)上線，而且活動(dòng)種類(lèi)繁多

·訪問(wèn)量無(wú)法精準(zhǔn)預(yù)估，很難精準(zhǔn)的預(yù)測(cè)一次活動(dòng)的訪問(wèn)量，玩家參與度經(jīng)常超預(yù)期

·訪問(wèn)量大，王者榮耀、和平精英等全部游戲運(yùn)營(yíng)活動(dòng)日PV超百億級(jí)

·活動(dòng)邏輯復(fù)雜，模塊多，上下游依賴(lài)多，并且對(duì)依賴(lài)服務(wù)有N倍放大，容量評(píng)估工作量大，涉及的開(kāi)發(fā)和運(yùn)維人員多，緊急突發(fā)可能性大

·大量重復(fù)開(kāi)發(fā)工作，活動(dòng)之間相互割裂，缺乏沉淀復(fù)用和共享

運(yùn)營(yíng)活動(dòng)快上快下的特點(diǎn)非常適合跑在TKE環(huán)境，利用其彈性伸縮、快速擴(kuò)縮容特性應(yīng)對(duì)活動(dòng)突發(fā)流量。

自研上云實(shí)踐

游戲數(shù)據(jù)營(yíng)銷(xiāo)活動(dòng)

單可用區(qū)裁撤熱遷移

IDC時(shí)代，機(jī)房裁撤是個(gè)痛點(diǎn)，需要要梳理機(jī)器上業(yè)務(wù)代碼邏輯，服務(wù)依賴(lài)以及新機(jī)器的部署測(cè)試等，帶來(lái)的遷移風(fēng)險(xiǎn)和遷移工作量都非常大。相對(duì)而言，TKE集群的機(jī)器裁撤，只需增加集群資源池下線機(jī)器即可，Pod是無(wú)損秒級(jí)遷移，極大提升了裁撤效率。

服務(wù)熱更新發(fā)布，容量評(píng)估效率提升

游戲數(shù)據(jù)營(yíng)銷(xiāo)活動(dòng)所用的TKE集群流量入口增加了Envoy網(wǎng)關(guān)服務(wù)，網(wǎng)關(guān)和后端Pod都在TKE集群內(nèi)，出于性能考慮全部走長(zhǎng)鏈接，為了實(shí)現(xiàn)后端服務(wù)熱更新，放棄了K8s原生service/ingresses負(fù)載均衡，采用了網(wǎng)關(guān)直通服務(wù)Pod的路由方式。

網(wǎng)關(guān)的服務(wù)發(fā)現(xiàn)組件Finder通過(guò)apiserver實(shí)時(shí)watch服務(wù)的Endpoint，檢測(cè)到變化則下發(fā)給網(wǎng)關(guān)。后端Pod的添加、刪除完全由網(wǎng)關(guān)管理，整個(gè)過(guò)程請(qǐng)求無(wú)丟失，服務(wù)實(shí)現(xiàn)了熱更新；對(duì)比物理機(jī)的通過(guò)L5摘除流量后發(fā)布、測(cè)試驗(yàn)證、接入流量，大大提高了發(fā)布效率。

游戲業(yè)務(wù)活動(dòng)都是周期性很強(qiáng)的業(yè)務(wù)發(fā)布，一個(gè)游戲活動(dòng)可能一周后就得下線騰出資源或者上線活動(dòng)期間需要大量資源，相比物理機(jī)的機(jī)器準(zhǔn)備，TKE集群僅需增加集群資源，業(yè)務(wù)副本數(shù)的擴(kuò)容可在秒級(jí)擴(kuò)容或配置HPA自動(dòng)擴(kuò)縮容，極大的提升了周期性游戲活動(dòng)資源準(zhǔn)備效率。

服務(wù)全鏈路高可用及故障自愈

TKE集群組件都是容災(zāi)部署的，且業(yè)務(wù)可跨地區(qū)遷移集群部署；任何單點(diǎn)故障都不影響服務(wù)，并且是同地區(qū)跨可用區(qū)（機(jī)房）容災(zāi)的，單個(gè)機(jī)房故障不影響服務(wù)，服務(wù)具備全鏈路的高可用容災(zāi)能力。主要體現(xiàn)在如下方面：

·網(wǎng)關(guān)和業(yè)務(wù)Pod都是多副本部署，且集群內(nèi)多可用區(qū)節(jié)點(diǎn)部署

·TKE集群外的CLB主動(dòng)探測(cè)網(wǎng)關(guān)的存活，自動(dòng)剔除故障網(wǎng)關(guān)Pod

·網(wǎng)關(guān)通過(guò)配置下發(fā)管理組件Finder檢測(cè)Endpoint，TKE根據(jù)就緒探測(cè)檢測(cè)服務(wù)Pod的存活

·宿主機(jī)容災(zāi)，宿主機(jī)故障后，該機(jī)器的Pod會(huì)自動(dòng)遷移調(diào)度到其他可用宿主機(jī)節(jié)點(diǎn)

跨可用區(qū)（機(jī)房）容災(zāi)，集群內(nèi)宿主機(jī)節(jié)點(diǎn)多可用區(qū)部署接入

服務(wù)運(yùn)營(yíng)指標(biāo)可視化

服務(wù)接入上線TKE集群后，我們會(huì)對(duì)服務(wù)請(qǐng)求QPS、響應(yīng)時(shí)間、成功率、Pod負(fù)載等指標(biāo)進(jìn)行監(jiān)控展示；網(wǎng)關(guān)主動(dòng)采集上報(bào)指標(biāo)到Promethues并將其可視化嵌入至發(fā)布平臺(tái)。如下圖所示，服務(wù)QPS、耗時(shí)、成功率、負(fù)載情況一目了然；業(yè)務(wù)可通過(guò)自定義字段生成對(duì)應(yīng)的監(jiān)控指標(biāo)報(bào)表；并且所有性能指標(biāo)和QPS成功率都會(huì)有默認(rèn)告警策略，還可根據(jù)業(yè)務(wù)特性自定義更改業(yè)務(wù)的告警閾值。

網(wǎng)關(guān)運(yùn)營(yíng)監(jiān)控指標(biāo)

業(yè)務(wù)容器性能監(jiān)控指標(biāo)

官網(wǎng)營(yíng)銷(xiāo)活動(dòng)

官網(wǎng)營(yíng)銷(xiāo)活動(dòng)HPA實(shí)踐

業(yè)務(wù)需求場(chǎng)景：營(yíng)銷(xiāo)活動(dòng)有定點(diǎn)開(kāi)啟特性，開(kāi)啟時(shí)流量會(huì)突增，且生命周期內(nèi)流量波動(dòng)較大，對(duì)資源有彈性擴(kuò)縮容需求。

GeneralPodAutoscaler(GPA)架構(gòu)圖：

大規(guī)模配置文件分發(fā)

問(wèn)題描述：

營(yíng)銷(xiāo)場(chǎng)景下總配置文件超過(guò)百萬(wàn)，每秒峰值數(shù)千個(gè)文件，需要將文件分發(fā)到K8s集群的所有節(jié)點(diǎn)，保證每個(gè)業(yè)務(wù)容器都能讀到相同的配置文件，對(duì)實(shí)時(shí)性和穩(wěn)定要求都很高，通過(guò)優(yōu)化分發(fā)系統(tǒng)，能做到5秒內(nèi)文件分發(fā)到300+節(jié)點(diǎn)，通過(guò)定期校驗(yàn)和全量校驗(yàn)及時(shí)糾正，出現(xiàn)不一致后進(jìn)行補(bǔ)錄，保證文件的一致性。

存儲(chǔ)方案選項(xiàng)：

問(wèn)題分析：

·CFS屬于網(wǎng)絡(luò)存儲(chǔ)，讀寫(xiě)存在一定的性能損耗

·容災(zāi)能力，需要另外一種存儲(chǔ)能夠做備份（本地目錄最佳）

·CFS故障時(shí)能夠快速切換到本地存儲(chǔ)（或者直接讀取本地存儲(chǔ)）

·中轉(zhuǎn)機(jī)的同步程序保障高可用

根據(jù)可靠性、性能要求、隔離性要求，最終使用CFS+CBS，業(yè)務(wù)從CBS讀取，CFS作為中轉(zhuǎn)，容器通過(guò)hostPath方式掛載宿主機(jī)的CBS，即使出現(xiàn)一個(gè)節(jié)點(diǎn)異常，可以通過(guò)設(shè)置污點(diǎn)或者驅(qū)逐的方式快速遷移業(yè)務(wù)。

中轉(zhuǎn)機(jī)高可用采用K8s lease資源作分布式鎖和租約，實(shí)現(xiàn)HA和切換功能。

總體架構(gòu)圖如下：

業(yè)務(wù)上云后IP授權(quán)與NAT問(wèn)題

業(yè)務(wù)上TKE后，容器環(huán)境IP不固定，且容器虛擬網(wǎng)絡(luò)無(wú)法與外部直接通訊，在面臨IP授權(quán)、業(yè)務(wù)模塊授權(quán)等場(chǎng)景時(shí)需要新的解決方案；

由于容器宿主機(jī)IP關(guān)聯(lián)業(yè)務(wù)相關(guān)信息，可以滿(mǎn)足業(yè)務(wù)模塊授權(quán)方式，并對(duì)比其他方案的效率和運(yùn)維成本，最終選擇了宿主機(jī)網(wǎng)段授權(quán)方式，因此容器訪問(wèn)外部實(shí)例需要在宿主機(jī)網(wǎng)絡(luò)棧做SNAT轉(zhuǎn)換。

NAT轉(zhuǎn)換帶來(lái)了以下幾個(gè)問(wèn)題：

（1）業(yè)務(wù)高并發(fā)訪問(wèn)外部接口超時(shí)問(wèn)題

問(wèn)題描述：

業(yè)務(wù)調(diào)用Redis或者其它接口，在傳統(tǒng)環(huán)境下機(jī)器內(nèi)核參數(shù)配置開(kāi)啟端口快速回收，工作正常；但K8s環(huán)境的容器在請(qǐng)求量大的情況下會(huì)造成容器源端口迅速被占滿(mǎn)導(dǎo)致拒絕訪問(wèn)。

問(wèn)題分析：

同時(shí)開(kāi)啟tcp_timestamp和tcp_tw_recycle時(shí)，NAT網(wǎng)絡(luò)環(huán)境下不同客戶(hù)端的時(shí)間戳不能保證一致，會(huì)在NAT網(wǎng)關(guān)收發(fā)包時(shí)遇到亂序問(wèn)題,因此在K8s集群的NAT環(huán)境下，不能開(kāi)啟tcp_tw_recycle快速回收。

容器內(nèi)的客戶(hù)端程序頻繁建立短連接與外部server通信時(shí)，容器內(nèi)本地端口會(huì)快速耗盡，同時(shí)容器宿主機(jī)作為NAT網(wǎng)關(guān)也會(huì)大量消耗本地端口，端口耗盡后宿主機(jī)上的其他容器也會(huì)無(wú)法建立新連接。

解決方式：

修改程序代碼，改為使用連接池方案，避免頻繁建立短連接。

（2）非對(duì)稱(chēng)回包問(wèn)題

問(wèn)題描述：

業(yè)務(wù)容器調(diào)用某接口，一直未響應(yīng)，抓包后客戶(hù)端未收到回包響應(yīng)。

問(wèn)題分析：

業(yè)務(wù)架構(gòu)為服務(wù)方有統(tǒng)一接入層，但有多個(gè)業(yè)務(wù)層，服務(wù)方接入層負(fù)責(zé)收包，服務(wù)方業(yè)務(wù)層負(fù)責(zé)回包，調(diào)用方為容器環(huán)境；

容器內(nèi)調(diào)用方調(diào)用一個(gè)服務(wù)，服務(wù)方回包直接以網(wǎng)絡(luò)連接上的對(duì)端IP:port（即母機(jī)的IP:port）作為回包地址

接入層只負(fù)責(zé)收包轉(zhuǎn)發(fā)給業(yè)務(wù)層，由業(yè)務(wù)層處理完消息后直接回包給調(diào)用方，在服務(wù)方接入層的視角中，調(diào)用方地址為SNAT后的主機(jī)地址，之后接入層將源地址傳遞給業(yè)務(wù)層，業(yè)務(wù)層往源地址回包；這種架構(gòu)在原有網(wǎng)絡(luò)環(huán)境下調(diào)用方和服務(wù)方可以直連，沒(méi)有問(wèn)題，但在容器網(wǎng)絡(luò)環(huán)境下的對(duì)外地址是NAT轉(zhuǎn)換后的，而在容器宿主機(jī)的conntrack(連接跟蹤)表中，沒(méi)有業(yè)務(wù)層的連接記錄，因此會(huì)丟棄回包，回包無(wú)法到達(dá)容器。

解決方案：

直接的方案是使用TKE獨(dú)立網(wǎng)卡direct-eni模式可以繞開(kāi)宿主機(jī)，容器直連服務(wù)方；另一種方案是修改IP Masquerade Agent配置，將服務(wù)方地址段加入nonMasqueradeCIDRs中，也可以繞開(kāi)NAT規(guī)則。

成果

目前王者榮耀、和平精英等全部游戲的營(yíng)銷(xiāo)運(yùn)營(yíng)活動(dòng)已經(jīng)All IN TKE，服務(wù)開(kāi)發(fā)、運(yùn)營(yíng)效率提升明顯，服務(wù)穩(wěn)定性、抗壓能力進(jìn)一步增強(qiáng)。云原生的效能優(yōu)勢(shì)和技術(shù)紅利不斷釋放出來(lái)，實(shí)現(xiàn)了低成本、高效率構(gòu)建支持高并發(fā)場(chǎng)景的在線服務(wù)，讓游戲運(yùn)營(yíng)活動(dòng)支撐更快更穩(wěn)，已經(jīng)支持了每日數(shù)百億服務(wù)請(qǐng)求。