导语 | 腾讯会议于 2019 年 12 月底上线，两个月内日活冲破 1000 万，被广泛应用于疫情防控会议、近程办公、师生近程授课等场景，为疫情期间的停工复产提供了重要的近程沟通工具。上线 100 天内，腾讯会议疾速迭代 20 个版本，满足一直增长的用户需要，屡次登顶 APP STROE 中国区收费榜总榜 No.1。

极速增长的会议需要，让腾讯会议服务质量剖析零碎禁受着微小的考验。为了向全网用户提供高效稳固的服务，以及对重要的大型会议进行保障护航。在充沛探讨调研了大量计划后，腾讯会议服务质量剖析团队与腾讯云 Elasticsearch（下文简称“ES”）团队开展单干，积极探索云端服务质量数据分析引擎架构的更多可能。

一、数据极速增长，业务稳固面临挑战

随同暴发增长的用户需要，腾讯会议的日活也在一直地刷新着历史记录。

从 1 月 29 日起，为了应答疫情下近程办公的需要，腾讯会议每天都在进行资源扩容，日均扩容云主机靠近 1.5 万台，8 天总共扩容超过 10 万台云主机，共波及超百万核的计算资源投入。

在会议中，偶然存在会议实时音视频卡顿、音视频不同步等会议品质问题，造成上述问题的可能因素比拟多，以后运行的网络有丢包或连贯不稳固的状况就是其中一种。

为了帮忙经营团队疾速精准地定位剖析问题，须要大量运行时的会议品质数据撑持，如网络相干的入网类型、码率、丢包率、网络切换、ip 切换等数据，以及客户端相干的 CPU 使用率、内存使用率、操作系统版本、产品版本等数据信息。

因会议是一个多用户参加交互的过程，定位问题不仅须要波及到单个用户的状况，也要从房间的维度洞察各个用户之间的分割。通过腾讯会议客户端实时上报的会议品质信息，经营团队能够疾速地对单用户、单房间的视频会议品质状况有直观的理解，为剖析问题提供了数据撑持。

除了数据的实时上报，另一方面，借助多维分析，咱们还能够在实时数据中挖掘出异常情况。如某个地区大面的卡顿，某个版本呈现特定的问题等。通过 dashboard 或数据报表的模式，帮忙经营团队及时掌控全局状况，疾速发现潜在问题。

快速增长的用户数以及一直刷新纪录的同时在线房间数，让腾讯会议服务质量剖析零碎禁受高压力，给经营团队及时排查用户问题带来了微小的挑战。深究根本原因，是因为服务质量剖析零碎在如此高压力、高吞吐的场景下，写入性能严重不足导致。因为零碎最要害的局部，是一个基于 lucene 自研的搜索引擎，扩容能力比拟差，依赖于研发团队针对业务的优化。在数据量暴涨的背景下，不能进行疾速扩容以满足需要。

二、选型 ES 及技术考量

为了保障全网腾讯会议用户都能高效稳固地进行会议沟通，保障经营团队能对用户会议中的卡顿等问题及时进行排查，以及对重要的大型会议进行保障护航。在充沛探讨调研了大量计划后，腾讯会议服务质量剖析团队决定从原来的自研服务质量数据分析系统，紧急迁徙至应用腾讯云 ES 作为数据分析引擎的架构上。

新老架构比照图

在进行架构计划选型的过程中，次要从以下几个方面进行了思考：

1. 高性能

腾讯会议服务质量数据上报至 ES 的流量，峰值高达 1000+w/s。在如此高吞吐的极限写入场景下，能继续稳固地提供数据读写服务，的确是一个挑战。在腾讯外部，也存在着相似腾讯会议这样的大批量、大吞吐写入场景，在应用过程中，业务部门常常会发现写入性能不高，且 CPU 使用率不稳固的问题，资源利用率严重不足。

腾讯云 ES 内核团队对相似的高压力写入场景进行了追踪及剖析，并在同样的场景下进行了多个计划的压力测试，发现 ES 单节点的压力写入测试与 lucene 基准的写压力测试有较大的差距。通过对调用火焰图进行剖析并比照测试 translog 的一些调优参数，最终定位发现 translog 文件的 rollGeneration 操作与 flush 操作有互斥，两个操作相互频繁的加锁烦扰，一次 rollGeneration 操作的均匀耗时达到了 570ms，在高压力写入场景下，频繁的 rollGeneration 会重大影响写入性能。

