背景

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

·节奏快，比如五五开黑节，九九战斗之夜，周年庆，活动仅持续数日

·数量多，平均每天都会有几十个活动上线，而且活动种类繁多

·访问量无法精准预估，很难精准的预测一次活动的访问量，玩家参与度经常超预期

·访问量大，王者荣耀、和平精英等全部游戏运营活动日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实践

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

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规则。

成果

目前王者荣耀、和平精英等全部游戏的营销运营活动已经All IN TKE，服务开发、运营效率提升明显，服务稳定性、抗压能力进一步增强。云原生的效能优势和技术红利不断释放出来，实现了低成本、高效率构建支持高并发场景的在线服务，让游戏运营活动支撑更快更稳，已经支持了每日数百亿服务请求。