腾讯会议如何做到8天扩容100万核？

　　关注腾讯开发者，一起用技术改变世界

　　本文为腾讯会议背后技术系列第一篇

　　疫情期间，腾讯会议作为一款非常便捷的远程协作工具，成为国内众多企业日常会议沟通交流的主要平台。殊不知，这款产品从 2019 年 12 月 26 日才正式推出。如何在这么短的时间内，有效撑起国内数以亿计的用户访问量，保证系统的稳定运行？本文来自腾讯云的技术人员，为你解析 8 天时间内完成 100 万核资源的扩容背后的技术，希望对大家有所借鉴。

　　如果需要交付 100 万核的计算资源，需要做什么？准备资源，然后按用户需求进行交付。如果在前面加一个定语“快速”呢？可以加班加点完成。但是如果要实现 8 天内完成 100 万核的资源交付，换算下来，每天需要交付 12.5 万核，这就有点苛刻。在云计算的历史上，从未出现过类似的案例。

　　那么，腾讯会议是如何做到的呢？

　　解决思路

　　首先，分析如此短的时间内，交付这些资源需要做哪些事情，会遇到哪些问题。

　　实际上，借助于当前成熟的虚拟化技术，可以基于已经制作好的镜像系统文件，快速地部署一套用于提供服务的生产环境，所以，只需要准备好足够的计算资源就能够实现服务的无限扩容，而这个过程大概需要以下四步。

　　1. 准备资源，投放物理机：作为云计算服务提供商，首先资源是第一位的，所以第一步要准备用于提供服务的物理机。这 100 万核心的资源，相当于约 12000 台物理机。以防资源不足的问题，需要快速将这些物理机全部上架，同时，保证每台物理机经过验证，并且部署了正确版本的后台组件。

　　2. 资源注册与分配：有了物理机资源，下一步就需要把初始化好的物理机资源投放到现网环境中，确保每一台物理机资源都在 CVM 后台服务中注册。腾讯云操作系统 VStation 需要维护数十万级的物理机资源，这无疑对资源调度能力提出了极大的挑战。这一步需要快速将所有计算资源找到对应的物理机承载。

　　3. 资源创建与交付：当后台调度系统选择好承载计算能力的物理机之后，下一步是到物理机上创建虚拟机资源。这一步看似简单但需要做的事情却不少，如生成用户控制数据，与存储、网络系统交互，生成对应的虚拟机配置，启动虚拟机。

　　4. 虚拟机初始化：虚拟机成功创建之后，就已经可以交付使用了。不过可能还需要进行配置，如拉取配置、加入服务集群、启动服务等。

　　完整历程解密

　　图 1 是腾讯云操作系统 VStation 架构图，腾讯云操作系统 VStation，承担资源调度、请求排队的任务，已经对大批量、高并发的创建请求进行了充分优化。具体来说：

API 部分接入用户请求，管理用户角色、CVM 机型、用户配额等；
云操作系统 VStation，承担资源调度、请求排队，目前虚拟机每分钟吞吐可达到 5000 台；
Host 组件上安装用于生产和配置 CVM 实例的各种辅助组件。

　　图1：VStation 云操作系统

　　下面从资源准备、注册与分配、创建与交付、虚拟机初始化四大部分详细介绍下其中的具体过程。

　　1. 准备资源，投放物理机

　　腾讯云基于定制化腾讯 TLinux、自研的虚拟化 hypervisor 系统，可以实现批量自动部署、自动投放，并且在投放到现网之前进行自动验证，保证软硬件不存在隐患。腾讯云 Host 组件管控系统，方便管理腾讯云 hypervisor 上的各种代理组件，易于发布，方便运维。

　　图2：Host 初始化过程

安装系统：运维平台从资产管理平台 CMDB 拉取对应 Host 相关机型信息，寻找与该机型对应的 TLinux 操作系统控制 BMC 配置从 pxe 启动，从 pxe 服务器拉取系统镜像安装系统。
系统初始化：安装完系统后需要配置各种系统参数，调优。
部署 Host 使用的组件：每种不同机型的 CVM 使用的 Host 会使用不同的后台 Agent，以及相关配置。通过 Host 组件管控系统 Host 使用的插件进行统一管理，下发。
导入集群：已经初始化好的 Host，需要导入到 VStation 集群才能售卖和生产 CVM。

　　图3：Host 组件管控系统

　　Host 组件管控系统用于下发 Host 组件、灰度版本、控制、支持并发下载、灰度发布，同时上报 Host 上各个组件的信息、组件健康管理、自动拉起组件、异常告警等。

　　2. 资源注册与分配

　　作为整个系统的核心，腾讯云操作系统 VStation 需要管理 10 万级的物理机资源，近千万级的核数，所以需要实现快速和稳定的调度系统。VStation 服务类似 Google Borg/Omega 使用的分布式调度架构，对计算资源进行调度。

　　图4：VStation 调度系统

　　其中，水平扩展调度器支持横向扩容，每个调度器拥有几乎全部的集群信息，方便掌握全局资源；采取增量同步、定时更新、局部缓存的方式，尽可能多地掌握全局视图，并且维持集群状态信息的准确性。

