作者 | Rafal Gancarz
譯者 | 張衛濱
策劃 | Tina
HubSpot 採用在多個 Kafka 主題（稱為泳道，swimlanes）上為同一生產者路由消息的方式，避免了消費者群組滯後的積壓，並且能夠優先處理實時流量。通過自動和手動相結合的方式探測流量峰值，該公司能夠確保大多數消費者的工作流能夠在無延遲的情況下執行。
HubSpot 提供了一個業務流程的自動化平台，其核心採用工作流引擎來推動操作（action）的執行。該平台可以處理數百萬個活動的工作流，每天執行數億個操作，每秒執行數萬個操作。
工作流引擎概覽（來源：HubSpot 工程博客）
大部分處理都是異步觸發的，使用 Apache Kafka 進行傳遞，從而實現了操作的源 / 觸發器與執行組件之間的解耦。該平台使用了許多 Kafka 主題，負責傳遞來自各種源的操作數據。使用消息代理的潛在問題在於，如果消息發布得太快，而消費者無法及時處理，等待處理的消息就會積壓，這就是所謂的消費者滯後（consumer lag）。
HubSpot 的工程主管 Angus Gibbs 描述了確保近實時處理消息所面臨的挑戰：
如果在主題上突然出現大量消息，我們就必須處理積壓的消息。我們可以擴展消費者實例的數量，但這會增加基礎設施成本；我們可以添加自動擴展，但增加新的實例需要時間，而客戶通常希望工作流能夠以接近實時的方式進行處理。團隊認識到，他們需要解決的問題是對所有相同類型或相同來源的消息使用了相同的主題。考慮到該平台被許多客戶使用，如果某一個或一小部分客戶開始產生大量消息，那麼所有的流量均會延遲，所有客戶的用戶體驗都會受到影響。
如果在主題上突然出現大量消息，我們就必須處理積壓的消息。我們可以擴展消費者實例的數量，但這會增加基礎設施成本；我們可以添加自動擴展，但增加新的實例需要時間，而客戶通常希望工作流能夠以接近實時的方式進行處理。團隊認識到，他們需要解決的問題是對所有相同類型或相同來源的消息使用了相同的主題。考慮到該平台被許多客戶使用，如果某一個或一小部分客戶開始產生大量消息，那麼所有的流量均會延遲，所有客戶的用戶體驗都會受到影響。
為了解決這個問題，開發人員選擇使用多個主題，他們將其稱為泳道（swimlanes），並為每個泳道配置專用的消費者池。應用這種模式的最簡單方式是使用兩個主題：一個負責實時的流量，一個負責溢出的（overflow）流量。這兩個泳道以完全相同的方式處理流量，但是每個主題都有獨立的消費者滯後，通過在兩者之間適當地路由消息，可以確保實時泳道避免出現任何的（或明顯的）延遲。
Kafka 泳道（來源：HubSpot 工程博客）
如果可能的話，系統會從發布的消息中提取元數據，基於此在泳道之間實現消息的自動路由。例如，批量導入所產生的消息可以在消息模式中明確標記出這種操作類型，這樣路由邏輯就可以輕鬆地將這些操作發布到溢出泳道。此外，開發人員還引入了按客戶配置來限制流量的功能，並且能夠根據報文消費者的最大吞吐量指標設置適當的閾值。
決定如何在泳道之間路由消息的另一個角度是查看操作的執行時間。實際操作將被路由到一個泳道，而慢速操作將被路由到另一個泳道。這一點對 HubSpot 平台尤為重要，因為客戶可以創建執行任意 Node 或 Python 代碼的自定義操作。
最後，該團隊還開發了將特定客戶的所有流量手動路由到專用泳道的方法，以防來自客戶的流量意外地在主（實時或快速）泳道上造成滯後，而此時自動路由機制均未啟動。這樣，在團隊排查延遲原因時，就對流量進行隔離了。
英文原文：
How HubSpot Uses Apache Kafka Swimlanes for Timely Processing of Workflow Actions (https://www.infoq.com/news/2023/11/hubspot-apache-kafka-swimlanes/)
軟體開發「食物鏈」：運維竟高於開發，最頂端該是用戶還是管理層？
滴滴 P0 事故，K8s 背鍋？拼多多正式登頂中國電商巨頭，馬雲阿里內網罕見發言；學霸女兒創業AI項目火了，老爸公司漲停｜Q資訊
ChatGPT 一周年：生成式 AI 出現後，我決定以後砸鍋賣鐵都不讓後代當程式設計師了
亞馬遜 CTO 20 年架構經驗之道：儉約架構師的七大黃金法則！