虚拟节点轻松应对 LOL S11 百万并发流量——腾竞体育的弹性容器实践

腾讯云原生

发布于 2021-12-07 08:10:07

1.1K0

文章被收录于专栏：腾讯云原生团队腾讯云原生团队

刘如梦，腾竞体育研发工程师，擅长高并发、微服务治理、DevOps，主要负责电竞服务平台架构设计和基础设施建设。

詹雪娇，腾讯云弹性容器服务EKS产品经理，主要负责 EKS 虚拟节点、容器实例相关的产品策划。

业务介绍

自 2019 年，腾竞整个电竞赛事数据服务完全由腾讯云 TKE 容器服务承载。腾竞赛事数据开放平台目前主要提供职业赛事数据的授权与查询，随着斗鱼、虎牙、企鹅、掌盟、微信直播、微博等平台的相继接入，平台整体流量有了爆发式的增长。

此前 2021英雄联盟全球总决赛（以下简称 S11）期间更是创下了平台流量新高，达到了百万级 QPS、百亿级调用量。面对电竞赛事此类周期性强、并发高的业务场景，有效快速的自动扩缩容、提升资源利用率，是满足业务高速发展、合理控制成本的关键所在。

这里将介绍 LOL S11 赛事期间，腾竞赛事数据开放平台如何通过 虚拟节点弹性调度+VPC-CNI 架构，轻松应对爆发的百万流量。

业务特性

电竞赛事具备明显的业务特性，其对服务的自动伸缩能力有非常高的要求。

周期性

电竞赛事具有明显的周期性，比赛时段是流量高峰期，其余时间流量骤减，流量相差数百倍，需要通过弹性扩缩能力，减少波谷时的冗余资源，降低成本。

高并发

比赛期间，服务需要承载百万级 QPS，需要快速的扩容时间、及库存充足的资源池。

突增快

比赛开始时，玩家开始大量涌入直播间，需要保证服务稳定性，避免突增流量过大引发集群雪崩。

架构介绍

整体架构

集群采用 Istio 作为服务网格框架进行微服务治理，流量经由多条 CLB（解决单条 CLB 带宽上限）进入 Istio Ingress（直连Pod)后进行流量分发，依托于 Istio 的 Sidecar 模式，能够对各服务之间进行非常精细化的流量管理，例如：灰度、限流、熔断等等。

普通节点+虚拟节点

开启 VPC-CNI 采用直连 Pod 模式后，集群不再受 NodePort 网络转发能力的限制，少量常规节点应对业务日常低负载场景，利用虚拟节点弹性扩缩容能力应对赛事期间业务超高负载场景。

DevOps

基于 Docker 的 CI/CD 服务，支持多环境（云端、本地）、多集群编排服务，满足业务的不同部署需求。

弹性扩容方案演变

基于上述的业务特性，针对弹性扩容的方案，经历了【手动扩容=>节点池=>虚拟节点】的一系列演变历程，目前的弹性扩容方案可以完美满足业务需求。

业务初期：手动扩容

业务初期，负载较低，根据业务特征，手动扩缩容基本可以满足需求。

由于手动扩缩容需要一定的时间窗口，因此需要放置一定数量的冗余资源应对突增流量，资源利用率较低，只有6%左右。

业务发展中：节点池

随着业务发展，周期性的高低峰流量特征愈发明显，面对高频的扩缩容需求时，手动扩缩容不仅人力成本较高，而且无法避免人为失误。

在突增流量速度较慢的场景下，节点池可以较好满足业务需求，不过需配置服务器，扩容速度较慢，冗余资源仍存在，资源利用率较低。另外，缩容时对节点进行封锁、驱逐等操作，不利于服务的稳定性。

业务高速发展：虚拟节点，秒级扩容，节省30%成本

业务高速发展阶段，高低峰流量相差悬殊、并发逐渐增高、突增流量时间达到秒级，节点池的扩容速度不足以满足业务需求，还有购置服务器时库存不足的风险。

虚拟节点是 TKE 提供的一种弹性调度能力，提供了近乎无限资源的扩容能力，可以直接将 Pod 调度至弹性容器服务 EKS 维护的云上资源中，无需扩容节点。相比节点池，虚拟节点的扩容、缩容流程简化了购买、初始化、退还服务器的流程，大大提升了弹性的速度，尽可能降低在扩容流程中可能出现的失败，使得弹性更快、更高效、更节省成本。

在弹性效率层面，虚拟节点可在数十秒内启动数以百计的 Pod，能够很好的应对 S11 这类高爆发业务场景。在成本层面，避免了普通节点由于无法完美分配 Pod 申请的资源而产生的 buffer 资源，节省了资源成本。

在此基础上，我们结合业务侧数据，采取自动化资源预热的方式应对高频的突增流量场景；运营类业务场景则需要和运营部门紧密结合做好手动扩容的准备。

网络转发方案优化

存在的问题

集群提供公网访问入口时，默认情况下外部流量经由集群节点 NodePort 转发至集群内部，当虚拟节点中部署的 Pod 数量较少，集群整体负载较低时，该模式不会有网络转发性能瓶颈。不过随着部署在虚拟节点中的Pod数量增大，集群整体负载升高，就需要添加更多的节点用于网络转发，这与自动伸缩、快速扩容、降低成本的目标背道而驰。

优化方案

开启 VPC-CNI 后采用直连 Pod 模式，容器与节点分布在同一网络平面，每个 Pod 分配有固定 IP，网络直接由 CLB 转入 Istio Ingress，不再经由 NodePort 转发，提高了网络转发效率，集群也不在需要网络转发节点，大大提高了集群的扩容能力。该模式下，集群扩容上限受到集群所分配网段可用 IP 数的限制，因此需要提前做好规划，避免集群扩容受限。