LinkedIn 开源 Iris 消息处理器，速度比旧系统快 86.6 倍

声明:本文来自于微信公众号 InfoQ（ID:infoqchina），作者:Eran Stiller，授权转载发布。

LinkedIn 开源“Iris 消息处理器”，该服务被用于增强其现有 Iris 事件升级管理系统（Escalation Management System）的性能和可靠性。iris-message-processor 的处理速度有了显著提升，相比之前的处理器，在平均负载下速度快4.6倍，在高负载下速度快86.6倍。

“iris-message-processor”是之前的 iris-sender 的分布式替代方案，支持更高的并发处理和直接将消息发送给目标供应商。它可以进行水平伸缩，并且不使用数据库作为消息队列，因而减少了对数据库的依赖。

iris-message-processor 可以处理大量的事件，经测试，它可以在不到10秒的时间内处理6000个事件，与之前的系统需要30分钟相比，进步巨大。即使在同时减少50% 节点的情况下，新处理器也保持了高效的处理速度，可以在不到30秒的时间内完成集群再均衡，并在不到3秒的时间内处理升级事件，即使是在高于平均负载的情况下。

为了提升性能，LinkedIn 将 Iris 升级事件拆分为桶，动态分配给 Iris 消息处理器集群中的不同节点，改进了并发处理和直接发送消息的能力。Iris 进行了重新设计，以应对未来“10倍”流量增长，避免在未来因需求增加时才匆忙进行改造。

_ 新 Iris 系统的架构（来源）_

新服务是用 Go 开发的。它不使用数据库作为消息队列，从而减轻了现有数据库系统的压力。新系统可以使用最终一致性数据库来存储结果消息进行审计跟踪，从而增强了可伸缩性。

LinkedIn 已经使用 iris-message-processor 大约一年时间都没有发生中断，并始终保持每毫秒处理1000条消息的 SLO。作为 iris-sender 的替代方案，iris-message-processor 不仅保留了现有的 Iris API，同时还提供了实质性的性能改进。

LinekedIn 的工程师采用了各种措施来确保上线期间的稳定性，包括保持向后兼容性和进行增量式验证和测试。

LinekedIn 已将 Iris -message-processor 开源，代码可在 Iris 和 Oncall 代码库中找到。这个工具可以在 LinkedIn 的环境之外运行，可以完全取代其他现成的事件管理系统。

InfoQ 采访了 LinkedIn 高级软件工程师 Diego Cepeda，聊了聊关于 iris-message-processor 的话题，包括它的实现和开源。

InfoQ:引入 iris-message-processor 后，资源使用（CPU、内存、网络带宽）发生了什么变化，这对运营成本有怎样的影响?

Diego Cepeda:实际上，资源利用率的变化可以忽略不计。LinkedIn 的关键监控基础设施具有非常高的容错冗余水平，因为我们认为可靠的监控是可靠运营的基础。

我们的 Iris 实例分布在不同的数据中心，每个数据中心都有足够的容量来处理整个站点的警报需求。不过，因为 Iris 足够高效，我们在每个数据中心只使用了3个实例，每个实例只配备了8个核心和32GB 内存，这些足够了。

每个数据中心有3个 MySQL 主机为 Iris 和 iris-message-processor 提供支持。值得注意的是，即使对于 LinkedIn 这样的规模，这样的配置也有点过剩，因为每个 iris-message-processor 实例平均使用不到5% 的 CPU 和不到1% 的内存。

InfoQ:你是否可以提供一些投资回报率 （ROI） 指标来证明 iris-message-processor 与其他现成解决方案在成本效益方面的差异?

Cepeda:我们没有与其他商业系统进行过比较或分析。不过，有大约6000名 Iris 内部用户积极待命，我们可以据此推测，使用现成的解决方案将是一笔相当大的投入。

我们确实有时间维度的比较，例如持续维护 Iris 所需的工作量，我们估计大部分时间都花在帮助我们的开发人员熟悉系统和回答问题上。

