【腾讯云 Elasticsearch Service】高可用，可伸缩，云端全托管。集成X-Pack高级特性，适用日志分析/企业搜索/BI分析等场景

导语 | 随着业务的发展，系统日益复杂，功能愈发强大，用户数量级不断增多，设备cpu、io、带宽、成本逐渐增加，当发展到某个量级时，这些因素会导致系统变得臃肿不堪，服务质量难以保障，系统稳定性变差，耗费相当的人力成本和服务器资源。这就要求我们：要有勇气和自信重构服务，提供更先进更优秀的系统。

文章作者：刘敏，腾讯基础架构研发工程师。

前言

自今年三月份以来天机阁用户数快速上涨，业务总体接入数达到1000+，数据进入量更是迎来了爆发式上涨，日均处理量上涨了一个数量级：Trace数据峰值处理量达到340亿/日条，Log日志数据峰值处理量级达到140亿/日条。

面对海量数据，老的实时计算系统处理压力逐渐增加，底层存储系统无论在磁盘、IO、CPU、还是索引上都面临巨大的压力，计算集群资源利用率不高，系统的调整优化迫在眉睫。

• Tracing：一系列span组成的树状结构。每个span包含一次rpc请求的所有信息。从用户发出请求到收到回包，就是通过trace来串联整条链路。
• Metric：指标数据。是对可观测性指标的一种度量，例如请求数、qps峰值、函数调用次数、成功率、异常率、接口返回码分布等信息，可用作统计聚合。
• Logging：业务日志。   

三者互相重叠，又各自专注于自己的领域，将三者结合起来就可以快速定位问题。而已知的业界优秀开源组件有诸如：

• Metric: Zabbix、Nagios、Prometheus、InfluxDB、OpenCenus；
• Logging: ELK、Splunk、Loki、Loggly；
• Treace: jeager、Zipkin、SkyWalking、OpenTracing。

随着时间的推移可能会集成更多的功能，但同时也不断地集成其他领域的特性到系统中来。而天机阁正是腾讯研发的集三位于一体的分布式链路追踪系统，提供了海量服务下的链路追踪、故障定位、架构梳理、容量评估等能力。

最近第二代天机阁系统已经建设完成，新天机阁采用opentelemetry标准，可以支持更多场景的数据接入，同时在系统稳定性，数据实时性方面都有很大提升。

二、系统架构

从数据流转角度来看，天机阁整体可以分为数据生产链路与消费链路，其中数据生产链路主要包括数据接入层、数据处理层、数据存储层。整体如下图所示。

1. 业务背景

天机阁使用腾讯云的ES组件，专门用于建立热门Trace倒排索引，用户在使用天机阁进行链路追踪查询时，首先可以指定Tag或者染色Key查询到任意时刻上报的Trace元数据，天机阁会根据查询到的Trace数据绘制出完整的服务调用过程。同时在UI上可以支持瀑布、调用树的多种样式的数据展示。如下图所示：

天机阁是基于业务Appid维度按天索引的策略，而伴随业务量的极速上涨主要暴露出来的问题为：

（1）集群内部分片过多

磁盘使用率：53% => 40%。

写入拒绝率：索引写入拒绝率降为0。

集群宕机问题被修复:

查询耗时：大索引跨天级别查询在500ms左右。

分片数量：7万 => 3万，减少了50%，同时索引存储量优化了20%。

写入耗时：从2000ms => 900ms左右。

5. 优化二期

经过一期的优化ES写入性能有了明显提升，但还存在一些痛点，包括：

• 写入延时还是过大，没有达到预期效果。
• 分片数3万+ 还是过多，同时索引创建时间仍然过长（1分钟）。
• 索引容量管理以及生命周期管理困难。

6. 优化方案

（1）升级硬件配置

4C16G升级为16C 32G， 节点总数由64降为48，开启专用主节点。默认情况下集群中的任何一个节点都有可能被选为主节点，为了确保一个集群的稳定，当节点数比较多时，最好是对生产环境中的节点进行职责划分，分离出主节点和数据节点。

天机阁采用3（防止脑裂）台低配置的节点作为专用主节点，负责索引的创建、删除、分片分配等工作，数据节点专门用来做数据的索引、查询、更新、聚合等工作。

（2）ES集群分通道部署

目前天机阁只有一个公共集群，所有业务都在同一个集群中创建索引，这种方式虽然具备了一定的可扩展性。但是随着业务量的进一步增长，集群规模也会逐渐变的巨大，从而容易达到系统的性能瓶颈，无法满足扩展性需要，且当大集群中有索引出现问题时，容易影响到其他业务。

所以我们从业务维度对公共集群进行解耦，按通道做set化部署，将不同通道业务，就近路由到不同集群，各集群可按需灵活扩展。

（3）基于ILM + Rollover + 别名实现索引自动化生命周期管理与容量管理

天机阁是典型的日志型时序索引，根据应用Appid按天定时生成索引，索引的生命周期默认为7天，其中当天的数据会被频繁写入与查询，第二、三天的数据偶尔被查询，后面几天的数据只有少数重度业务使用者才会查询到。

这样的特性会衍生出来几个问题：

• ES索引分片数一旦创建便无法更改，这种机制无法应对业务忽然放量导致的索引容量激增的问题，通常只能通过手动Reindex来解决，而Reindex过程也会影响到业务写入性能。
• 根据日志索引存储具备的特点，不同时间阶段可以重新对分片数、副本数、Segment进行针对性调整，对冷数据进行归档处理，从而更好的利用机器资源。
• 需要创建额外的定时任务来删除索引，特别是当集群中索引过多时，密集型的索引删除操作，短时间内也会造成集群的波动。

