背景

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

• 數(shù)量多，平均每天都會有幾十個活動上線，而且活動種類繁多

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

• 訪問量大，王者榮耀、和平精英等全部游戲運營活動日 PV 超百億級

• 活動邏輯復(fù)雜，模塊多，上下游依賴多，并且對依賴服務(wù)有N倍放大，容量評估工作量大，涉及的開發(fā)和運維人員多，緊急突發(fā)可能性大

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

自研上云實踐

游戲數(shù)據(jù)營銷活動

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

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

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

• 網(wǎng)關(guān)和業(yè)務(wù) Pod 都是多副本部署，且集群內(nèi)多可用區(qū)節(jié)點部署
• TKE 集群外的 CLB 主動探測網(wǎng)關(guān)的存活，自動剔除故障網(wǎng)關(guān) Pod
• 網(wǎng)關(guān)通過配置下發(fā)管理組件 Finder 檢測 Endpoint，TKE 根據(jù)就緒探測檢測服務(wù) Pod 的存活
• 宿主機(jī)容災(zāi)，宿主機(jī)故障后，該機(jī)器的 Pod 會自動遷移調(diào)度到其他可用宿主機(jī)節(jié)點

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

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

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

官網(wǎng)營銷活動

官網(wǎng)營銷活動HPA實踐

業(yè)務(wù)需求場景：營銷活動有定點開啟特性，開啟時流量會突增，且生命周期內(nèi)流量波動較大，對資源有彈性擴(kuò)縮容需求。

需求	最終效果
分鐘級擴(kuò)容	優(yōu)化后的 HPA 直接從 Metrics Server 取負(fù)載數(shù)據(jù)，擴(kuò)容可以做到1分鐘左右
原生 HPA 僅支持 Pod 粒度的 metric 計算,需要針對業(yè)務(wù)容器進(jìn)行擴(kuò)縮容	同一 Pod 多個 container 時業(yè)務(wù)容器負(fù)載高，但是 Pod 整體負(fù)載低情況下可以擴(kuò)容
支持 request、limit 多種方式觸發(fā) HPA	支持按 request、limit 的方式 HPA，覆蓋不同的業(yè)務(wù)場景
擴(kuò)縮容事件，開發(fā)側(cè)需要感知	優(yōu)化后的 HPA，擴(kuò)容、縮容都有事件通知

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

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

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

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

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

• CFS 故障時能夠快速切換到本地存儲（或者直接讀取本地存儲）

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

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

中轉(zhuǎn)機(jī)高可用采用 K8s lease 資源作分布式鎖和租約，實現(xiàn) HA 和切換功能。總體架構(gòu)圖如下：

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

業(yè)務(wù)上 TKE 后，容器環(huán)境 IP 不固定，且容器虛擬網(wǎng)絡(luò)無法與外部直接通訊，在面臨 IP 授權(quán)、業(yè)務(wù)模塊授權(quán)等場景時需要新的解決方案；由于容器宿主機(jī) IP 關(guān)聯(lián)業(yè)務(wù)相關(guān)信息，可以滿足業(yè)務(wù)模塊授權(quán)方式，并對比其他方案的效率和運維成本，最終選擇了宿主機(jī)網(wǎng)段授權(quán)方式，因此容器訪問外部實例需要在宿主機(jī)網(wǎng)絡(luò)棧做 SNAT 轉(zhuǎn)換。NAT 轉(zhuǎn)換帶來了以下幾個問題：（1）業(yè)務(wù)高并發(fā)訪問外部接口超時問題問題描述：業(yè)務(wù)調(diào)用 Redis 或者其它接口，在傳統(tǒng)環(huán)境下機(jī)器內(nèi)核參數(shù)配置開啟端口快速回收，工作正常；但 K8s 環(huán)境的容器在請求量大的情況下會造成容器源端口迅速被占滿導(dǎo)致拒絕訪問。問題分析：同時開啟 tcp_timestamp 和 tcp_tw_recycle 時， NAT 網(wǎng)絡(luò)環(huán)境下不同客戶端的時間戳不能保證一致，會在 NAT 網(wǎng)關(guān)收發(fā)包時遇到亂序問題,因此在 K8s 集群的 NAT 環(huán)境下，不能開啟 tcp_tw_recycle 快速回收。容器內(nèi)的客戶端程序頻繁建立短連接與外部 server 通信時，容器內(nèi)本地端口會快速耗盡，同時容器宿主機(jī)作為 NAT 網(wǎng)關(guān)也會大量消耗本地端口，端口耗盡后宿主機(jī)上的其他容器也會無法建立新連接。解決方式：修改程序代碼，改為使用連接池方案，避免頻繁建立短連接。（2）非對稱回包問題問題描述：業(yè)務(wù)容器調(diào)用某接口，一直未響應(yīng)，抓包后客戶端未收到回包響應(yīng)。問題分析：業(yè)務(wù)架構(gòu)為服務(wù)方有統(tǒng)一接入層，但有多個業(yè)務(wù)層，服務(wù)方接入層負(fù)責(zé)收包，服務(wù)方業(yè)務(wù)層負(fù)責(zé)回包，調(diào)用方為容器環(huán)境；容器內(nèi)調(diào)用方調(diào)用一個服務(wù)，服務(wù)方回包直接以網(wǎng)絡(luò)連接上的對端 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ù)方可以直連，沒有問題，但在容器網(wǎng)絡(luò)環(huán)境下的對外地址是 NAT 轉(zhuǎn)換后的，而在容器宿主機(jī)的 conntrack (連接跟蹤)表中，沒有業(yè)務(wù)層的連接記錄，因此會丟棄回包，回包無法到達(dá)容器。解決方案：直接的方案是使用 TKE 獨立網(wǎng)卡 direct-eni 模式可以繞開宿主機(jī)，容器直連服務(wù)方；另一種方案是修改 IP Masquerade Agent 配置，將服務(wù)方地址段加入 nonMasqueradeCIDRs 中，也可以繞開 NAT 規(guī)則。

成果

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