最佳案例 | 日 PV 超百亿级的游戏营销服务云原生容器化之路

曹鑫，腾讯业务运维工程师，擅长大规模K8s集群运营和容器化，目前就职于 IEG 增值服务部营销基础平台中心，现负责腾讯游戏数据营销服务上云和营销基础平台建设。

背景

游戏营销服务通过分析玩家在游戏内的行为数据，精准发起运营活动，实现拉新、拉活跃、拉付费、拉回流等效果，使游戏获得更大的收益。服务有如下特点：

节奏快，比如五五开黑节，九九战斗之夜，周年庆，活动仅持续数日
数量多，平均每天都会有几十个活动上线，而且活动种类繁多
访问量无法精准预估，很难精准的预测一次活动的访问量，玩家参与度经常超预期
访问量大，王者荣耀、和平精英等全部游戏运营活动日 PV 超百亿级
活动逻辑复杂，模块多，上下游依赖多，并且对依赖服务有N倍放大，容量评估工作量大，涉及的开发和运维人员多，紧急突发可能性大
大量重复开发工作，活动之间相互割裂，缺乏沉淀复用和共享

运营活动快上快下的特点非常适合跑在 TKE 环境，利用其弹性伸缩、快速扩缩容特性应对活动突发流量。

自研上云实践

游戏数据营销活动

单可用区裁撤热迁移

IDC 时代，机房裁撤是个痛点，需要要梳理机器上业务代码逻辑，服务依赖以及新机器的部署测试等，带来的迁移风险和迁移工作量都非常大。相对而言，TKE 集群的机器裁撤，只需增加集群资源池下线机器即可， Pod 是无损秒级迁移，极大提升了裁撤效率。

服务热更新发布，容量评估效率提升

游戏数据营销活动所用的TKE集群流量入口增加了 Envoy 网关服务，网关和后端 Pod 都在 TKE 集群内，出于性能考虑全部走长链接，为了实现后端服务热更新，放弃了 K8s 原生 service/ingresses 负载均衡，采用了网关直通服务 Pod 的路由方式。

网关的服务发现组件 Finder 通过 apiserver 实时 watch 服务的 Endpoint ，检测到变化则下发给网关。后端 Pod 的添加、删除完全由网关管理，整个过程请求无丢失，服务实现了热更新；对比物理机的通过 L5 摘除流量后发布、测试验证、接入流量，大大提高了发布效率。

游戏业务活动都是周期性很强的业务发布，一个游戏活动可能一周后就得下线腾出资源或者上线活动期间需要大量资源，相比物理机的机器准备，TKE 集群仅需增加集群资源，业务副本数的扩容可在秒级扩容或配置 HPA 自动扩缩容，极大的提升了周期性游戏活动资源准备效率。

服务全链路高可用及故障自愈

TKE 集群组件都是容灾部署的，且业务可跨地区迁移集群部署；任何单点故障都不影响服务，并且是同地区跨可用区（机房）容灾的，单个机房故障不影响服务，服务具备全链路的高可用容灾能力。主要体现在如下方面：

网关和业务 Pod 都是多副本部署，且集群内多可用区节点部署
TKE 集群外的 CLB 主动探测网关的存活，自动剔除故障网关 Pod
网关通过配置下发管理组件 Finder 检测 Endpoint，TKE 根据就绪探测检测服务 Pod 的存活
宿主机容灾，宿主机故障后，该机器的 Pod 会自动迁移调度到其他可用宿主机节点

跨可用区（机房）容灾，集群内宿主机节点多可用区部署接入

服务运营指标可视化

服务接入上线 TKE 集群后，我们会对服务请求 QPS、响应时间、成功率、Pod 负载等指标进行监控展示；网关主动采集上报指标到 Promethues 并将其可视化嵌入至发布平台。如下图所示，服务 QPS、耗时、成功率、负载情况一目了然；业务可通过自定义字段生成对应的监控指标报表；并且所有性能指标和 QPS 成功率都会有默认告警策略，还可根据业务特性自定义更改业务的告警阈值。

网关运营监控指标

业务容器性能监控指标

官网营销活动

官网营销活动HPA实践

业务需求场景：营销活动有定点开启特性，开启时流量会突增，且生命周期内流量波动较大，对资源有弹性扩缩容需求。