在与社区进行了大量的探讨及压测之后，最终确定了优化计划：采纳 rollGeneration 的过程中，在敞开原 translog 文件之前，先执行一次 flush，奇妙地防止了操作的互斥。这个计划对流程的革新最轻量优雅，且优化后的写入性能进步了 20% 以上。这部分优化的代码经腾讯外部的业务验证后，最终整顿提交回馈给了社区。因为这个优化在 ES 写入的所有场景下均实用，且对性能的晋升十分显著，Elastic 的创始人对该 PR 高度赞扬，并给腾讯云总裁发来了公开感谢信。

腾讯云 ES 在社区开源的内核之上，依据云上的内外部业务的场景案例积攒，做了大量的内核优化。除了下面介绍的 translog 的优化，还有带“_id”的写入操作剪枝优化、查问打算优化等等，满足了客户在性能方面的须要，并踊跃将一些通用的优化提交至社区，截至目前为止，腾讯云提交的 pr 约有 50+ 被合并到了骨干。

2. 扩容能力

在疫情期间，持续沿用原有的架构很难满足疾速扩容的需要，导致服务质量数据上报写入慢，数据大量沉积在队列中。腾讯云 ES 有着欠缺的分布式设计，单个集群反对扩容至数百甚至上千个节点。有牢靠齐备的选主算法逻辑以及 sharding 路由策略做保障。数据分片反对数据冗余，避免因为硬件故障导致的数据失落，并晋升集群的读性能。同时，数据能够按索引维度设置数据分片及正本数目，能够依据业务特点更灵便地设置正当的数值，升高了数据存储的老本。

腾讯云 ES 依靠于腾讯云 CVM 进行构建，资源池短缺，仅在疫情刚开始的一个月内就扩容了 3W 核，集群弹性伸缩的便利性失去了验证。扩容节点数目及变更节点配置等均为自动化性能，反对控制台及 API 一键操作，扩容过程平滑，不影响业务读写。

在集群扩容的场景中，置信很多业务都遇到过应用 ES 进行扩容后，大量新写入数据有读写热点，都沉积到新退出的节点上，导致节点被打挂，影响整个集群的写入性能。随着数据的增长，腾讯会议业务也扩容至千级节点的规模，那么下面的问题在腾讯云 ES 中是如何解决的呢？

社区开源版本的 ES，在 shard 调配的时候，会优先思考各个节点上已有的 shard 数量，目标是尽量放弃各个节点的 shard 和数据的平衡。当集群数据在各节点之间曾经处于 balance 状态时，这时候减少新节点。因为新节点下面的 shard 数起码，就会造成下面的问题，新写入的数据都调配在新的节点上，造成新的节点压力过高而宕机。

为了帮忙客户解决上述问题，腾讯云 ES 内核团队在原有 allocationDecider 责任链根底上，开发了一个新的 decider 调配算法，将一个 index 的所有分片，尽量均匀地调配在各个节点上，使得新写入数据的读写流量被平均分担，防止了新写入数据的拜访热点。

3. 稳定性

腾讯会议服务质量剖析零碎，从 2 月份进行 ES 架构的计划切换开始，写入吞吐从 5w/ s 一直攀升，现已达到 100w+/s。业务的突发增长有时候来的很忽然，并不能在后期做无效的评估。社区中的很多用户也遇到过相似的问题，因为没有预估到业务突发的增长，并且在业务层没有做好服务降级等机制，导致突发的写入查问流量打崩了整个集群，使 ES 服务甚至整个业务长时间不可用。那么，在相似腾讯会议这样的场景中，是怎么解决 ES 突增写入查问流量的问题的呢？

例如晚期咱们外部一个日志集群，写入量一天突增 5 倍，集群多个节点 Old GC 卡住脱离集群，集群 RED，写入进行，这个痛点的确有点痛。咱们对挂掉的节点做了内存剖析，发现大部分内存是被反序列化前后的写入申请占用。咱们来看看这些写入申请是沉积在什么地位。

ES high level 的写入流程，用户的写入申请先达到其中一个数据节点，咱们称之为数据节点。而后由该协调节点将申请转发给主分片所在节点进行写入，主分片写入结束再由主分片转发给从分片写入，最初返回给客户端写入后果。左边是更细节的写入流程，而咱们从堆栈中看到的写入申请沉积的地位就是在红色框中的接入层，节点挂掉的根因是协调节点的接入层内存被打爆。

针对这种高并发场景，咱们的优化计划是服务限流。除了要能管制并发申请数量，还要能精准地管制内存资源，因为内存资源有余是次要的矛盾。另外通用性要强，能作用于各个层级实现全链限流。

在很多数据库应用场景，会采纳从业务端或者独立的 proxy 层配置相干的业务规定的限流计划，通过资源预估等形式进行限流。这种形式适应能力弱，运维老本高，而且业务端很难精确预估资源耗费。