我们希望构建一个优雅的索引自动化运维管理系统，而这个系统主要解决两个问题：

• 自动化索引生命周期管理： 创建索引生命周期管理，并定义不同阶段的索引策略，以此来实现ES索引自动化优化与生命周期管理而不需要引入第三方服务。
• 自动化索引容量管理：当集群索引超过设定容量大小时，可以自动进行滚动，生成新的索引，而上游业务不需要感知。

7. 索引自动化管理优化

ES在索引管理这一块一直在进行迭代优化，诸如Rollover、日期索引、Curator等都是对索引管理的一种策略，但是这些方式都不够自动化。

直到ES6.7以后，官方推出了ILM（index lifestyle management)索引生命周期管理策略，能同时控制多个索引的生命流转，配合索引模板、别名、Rollover能实现自动化索引生命周期与容量的管理闭环。

ILM策略主要有四个阶段：

• Hot阶段：可读，可写，索引会被频繁查询。
• Warm：可读，不可写，此时可对数据进行归档，采用Shrink与Forcemerge，减少索引副本与主分片数，并强制进行Segment合并，能够减少数据内存与磁盘的使用。
• Cold：不可写入，很久没被更新，查询慢。可对索引进行冻结操作，此时集群将对索引进行落盘操作，业务需要指定特定的参数才能查询到数据。
• Delete：删除操作。将触发索引删除事件。

8. 天机阁索引管理实践

天机阁使用ILM 策略配合分级索引模板可以比较优雅的实现索引的自动化管理过程。

ILM 策略主要分为四个阶段：热、温、冷和删除。对于定义好的各个阶段的相应策略，ILM 会始终顺序执行。我们只需要根据索引每个阶段的数据特性定义合适的管理方式，诸如：索引滚动更新用于管理每个索引的大小；强制合并操作可用于优化索引；冻结操作可用于减少集群的存储压力。

天机阁通过Flink Stream读取Kafka数据实时写入ES，峰值QPS接近35w，每天新增索引超过1000+。

在这么大数据量上进行操作是一件很麻烦的事。我们希望ES能够自动化对分片超过100G的索引进行滚动更新，超过3天后的索引进行自动归档，并自动删除7天前的索引，同时对外以提供索引别名方式进行读写操作。

这个场景可以通过ILM配置来实现，具体策略是：对于一些小于40G的索引，在Warm阶段执行Shrink策略压缩成单分片，并设定写入低峰期执行Forcemerge操作合并集群中小的段,Cold阶段可以执行Allocate操作来减少副本数，而针对集群内部1%的大索引，可以执行Freeze操作来释放部分存储空间。具体策略如下表所示：

天机阁索引ILM策略

索引模板配置

ILM可以高效的进行索引生命周期与容量自动化管理，使用起来也很简单。但是还是有不少要注意的地方。

• 切换策略后索引不会马上生效，旧数据仍然写入旧索引，只有触发Rollover生成新索引，新策略才会生效。
• 每个阶段的生效时间是以Hot阶段触发Rollover为起始时间的基础上再加业务配置时间。
• 如果不想使用Rollover，可以直接进行关闭，也可以实现只对索引进行生命周期的管理操作。
• 腾讯云ES最好采用 白金版 + 6.8以上版本。

后续优化：ILM + 冷热架构,ILM 可支持为时序索引实现热温冷架构从而节约一些成本。

9. 最终优化效果

• 写入耗时：2500万/min写入量 2000ms - > 320ms。
• 分片数量：7.2万 -> 2万 分片数量减少 70%。
• 索引存储总量：67T -> 48T 节约存储 30%。
• 创建索引速度：分钟级 -> 秒级。

七、优化后整体架构图

Flink实时计算系统是天机阁链路追踪平台的重要组成部分，数据经过Flink窗口进行实时计算聚合最终sink到ES与Hbase等底层存储，而日益增长的数据量给计算集群带来了很大的挑战。

面对这些问题，我们重新梳理了整个链路架构，找到系统的瓶颈所在，并展开了一系列有效的优化措施。而在未来，我们会继续在大数据领域的探索研究工作，更进一步的打磨系统数据处理能力，提供更好的服务。

整体从计算层、存储层、架构、服务质量等几个维度对系统进行了优化，同时也加强了系统的容灾能力

• 自定义计数器实现热Key自动发现与降级。
• 存储过载保护，当QPS超过压测阈值时，触发降级逻辑。
• 通过druid 预聚合方式完善对业务的多维监控。

结语

性能是用户体验的基石，而性能优化的最终目标是优化用户体验，俗话说：“天下武功，唯快不破”，这句话放到性能优化上也是适用的。

我们优化ES, Habse存储摄入速度，优化Flink的处理速度以及接入层的数据采集能力，都是为了保证数据的“快”。而优化的过程则需要我们做好打持久战的准备，既不能过早优化，也不能过度优化。

最好的方式是深入理解业务，了解系统瓶颈所在，建立精细化的的监控平台，当系统出现问题时，我们就可以做到有条不紊，从应用，架构，运维等层面进行优化分析，设定一些期望的性能指标，并对每次优化措施和效果做总结思考，从而形成自己的方法论。

最新活动

包含文章发布时段最新活动，前往ES产品介绍页，可查找ES当前活动统一入口

Elasticsearch Service自建迁移特惠政策>>

Elasticsearch Service 新用户特惠狂欢，最低4折首购优惠 >>

Elasticsearch Service 企业首购特惠，助力企业复工复产>>