背景

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

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

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

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

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

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

自研上云實踐

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

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

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

服務全鏈路高可用及故障自愈

• 網(wǎng)關(guān)和業(yè)務 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ù)就緒探測檢測服務 Pod 的存活
• 宿主機容災，宿主機故障后，該機器的 Pod 會自動遷移調(diào)度到其他可用宿主機節(jié)點

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

服務運營指標可視化

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

官網(wǎng)營銷活動

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

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

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

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

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

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

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

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

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

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

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

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

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

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

成果

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