商务合作

腾讯云游戏业务容器化改造解决方案

腾讯云游戏业务容器化改造解决方案，整合负载均衡CLB、Pod绑定外网EIP方案及Nginx Ingress容器服务功能。支持游戏服务弹性扩缩、网络访问高效调度及流量智能分发，助力游戏企业简化部署流程，提升业务稳定性与运维效率。

立即咨询

典型战斗服的架构和技术特点 icon

具体过程：

玩家们连接到某种匹配服务，匹配服务将玩家匹配分组

一旦玩家匹配成功，匹配服务通知游戏管理器在服务器集群中提供一个专属游戏进程

游戏管理器在集群中某台机器上创建专属游戏服务

游戏管理器给专属游戏服务分配IP地址和服务端口，并返回匹配器

匹配器将返回的IP地址和端口回传给玩家

玩家们直连到专属服务进程开始游戏

技术特点：

游戏存在难以预估的波峰波谷，需要快速的扩缩容

DS进程的启动时延要求很高，一般要求几秒钟，否则就会影响玩家体验

专属游戏服务器在内存中保留游戏信息，属于有状态应用，不可直接退出，需要保证用户对局结束，才能退出

DS的生命周期很短，一般只需保留几分钟或者几个小时

对网络延迟敏感，游戏服务需要直接对外提供服务，玩家直连

游戏需要频繁更新地图、道具等，需要频繁发版和灰度发布

工作负载选择

有状态服务持久化存储对比 icon

StatefulSet

PVC 关系：StatefulSet 每个 Pod 都将使用自己的 PVC

持久化存储：可使用 CFS / CBS，都支持 Pod 多副本

Deployment

PVC 关系：Deployment 所有 Pod 都将使用同一个 PVC

持久化存储：使用 CBS 只支持Pod单副本，使用CFS可支持 Pod 多副本

有状态服务持久化存储配置 icon

1、StatefulSet 多副本挂载 CBS 存储

2、StatefulSet 多副本挂载 CFS 存储

容器存储性能指标

玩家流量接入方式选择 icon

游戏玩家直连战斗服 Pod 外网IP

每个集群可使用一个 StatefulSet 工作负载，采用多副本模式运行

游戏玩家直连Pod，长连接链路简单，可以使用 HPA/HPC 处理弹性伸缩

EKS 小规格资源供给相对充足，EIP 配额可根据场景评估调整

员游戏玩家通过 CLB 转发 Pod 方式进入战斗服

每个集群可使用一个 StatefulSet 工作负载，通过 pod-name label 为每个 sts Pod 单独创建一个 LoadBalancer 的 Service，提供战斗服接入外网IP

游戏玩家通过 LB 转发接入战斗服 Pod，长连接链路多一个层级

工作负载固定内网IP / 外网IP icon

StatefulSet 固定内网IP、外网IP，同时设置响应的回收策略

为每个 Pod 绑定一个外网 CLB icon

1、StatefulSet 多副本挂载 CBS 存储

2、为 nginx-0 绑定 LoadBalancer 的 Service

客户案例——客户流量接入方式汇总 icon

CLB Ingress Controller icon

优势

控制器监听 Ingress 直接修改操作 LB 绑定路由规则

网络流量从 LB 直接到业务 POD

缺点

不支持正则表达式路由规则

不支持 rewrite 修改 url 路径

不支持金丝雀发布等高级特性

业务 Service 必须是 NodePort 类型（GR网络模式）

Nginx Ingress Controller icon

复用 Nginx Ingress Controller 的所有特性

开箱即用，支持节点池 Daemonset 和 Deployment 两种部署方式

可以使用普通 ClusterIP 类型业务 Service

Nginx Ingress 限流能力 icon

Nginx Ingress 部分限流配置项

limit-connections：单个IP地址可以同时并发连接的个数

limit-rps：限制单个IP每秒钟的请求数 (limit request per second)

limit-rpm：限制单个IP每分钟的请求数，limit-rpm的优先级高于limit-rps

limit-burst-multiplier：突发请求大小的系数，主要用来定义连接队列的长度，默认是5

limit-rate-after：超过多少流量后执行限速，单位是KB

limit-rate：单个连接每秒的限速值，单位是KB

limit-whitelist：设定IP白名单，在该白名单内的IP不被限速

Istio Ingress Gateway icon

丰富的流量管控能力，灰度发布

跨集群服务发现和路由

地域感知就近路由

实现每个 Pod 独立配置文件 icon

方案优势

每个 Pod 可以使用独立的配置文件，满足游戏业务不同 Pod 需要不同配置的需求（地图、难度级别、游戏规则、玩家数量...） initContainer是在应用程序容器之前启动的，可以保证业务 Pod 配置文件的正确生成

方案问题

使用 initContainer 需要在 StatefulSet YAML 内编写一些额外的代码来实现

需要使用StatefulSet工作负载类型，如果之前使用Deployment，

则会带来某些行为不一致的问题

有状态服务 Pod 扩缩容 icon

1、Pod 优雅终止

要实现优雅终止，首先战斗服业务代码需要支持优雅终止的逻辑，在业务代码里面处理下 SIGTERM 信号，一般主要逻辑就是"排水"，即等待存量的连接完全结束，再退出进程

Pod 长连接场景及最佳实践 icon

1、长连接 terminationGracePeriodSeconds 配置问题

长连接场景下，销毁 Pod 时需要的优雅终止时间可能较长 (preStop + 业务进程停止超过 30s)，有的极端情况甚至可能长达数小时，这时候可以根据实际情况自定义 terminationGracePeriodSeconds，避免过早的被 SIGKILL 杀死。具体设置多大可以根据业务场景最坏的情况来预估，比如对战类游戏场景，同一房间玩家的客户端都连接的同一个服务端 Pod，一轮游戏最长半个小时，那么就设置 terminationGracePeriodSeconds 为 1800