庚子新春，一场突其而来的疫情打乱了中国经济秩序。但经济终要复苏，此时，线上会议服务成为企业远程工作的重要协同工具。
于是，腾讯会议春节期间马上紧急召回技术团队，在现场或在远程，通过各种手段来支撑起会议服务。
团队不仅通宵达旦地对服务的架构、承载能力做了优化，同时腾挪腾讯云全国资源进行多次扩容。日均扩容云主机近1.5万台，8天总共扩容超过10万台云主机，涉及超百万核的计算资源投入。强大的云资源保障下，会议完美的扛住了全国用户的访问请求。在线用户天天攀升，稳健地顶住了多次的流量高峰。
全球云数据中心支持
全球化的云数据中心
短短几天要扩容百万核心，资源供给难度极大。如果按一台物理服务器64核心来计算，需要上架近二万台物理服务器。加上春节和疫情双重叠加，物流困难重重，服务器资源供给的任务根本是不可能完成的。
幸而借助腾讯云数据中心资源弹性和能力，资源规划团队每天都能从各地的云数据中心快速供应带宽、计算和存储资源。短短一周内，云帮助腾讯会议快速调度到支撑海量用户的资源。
腾讯云各区域数据中心网络支持城市和园区颗粒度，能够精细化地分配IP和业务部署。电信、联通、移动和中小运营商的用户都能按IP调度策略分别动态定向到不同的接入点VIP，精细化定向覆盖网络运营，提高了用户按地域、按运营商等维度访问腾讯会议服务的质量，省却了开发团队在架构分布上的规划投入。
腾讯会议在海外还有大量的用户接入，借助腾讯云海外支持能力，运维团队快速在欧美、日韩、东南亚和中东等地部署了接入点和业务逻辑层，通过低延迟全球骨干网络，实现海外用户的会议音视频接入，实现了全球的远程会议功能。
腾讯会议使用了全球应用加速 GAAP，将当地区域用户通过加速节点转发到距离最近的业务接入服务。GAAP通过全球节点之间的高速通道、转发集群及智能路由技术，实现各地用户的就近接入，通过高速通道直达源站区域。
计算资源交付
依赖于腾讯积累的标准化CMDB，底层的数据中心物理机和虚拟机的运维方式采用了标准化的包发布方式。
CMDB将业务所依赖的各种依赖包、配置、文件、权限、日志、流程和测试用例等以配置库的方式存储。包发布系统在应用CMDB的基础上实现一键交付的能力，可以在一小时以内同时交付上万台实体机和虚拟机。
包发布中的每一个软件包是完成特定功能所需文件的集合，包发布系统包括了一键式的部署流程，包括配置下发（统一管理类似 nginx.conf这样的配置文件），服务部署（上传进程包并运行），进程管理（对进程进行跟踪，保证进程意外退出时及时拉起）等功能。
腾讯自研服务器
服务器硬件上，会议使用了腾讯自研星星海服务器。这是星星海服务器首次承担如此大规模的百万核心级计算资源保障任务。
星星海是腾讯第一款自研服务器，服务器除了在软硬件系统上进行了自主研发设计外，还在芯片等关键部件上与供应链企业进行了深度定制。
使用星星海有效提升了腾讯云IaaS在腾讯会议硬件质量验收、云化适配和故障检测修复等环节的效率，进而也提升了腾讯云大规模计算资源的调度效率。腾讯会议因此能够实现单日几十万核计算资源的快速扩容。”
星星海还具备故障热迁移能力，系统监测到某一台物理服务器状态为不健康，腾讯云的快速故障热迁移能力能够在用户无感知的情况下，将子机迁移到健康的母机上，保障业务平稳运行。
云原生架构
如果说腾讯的QQ、微信和游戏等业务是从自研架构迁移到腾讯云，腾讯会议完全就是一个完全诞生于原生云的业务。在云上，会议使用了容器服务、中间件、数据库和存储等全套服务。
会议在一个月内，从一地部署扩张到广州、北京、上海和重庆等全国多地部署；从一个单一应用架构变化为多地SET化架构；各种应用服务不断拆分成更多的服务模块；和企业微信、微信等多个产品的联动；从中文版本发展到多语言版本等等。每天都遇到各式各样的花式挑战。
在强大云原生平台的支持下，腾讯会议架构能够便利的弹性伸缩，经受住了高海量并发的考验。
TKE云原生容器服务
腾讯会议的接入和逻辑层使用了腾讯云的TKE（Tencent Kubernetes Engine ），TKE是基于基于原生 kubernetes的容器管理服务，部署高效，扩容效率极高。
基于不可变基础设施的理念，TKE容器提供了统一的应用交付模式。腾讯会议业务应用的二进制文件、配置、环境等打包成一个镜像，在开发、测试和生产环境中使用同一个镜像，保证了不同环境中交付的不可变，业务迭代版本可以在流水线中的敏捷开发和快速交付。
除了支持Kubernetes原生特性，针对业务的应用特性，容器团队在TKE基础上做了应用层的封装，增加了服务发现与路由管理的支持，例如支持内部的名字路由服务L5；支持应用CMDB；支持容器网络与自研网络互通；内部的各种CI流程打通，包括蓝盾、OCI、QCI和包发布等公司的CI流程； 提供全国、全球各大区域的应用部署、升级、弹性伸缩等核心服务能力。
会议服务的注册、登录、接入、长连接、混音、流控等服务完全托管在容器平台上，以镜像为唯一的交付标准，实现自动扩缩容和基于SET的资源调度能力。大的模块下有上万个POD。容器的秒级扩容能力，极大解放了运维扩容的效率。
数据库和中间件
会议后端的数据库采用各种云原生的数据库，包括MySQL、Redis、MongoDB等。业务在全国各地实例资源上，自行实现了多地云数据中心的同步写和异地读能力。
会议使用云MySQL用来存储会议用户信息，落地数据等数据。
云Redis（TencentDB for Redis）用来存储会议房间，会议列表，文档列表等缓存信息，云上的Redis扛住了会议高峰期每秒上千万级的读写并发QPS。
使用了云数据库之后，会议的运维和开发不需要专门的DBA。通过控制台，运维和开发可以即时查看各种数据库的连接、CPU利用率、IO利用率、慢查询等数据，一键生成异常诊断报告，获知数据库服务的健康得分，从报告中定位出异常因素，进行慢查询语句优化。
譬如上图的案例，可以分析到数据库实例中有大量的全表扫描查询，导致CPU利用率超过阈值。通过在控制台查询慢查询SQL语句，开发不断优化应用性能，解决了此实例的性能瓶颈。
有了强大的云PaaS服务伸缩能力，几个会议运维工程师才能够在短短时间内同时支持计算资源扩容和PaaS服务扩容。
通过腾讯云的CAM权限管理，会议内众多的开发团队能够按实例级的颗粒度来进行权限控制。譬如A团队申请的实例，可以设置B团队具有浏览权限，但不能重启和销毁。运维团队拥有更多的权限，可以浏览、重启、观测所有会议业务的实例资源，但没有销毁权限。，以保证业务安全
PaaS服务有默认的备份策略，也可以配置个性化的备份策略，完善的全托管备份方式之下，运维团队省却了传统运维大量的常规工作。
运维体系保障
容量巡检
会议的容量巡检用于衡量服务模块的计算和网络水位，结合业务大盘指标及各个模块的服务指标，可以获知到服务模块的负载情况，结合扩缩容调度，能够实现业务的性能与成本间的平衡。
容量巡检系统从基础数据中拉取服务器的计算和网络的利用率，在实时流计算中按模块维度进行聚合。采用不同的容量计算方式，得出模块级别的利用率，并上向汇聚成服务和业务的总体平均利用率。
在业务高峰值班期间，容量巡检通过人工巡检和机器人巡视二种方式来进行，上百个服务模块的容量和质量数据由企业微信机器人定时巡检，重点模块和高负载模块被推送到值班群，极高负载的模块和机器则通过微信、小程序或电话告警的不同方式触达值班人员。
同时还把模块的利用率通过大屏展示到值班大屏幕上，直观了解各重点模块的曲线变化。
通过机器人和工程师相互结合的值守，减少了人工巡视的工作量，工程师从而把时间聚焦在重点负载视图和问题处理解决之上。
容量压测
春节以来腾讯会议的开发团队每天都要快速迭代几十个大小版本，包括BUG解决、新功能上线、架构优化和性能优化等，为了衡量新版本核心业务链条的健壮性和性能，每天晚上使用高峰过后，测试团队都要在凌晨时间进行大大小小的模块级、系统级和SET级压测，及时发现会议自身和周边服务的短板。
每天压测出来的各种问题，开发团队要在下半夜紧急修复版本，回滚旧版本，或者紧急扩容新功能服务，以保证上午业务高峰期服务的高可用性。
应急预案
团队提前准备了各种应急预案，根据流量、容量水位和质量数据的变化，做出SET调度、服务柔性等分级决策。
应急预案包括了服务容量达到60%，80%，90%等不同水位，在服务级和系统级的策略手段。譬如接入层限频，并发布限流公告；核心模块开启熔断；全国各SET的人工流量调度；视频降码率等。每个策略有主备责任人紧急操作实施。
最终由于容量准备周全，服务健壮性强，众多问题在压测环节得到优化，准备的应急预案都没有实施。
会议高峰值守
每天会议团队的工作日志为，上午7点开始上午高峰值守，11点总结，中午12点到14点问题优化，下午14点到18点进入下午高峰值守，18时当天会议总结，晚上各个模块的版本迭代发布，23时至凌晨2时进入每天例行压测或演习，2时至6时解决压测中出现的问题。
快节奏的工作日志下，团队只能小憩二三个小时，每天周而复始。
由于疫情，开发、运维、测试和周边支持团队分隔在全国各地，这个时候腾讯会议成为各团队之间高效协同的核心武器。
总结
腾讯会议是一款真正基于云原生的SaaS产品，短短一二周内，会议产品凭借强大的云原生架构，从最早的广州云，快速扩容到全国几大区域的SET，以及全球几十个海外节点接入，用户量从春节前的几十万在线增长到数千万在线，日活跃用户上亿。这在传统的数据中心是极难实现的目标。
腾讯会议人数不多的业务运维团队，通过腾讯云后端IaaS、云PaaS运维服务支持，才能够高效的支撑了海量流量的服务保障。
通过业务和系统的可观测性，及时掌握业务和系统瓶颈，快速定位问题，及时优化，保证了业务的高可用性。
腾讯会议的春节云上成长经验，希望给更多的，通过公有云高速成长的业务参考借鉴。
