HubSpot采用多Kafka主题（称为泳道）进行消息路由

HubSpot为了解决消费者组延迟堆积问题，并优先处理实时流量，采用了将消息路由到多个Kafka主题（称为泳道）的策略。通过结合自动和手动检测流量峰值，公司确保大多数客户的工作流程能够无延迟地执行。

平台概述

HubSpot提供了一个业务流程自动化平台，其核心是一个工作流引擎，用于驱动操作执行。该平台每天处理数百万个活跃工作流，执行数亿个操作，每秒处理数万个操作。

异步处理与Kafka的运用

大多数处理是异步触发的，使用Apache Kafka进行消息传递，从而实现了操作源/触发器与执行组件之间的解耦。平台使用多个Kafka主题来传递来自各种源的操作数据。使用消息代理的潜在缺点是，如果消息发布过快，消费者无法及时处理，将会出现消息堆积，称为消费者延迟。

挑战与解决方案

HubSpot的工程主管Angus Gibbs描述了确保消息处理近乎实时的挑战：当某一主题突然产生大量消息时，会形成待处理的消息积压。虽然可以通过增加消费者实例来扩展处理能力，但这会增加基础设施成本，且添加新实例需要时间，而客户通常期望工作流能够近乎实时地处理。

团队认识到，问题在于所有相同类型或来源的消息都使用同一个主题。考虑到平台被许多客户使用，如果一个或一小部分客户开始产生大量消息，所有流量都会被延迟，影响所有客户的用户体验。

泳道策略的实施

为了解决这个问题，开发者选择使用多个主题（称为泳道），并为每个泳道分配专用消费者池。最简单的应用模式是使用两个主题：一个负责实时流量，另一个负责溢出流量。两个泳道以完全相同的方式处理流量，但每个主题都有独立的消费者延迟，通过适当的消息路由，可以确保实时泳道避免任何（或显著）延迟。

自动与手动路由

在可能的情况下，基于从发布的消息中提取的元数据实现泳道间的自动路由。例如，某些批量导入的重新填充操作在消息模式中明确标记，路由逻辑可以轻松将这些消息发布到溢出泳道。此外，开发者引入了每个客户的流量限速配置，并根据消息消费者的最大吞吐量指标设置适当的阈值。

另一个决定如何路由消息的角度是查看操作执行时间。快速操作会路由到一个泳道，慢速操作则路由到另一个泳道。这对于HubSpot平台尤为重要，因为客户可以创建执行任意Node或Python代码的自定义操作。

最后，团队开发了手动将特定客户的所有流量路由到专用泳道的手段，以防某个客户的流量意外地在主要（实时或快速）泳道上造成延迟，且没有任何自动路由机制触发。这样，流量可以被隔离，团队可以着手排查延迟原因。