需求	最终效果
分钟级扩容	优化后的 HPA 直接从 Metrics Server 取负载数据，扩容可以做到1分钟左右
原生 HPA 仅支持 Pod 粒度的 metric 计算,需要针对业务容器进行扩缩容	同一 Pod 多个 container 时业务容器负载高，但是 Pod 整体负载低情况下可以扩容
支持 request、limit 多种方式触发 HPA	支持按 request、limit 的方式 HPA，覆盖不同的业务场景
扩缩容事件，开发侧需要感知	优化后的 HPA，扩容、缩容都有事件通知

GeneralPodAutoscaler(GPA)架构图：

大规模配置文件分发

问题描述：

营销场景下总配置文件超过百万，每秒峰值数千个文件，需要将文件分发到 K8s 集群的所有节点，保证每个业务容器都能读到相同的配置文件，对实时性和稳定要求都很高，通过优化分发系统，能做到5秒内文件分发到300 节点，通过定期校验和全量校验及时纠正，出现不一致后进行补录，保证文件的一致性。

存储方案选项：

问题分析：

CFS 属于网络存储，读写存在一定的性能损耗
容灾能力，需要另外一种存储能够做备份（本地目录最佳）
CFS 故障时能够快速切换到本地存储（或者直接读取本地存储）
中转机的同步程序保障高可用

根据可靠性、性能要求、隔离性要求，最终使用 CFS CBS，业务从 CBS 读取，CFS 作为中转，容器通过 hostPath 方式挂载宿主机的 CBS，即使出现一个节点异常，可以通过设置污点或者驱逐的方式快速迁移业务。

中转机高可用采用 K8s lease 资源作分布式锁和租约，实现 HA 和切换功能。

总体架构图如下：

业务上云后 IP 授权与 NAT 问题

业务上 TKE 后，容器环境 IP 不固定，且容器虚拟网络无法与外部直接通讯，在面临 IP 授权、业务模块授权等场景时需要新的解决方案；

由于容器宿主机 IP 关联业务相关信息，可以满足业务模块授权方式，并对比其他方案的效率和运维成本，最终选择了宿主机网段授权方式，因此容器访问外部实例需要在宿主机网络栈做 SNAT 转换。

NAT 转换带来了以下几个问题：

（1）业务高并发访问外部接口超时问题

问题描述：

业务调用 Redis 或者其它接口，在传统环境下机器内核参数配置开启端口快速回收，工作正常；但 K8s 环境的容器在请求量大的情况下会造成容器源端口迅速被占满导致拒绝访问。

问题分析：

同时开启 tcp_timestamp 和 tcp_tw_recycle 时， NAT 网络环境下不同客户端的时间戳不能保证一致，会在 NAT 网关收发包时遇到乱序问题,因此在 K8s 集群的 NAT 环境下，不能开启 tcp_tw_recycle 快速回收。

容器内的客户端程序频繁建立短连接与外部 server 通信时，容器内本地端口会快速耗尽，同时容器宿主机作为 NAT 网关也会大量消耗本地端口，端口耗尽后宿主机上的其他容器也会无法建立新连接。

解决方式：

修改程序代码，改为使用连接池方案，避免频繁建立短连接。

（2）非对称回包问题

问题描述：

业务容器调用某接口，一直未响应，抓包后客户端未收到回包响应。

问题分析：

业务架构为服务方有统一接入层，但有多个业务层，服务方接入层负责收包，服务方业务层负责回包，调用方为容器环境；

容器内调用方调用一个服务，服务方回包直接以网络连接上的对端 IP:port（即母机的IP:port）作为回包地址

接入层只负责收包转发给业务层，由业务层处理完消息后直接回包给调用方，在服务方接入层的视角中，调用方地址为 SNAT 后的主机地址，之后接入层将源地址传递给业务层，业务层往源地址回包；这种架构在原有网络环境下调用方和服务方可以直连，没有问题，但在容器网络环境下的对外地址是 NAT 转换后的，而在容器宿主机的 conntrack (连接跟踪)表中，没有业务层的连接记录，因此会丢弃回包，回包无法到达容器。

解决方案：

直接的方案是使用 TKE 独立网卡 direct-eni 模式可以绕开宿主机，容器直连服务方；另一种方案是修改 IP Masquerade Agent 配置，将服务方地址段加入 nonMasqueradeCIDRs 中，也可以绕开 NAT 规则。