此外，我们没有专门为 Iris 投入人员资源，它只是监控基础设施团队负责处理的许多个服务中的一个。

Iris 已经为我们的整体投入带来了回报。对于选择使用 Iris 的组织来说，ROI 可能会更大，因为它们只会产生硬件和维护成本，并且可以从 Iris 的开源中受益。

InfoQ:你选择 Go 作为 iris-message-processor 的开发语言，这个决定背后的原因是什么?这个选择对系统的性能和可伸缩性有怎样的影响?

Cepeda:我们选择 Go 是因为它能够快速开发 Bug 少、高度可伸缩的并发应用程序。Go 的轻量级协程非常适合用来完成这项任务，因为管理并发任务变得很容易，避免了传统线程的复杂性。使用通道在程序之间进行通信增强了安全性和同步能力。

此外，Go 的标准库提供了并发、网络、分布式系统和测试用的包，减少了对第三方库的依赖，简化了开发。这些特性使得我们能够编写 Bug 更少的代码，支持高效的伸缩，并快速交付健壮的并发应用程序，如 iris-message-processor。

在过去的几年，我们一直在用 Go 语言逐步重写我们的大部分关键监控服务，并在开发速度、性能和可操作性方面获得显著的好处。一个典型的例子就是 iris-message-processor，它在高负载下的性能比之前的版本要好几个数量级。

InfoQ:你提到 iris-message-processor 已经在 LinkedIn 运行了大约一年时间都没有出现过中断，并且始终保持很好的 SLO。你能分享系统在高压环境下测试的例子吗?它的表现如何?

Cepeda:值得庆幸的是，LinkedIn 的系统都是相对可靠的，所以我们很少对系统进行真正的压力测试。当然，对于庞大而复杂的系统，出现故障总是不可避免的。我们曾经遇到过一个 DNS 问题导致我们的一个生产数据中心中的大部分服务（包括 iris-message-processor）无法访问时。

这是我们所见过的最接近高压的场景，数百个服务同时出现数千个警报，Iris 集群有三分之一的节点无法启动。

值得庆幸的是，我们在设计 iris-message-processor 时就考虑到了这种场景。

正如我们所计划的那样，集群可以丢弃不可达的节点，进行再均衡，并在不到60秒的时间内处理升级事件。以前的系统可能需要几十分钟才能完全解决这个问题，这会导致处理信息不及时，浪费了工程师发现问题和解决问题的宝贵时间。

InfoQ:随着 iris-message-processor 的开源，你希望社区可以带来怎样的特新和改进?你计划如何管理开源项目，确保它们与目标和质量标准对齐?

Cepeda:iris-message-processor 的核心思想是可伸缩性和灵活性。我们意识到这个世界上不存在两个完全相同的环境，在设计和实现中我们注意到了这一点。例如，我们目前使用 Twilio 发送语音和短消息，但其他组织可能使用不同的供应商。

我们没有对他们进行强制锁定，而是为消息供应商提供了一个可插拔的接口，任何想要集成到其他系统的组织都可以非常快速地编写出一个新的插件，并在对代码库进行最少变更的情况下启动并运行。

这种模式也体现在我们对存储系统的选择上。iris-message-processor 使用 MySQL 作为数据存储，当然也可以很容易地使用其他数据存储。所有与 MySQL 相关的代码都进行了抽象，这样就可以为不同的数据存储编写新的集成实现，而不需要修改代码的其他部分。这种设计使得拥有不同技术栈的组织更容易采用新系统。

对于已经开源的 Iris 和 Oncall 来说，项目的管理无疑是一个挑战。在这方面，我们采用基于测试驱动的开发和测试。为了确保与质量标准对齐，我们希望新的贡献代码是可测试的，除此之外，代码在被接受之前会在本地开发环境进行验证。

我们期待外部贡献者帮助我们把它变成一个更好、更容易使用的平台。

查看英文原文:

https://www.infoq.com/news/2023/09/linkedin-iris-message-processor/