微盟APM系统之数据流处理优化篇

作者：Aero

本文为原创，转载请注明作者及出处

背景

从2020年微盟 APM 系统大规模投入使用以来，微盟各个业务线的小程序的公众号的流量也百万级别上升了数倍。同时随着人均驻留时长大幅度提升、业务复杂程度大幅度加大，人均产生的调用链、运行时日志也较初上线时翻了三倍多。这就意味着，原有的 APM 系统架构要面对提升的流量，就会产生高额的费用。为此，我们计划将微盟 APM 系统（代号MARS - Monitoring & Automatic Reporting System）的数据处理架构进行优化和升级，目标是应对更高的流量并且降低服务端成本，同时也希望借此拓展 MARS 的功能、效率、以及灵活度等等。

架构对比

初版

上图为 MARS 的最初数据处理的流程图。从中我们可以发现，这个模式虽然存在直观、简单、开发成本低等优势，也存在以下问题：

1. Node.js 应用直接请求进入 ElasticSearch 导致流量没有统一收口

2. 统一化服务对机器要求高，且每次修改风险大

3. 数据进入 ElasticSearch 未做队列、聚合等处理，失败率高

4. 失败日志查阅不方便，难以定位问题

5. 没有合理的环境隔离

鉴于以上问题，我们认为需要对数据校验和消费进行分离，才能够在每次修改时做简单的增量发布，从而实现对接各种内部系统或者不同数据库实现如周数据环比等新的业务需求。在微盟，我们有一套非常成熟的基于 Kubernetes 的OMS 系统，我们在此简称 OMS Kubernetes。我们认为 OMS Kubernetes已有较为完善的 DevOps 和日志系统功能，还有比较良好的扩容能力（当然在消费者服务上为了避免新加入 consumers 引发 kafka rebalance，因此设置为手动扩容），因此新的系统应该被搭建在 OMS Kubernetes 之上，实现资源最大化利用的同时尽可能的复用已有的内部系统。

队列版

通过规划，我们认为新的系统可以按照以上描述的，从原有的直接从数据源发送数据并且写入 ElasticSearch 的模式修改为，由统一的网关服务生产、校验数据以后进入 Kafka，然后在消费者内对数据进行小队列的聚合和处理后再发送至 ElasticSearch 内。

通过以上系统的改造，我们首先能够获得服务器承压能力和成功率的大幅度提升。以下为老 APM 服务的压测结果：

从上图可以看出，老的 APM 系统的承压能力基本上取决于 ElasticSearch 的承压能力，在面临大规模流量访问时，虽然一开始可以维持2000+的 TPS，但是很快 TPS 大规模下降，并且响应速度非常不理想。最终在单台压力机，请求1分钟的情况下，虽然有多台黑石物理机为载体，就已经出现无法承压的表现，错误率1.57%，平均TPS 908，平均响应时间854毫秒。

上图为最终优化版本的新版 DEV 环境下的 MARS 系统（0.5核2GB Pod），虽然在 DEV 下的 Gateway 服务的载体性能较多台黑石机弱了数百倍，但是依然可以实现几乎相同的1.65%的错误率的 TPS 649，虽然平均耗时有较大的提升，到了2955毫秒。并且，新的服务没有出现之前1分钟不到就出现无法访问的情况，能够在高压下依然维持600上下的 TPS。

我们将相同的服务上线（结果见下图），设置为20个1核2GB的 Pods（固定配置，无自动扩容），得到了可喜的0错误，TPS 38073，平均耗时13毫秒的结果。实际上20个1核2GB的 Pods 在性能和费用上还远不上原先单台黑石物理机，更不要说是多台了。因此除了性能上新的架构较原有有了质的飞跃，成本上也有大幅度的削减。鉴于此，我们将线上的扩容能力设置为20-100（实际上我们认为初始为10台可能已经可以满足90%以上的业务场景）。

当然，在多次压测过程中，我们发现了 Node.js 服务的一些缺陷。如 Node.js 可以在短时间内接收大量请求，并且响应速度极高，但是在收到一定的请求以后会进入“装死”模式，既对新的请求不作出任何响应，直到 CPU和内存占用降低到一定的比率下。

结论

鉴于这个问题的存在我们做出了以下的性能优化改进：

• 有效

1. 提升 OLD 内存使用

2. 判断同时处理的异步请求达到阀值后切换为同步响应

3. 允许更长的监控检测响应时间

• 无效

1. CPU 占有率提高后切换为同步响应

2. 内存占有率提高后切换为同步响应

3. 连续网络请求达到阀值后切换为同步响应

4. CPU 占有率或内存占有率提高后切换为同步响应

5. 5+6+7的权重算法

我们认为在 Node.js 对系统性能的技术可能因为其 Runtime 特性和实际请求时的 event loop 处理逻辑是脱钩的，因此出现了5、6、7、8、9方案无效的情况。使用 actix 框架（Rust）编写的程序在和 DEV 相同配置的的 Pod（0.5核2GB）内可以避免错误率的出现，并且响应时间有明显降低，但是鉴于现有的 OMS Kubernetes 并不支持 Rust 应用，且其生态相对于 Node.js 应用不是非常成熟，因此我们将服务端逻辑由 Node.js 往 Rust 的迁移定到了下一期的规划内。