腾讯云Elasticsearch在腾讯会议中有哪些应用？在大规模海量应用场景下，腾讯云Elasticsearch在高可用和性能方面做了哪些优化？在低成本解决方案中又有哪些独到之处？本文是对腾讯云专家工程师张彬老师在云+社区沙龙online的分享整理，希望与大家一同交流。

　　一、腾讯云ES在腾讯会议中的应用

　　1. 腾讯会议质量分析系统

　　腾讯会议于2019年12月底上线，两个月内日活突破1000万，被广泛应用于疫情防控会议、远程办公、师生远程授课等场景，为疫情期间的复工复产提供了重要的远程沟通工具。极速增长的会议需求，让腾讯会议服务质量分析系统经受着巨大的考验。

　　在会议中偶然会存在会议实时音视频卡顿、音视频不同步等会议质量问题，造成上述问题的可能因素比较多，当前运行的网络有丢包或连接不稳定的情况就是其中一种。

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

　　除了数据的实时上报，另一方面，借助多维分析，我们还可以在实时数据中挖掘出异常情况。如某个地区大面积的卡顿，某个版本出现特定的问题等。通过dashboard或数据报表的形式，帮助会议质量团队及时掌控全局情况，快速发现潜在问题。

　　2. 痛点挑战

　　随着疫情爆发，腾讯会议快速增长，在100天内迭代了20多个版本，在8天内主机数扩容到了 10w 台，这样的急剧增长量让腾讯会议服务质量分析系统经受高压力，给运营团队及时排查用户问题带来了巨大的挑战。

　　深究根本原因，是因为服务质量分析系统在如此高压力、高吞吐的场景下，写入性能严重不足导致。腾讯会议和质量分析系统研发团队也一起对问题做了梳理。主要表现在以下四个方面：

　　下图展示了整个系统的架构图，红线上面部分是原先使用的质量分析系统。腾讯会议的质量数据，由上报接口机采集后到我们自研的接入服务，做数据清洗或转换的ETL过程，最后把数据写入到自研的 lucene 数据存储引擎里，提供数据查询和分析能力。

　　系统架构图

　　（1）可用性

　　原来的系统可能会遇到很多问题，首先在可用性方面，原来自研的 lucene 引擎是用 Java 写的，内存使用过多就会 OOM ，导致节点挂掉，进而造成集群的雪崩。这样 SLA 就难以保障，达不到 4 个 9 的要求，质量团队经常面临系统崩溃之后用户问题得不到及时跟进和解决的困扰。

　　（2）性能

　　第二个问题在于性能。疫情爆发之后，峰值系统写入量接近 300w/s，这个量是非常大的。由此造成了系统数据同步延迟比较高，大量数据堆积在里面长时间得不到消费。比如我们在前端查询用户的一些实时质量问题的时候，发现时延经常在半小时以上，这肯定无法达到我们的质量要求。

　　（3）拓展性

　　在出现如上问题的时候，大家通常做法可能就是去扩容。由于系统最关键的部分，是一个基于lucene自研的搜索引擎，扩容能力比较差，依赖于研发团队针对业务的优化。在数据量暴涨的背景下，不能进行快速扩容以满足需求。

　　（4）易用性

　　另外，在新系统选型切换的过程中，我们也要考虑易用性。用户数暴增，留给系统验证切换的时间非常短，这要求我们必须使用一种简单快速的解决方案。需要在一周之内输出适用方案，并进行线上数据的切换。

　　由于时间紧迫，新的方案需要尽量保留原有架构的大部分基础设施，并做尽量少的代码开发改动。

　　经过讨论，最终决定把原来这套架构切换成 Elasticsearch 比较经典的 ELK 架构。通过logstash的易用性和强大的生态插件，可以快速替代原有的自研数据接入组件，进行数据的清洗转换等ETL过程。如原有架构中使用的kafka，在logstash中就已经包含了相应的input插件。并且有大量数据格式的解析插件支持，对于数据的一些解析、过滤、清洗等操作可以直接在logstash的pipeline中进行简单的配置即可，基本上是0开发量。

　　丰富的各语言SDK，方便快速的对服务质量分析平台前后台进行快速切换，实际从代码修改到上线完成只用了一天的时间。