ES 原生版本自身无限流策略，是基于申请数的漏桶策略，通过队列加线程池的形式实现。线程池大小决定了解决并发度，解决不完放到队列，队列放不下则拒绝请求。然而单纯地基于申请数的限流不能管制资源使用量，而且只作用于分片级子申请的传输层，对于咱们后面剖析的接入层无奈起到无效的爱护作用。原生版本也有内存熔断策略，然而在协调节点接入层并没有做限度。

咱们的优化计划是基于内存资源的漏桶策略。咱们将节点 JVM 内存作为漏桶的资源，当内存资源足够的时候，申请能够失常解决；当内存使用量达到肯定阈值的时候分区间阶梯式平滑限流。例如上图中浅黄色的区间限度写入，深黄色的区间限度查问，底部红色局部作为预留 buffer，预留给解决中的申请、merge 等操作，以保障节点内存的安全性。

限流计划外面有一个挑战是：咱们如何能力实现平滑限流？因为采纳繁多的阈值限流很容易呈现申请抖动，例如申请一上来把内存打上去马上触发限流，而放开一点点申请又会涌进来把内存打上去。咱们的计划是设置了高下限流阈值区间，在这个区间中，基于余弦变换实现申请数和内存资源之间的平滑限流。当内存资源足够的时候，申请通过率 100%，当内存达到限流区间逐渐回升的时候，申请通过率随之逐渐降落。而当内存使用量降落的时候，申请通过率也会逐渐回升，不会一把放开。通过理论测试，平滑的区间限流能在高压力下保持稳定的写入性能。

咱们基于内存资源的区间平滑限流策略是对原生版本基于申请数漏桶策略的无效补充，并且作用范畴更广，笼罩协调节点、数据节点的接入层和传输层，并不会代替原生的限流计划。

4. 易用性

用户数暴增，留给系统验证切换的工夫十分短，这要求咱们必须应用一种简略疾速的解决方案。须要在一周之内输入实用计划，并进行线上数据的切换。如原架构应用 kafka 队列做数据的投递，由自研的音讯接入服务进行音讯的接入、荡涤并最终写入自研的服务质量数据存储剖析服务。因为工夫紧迫，新的计划须要尽量保留原有架构的大部分基础设施，并做尽量少的代码开发改变。

在这方面，ES 的社区生态做得十分齐备。从采集端、收集端到存储都有一整套解决方案。通过 logstash 的易用性和弱小的生态插件，能够疾速代替原有的自研数据接入组件，进行数据的荡涤转换等 ETL 过程。如原有架构中应用的 kafka，在 logstash 中就曾经蕴含了相应的 input 插件。并且有大量数据格式的解析插件反对，对于数据的一些解析、过滤、荡涤等操作能够间接在 logstash 的 pipeline 中进行简略的配置即可，基本上是 0 开发量。

丰盛的各语言 SDK，不便疾速的对服务质量剖析平台前后台进行疾速切换，理论从代码批改到上线实现只用了一天的工夫。同时，ES 社区也比拟沉闷，国内有 10 万 + 的开发者参加其中，问题都能够比拟快地失去回复和解决。在此，也特别感谢 ES 的研发团队及一线运维团队，在疫情期间，对腾讯会议进行了 7 *24 小时的反对，并对于应用 ES 的一些疑难问题给出了大量的解决方案。

三、腾讯云 ES 高可用架构 为业务提供高效稳固的读写能力

在腾讯会议服务质量数据分析系统全副切换至 ELK 架构之后，达成了 100w+/ s 的数据写入性能要求，数据从入队列到可被搜寻到的延迟时间从小时级别缩短至了秒级，保障了业务数据同步的实时性要求以及经营剖析零碎的查问提早要求。

截止到目前，腾讯会议集群随着业务的增长已平滑扩大至数百节点，百万核数规模，满足了业务数据增长下的扩容需要。

并且，得益于内核稳定性方向的大量优化，腾讯云 ES 的服务稳定性上达到了 99.99%，保障了万亿级别数据量高压力应用场景下的服务稳定性，为腾讯会议的经营剖析及问题排查保驾护航。

腾讯会议的遍及与腾讯云 ES 在数据搜寻查问、高并发、弹性扩大以及平安畛域的技术能力密切相关。腾讯云 ES 在腾讯会议品质服务上的成功实践，也为视频会议这个细分行业畛域提供了一个优良的范例，拓展了行业解决方案的思路。

将来，腾讯云 ES 仍将一直迭代，针对用户需要，不推打磨技术和产品，继续输入稳固牢靠的 Elasticsearch 服务。

参考资料：

[1] Elasticsearch Service 收费体验馆：

https://cloud.tencent.com/act/free/personal/bigdata?from=12847#pproduct