　　调度决策方面，将可能过滤掉更多物理机的基础条件放在调度器的靠前位置，过滤掉无法满足基本条件的物理机列表，减少调度过程中物理机集合在不同调度器之间的传递；同时，根据多个维度，如物理机资源使用率、剩余资源等，对满足装箱条件的物理机进行排序，尽可能优先使用优质 Host 资源，合理调配。此外，避免多个调度器在并发时选中相近的物理机，对经过排序后的物理机进行随机调整，减少大并发时造成的冲突。

　　3. 资源创建与交付

　　解决资源调度问题后，需要在选中的物理机上创建虚拟机资源，其中有一些耗时的硬性阶段无法解决，VStation 对此结合资源创建过程的的特点，做出了令人满意的优化，把单台虚拟机创建时间基本控制在3-5 秒。

　　前面提到，资源创建需要与诸如用户控制数据、网络服务、存储服务、镜像服务、密钥、安全组服务等进行交互，完成用户与所创建的虚拟机资源之间的映射。VStation 平台设计之初就考虑到高并发，批量创建的场景，对周边系统的交互实现了并行化通信。同时，为支持高并发，提高服务的吞吐量，每种与其他服务交互的工作进程通过高可用消息队列通信，都是无状态和可扩容的。真正实现了高可用、高并发、自动容灾。图 5 是 VStation 内部系统的核心架构。

　　图5：VStation 后台架构

　　VStation 通过高可用的消息队列，控制数据与周边系统交互的工作进程间通信，同时对创建过程中的关键任务按照依赖关系实现并行化，最大限度的压缩创建总耗时。针对高并发请求，为减少对系统自身的影响，系统具备以下特性：

　　控制信息载荷自动压缩

　　控制消息携带了 CVM 实例的各种控制信息：计算、存储、网络以及各种元数据信息。随着系统功能增加，控制层面数据也有所增长，控制信息载荷增大。使用压缩算法在投递消息前进行压缩并在接受消息后解压缩，能够大大降低消息占用消息总线，提高消息吞吐率。目前 VStation 使用开源 LZ4 – Extremely fast compression 压缩和解压缩算法，压缩速率可达到 780 MB/s，解压缩速率在 4970 MB/s，压缩率在 2 倍左右。

　　负载平衡

　　分布式系统中会使用多个实例以增加系统请求响应吞吐率，控制模块负载平衡可以保证请求均匀地被各个 worker 处理。负载平衡需要后台处理请求的 worker 均匀分配到不同处理实例上，降低等待队伍长度，并发执行任务。同时需要将虚拟机实例尽量均匀地分配在不同 Host。

　　将并发请求尽可能均匀地分在不同物理机，有利于加快办法创建速度。生产虚拟机较为耗时的任务有创建虚拟机磁盘、下载虚拟机镜像、申请网卡、配置网络等。如果多台虚拟机串行地在同一台物理机上创建，必然是系统瓶颈，创建耗时延长。VStation Scheduler 在装箱时，每个 Scheduler 实例有近乎全局的资源视图，对同一批次的创建任务，可以在虚拟机并发装箱时保证虚拟机尽量不落在同一台物理机。

　　流控系统

　　当请求数超过系统承载能力时，如果不加控制，会对周边系统造成危害，导致系统过载，内部组件异常（如 DB 慢查询、不响应、消息队列丢消息），破坏性较大，严重时会造成服务不响应，甚至用户数据不一致。VStation 增加排队机制，降级服务，而不是返回系统内部错误，以提升用户体验。流控系统由以下几个方面组成：

关键请求频次控制：在 API 请求频次上对用户做限制，防止恶意用户频发请求系统，如恶意购买，刷单等。
用户配额限制：限制用户随意申请资源，尤其是按量资源，限制配额。
后台请求排队与流速控制：任何系统都有能承载的处理容量，当 VStation 正在处理的请求超过一定阈值时，对新加入的请求不做拒绝处理，而是放入等待队列中待正在处理的任务完成后继续执行。

　　图6：VStation 流控系统

　　任务编排优化

　　一个完整的创建任务涉及到的各种子任务较多，单纯串行执行虽然逻辑清楚且维护简单，但不利于充分发挥系统能力，高并发创建场景中耗时较长。通过分析虚拟机实例创建过程中的各种依赖关系，将不耦合的任务并行执行，把简单的单项图转换成有向无环图（DAG），进一步提升任务的并行度。

图7：创建流程任务优化

　　调整后，单台 CVM 实例创建任务可以控制在 5 秒以内。

　　4. 虚拟机初始化

　　提到云主机的初始化，CVM 支持使用云原生的 cloud-init 服务，支持云计算主机镜像初始化协议，用户通过传入自定义的脚本程序，实现云主机创建后自动执行预定义配置。同时，腾讯云提供实例 metadata 服务。用户在自定义脚本程序中可以访问实例 metadata 服务获取与实例有关的信息，如 IP 地址、实例名称等，来实现每个实例的特殊化配置。