Pulsar Developer Day 2025 將於 12.6（週六）下午 13:30-18:00 在 北京·麗亭華苑酒店 舉辦。戳👇報名！

本文整理自 Zhangjian He 在 Community Over Code Asia 2025 上的主題演講。一起來看華為雲如何使用 Pulsar 構建高可靠訂閲和推送服務！

1

華為雲 IoT 架構

華為雲 IoT 服務採用分層的 Service on Service 架構。底層是基於 ECS 和 K8s 的雲底座，在此之上是物聯網基礎服務層，提供設備接入、IoT 邊緣等核心能力；再向上是行業平台層，服務於工業物聯、數字工廠等特定領域；頂層通過與 RDS、MySQL 等雲服務的組合，形成完整的行業解決方案。

為適應大模型技術的發展，平台對物聯網數據進行了分類處理：結構化的物模型數據存入知識圖譜，行業文檔等非結構化數據進入向量數據庫，時序數據則通過 MCP 方式供給大模型使用，實現了物聯網數據與大模型的高效協同。該服務的顯著特點是提供端到端的一站式開發能力，能夠有效支撐工業物聯平台、智慧交通平台等垂直行業解決方案的快速構建。

2

訂閲推送服務

訂閲推送服務的業務模型圍繞幾個核心概念展開：

• Tenant（租户）維度設計用於支持海量租户場景，單個租户能夠配置多個訂閲。
• EventRule（事件規則）定義了事件的過濾條件，例如處理開户、銷户或地域變更等業務事件。
• Action（動作）則指明瞭消息推送的目的地，可以是 OBS、遊戲服務器或 HTTP Server 等。

這套業務模型支持基於條件的過濾和多目的地分發，典型應用場景是將用户系統事件推送給第三方應用。一個訂閲單元被定義為一條 EventRule 與一個 Action 的組合，從而實現精細化的事件路由。

3

基於 Pulsar 的技術實現

基於 Pulsar 的 Function 和 Pulsar I/O 組件來構建訂閲推送功能，初始方案是利用 Pulsar Function 實現規則引擎的過濾邏輯，通過 Pulsar I/O Sink 完成消息的最終推送（Action 執行）。這一方案的優勢在於開箱即用，能夠快速實現核心功能。在生產環境實踐中，針對出現的挑戰迭代形成了優化方案。

計費和規格

核心挑戰：

過濾計算本身消耗實際的 CPU 和內存資源，但客户通常不願為被過濾掉、未成功推送的數據付費。在極端情況下，單個租户配置 10 條規則可能導致消息內部放大 10 倍。

優化方案：

• 合併消費者：將 N 個規則消費者合併為 1 個，以大幅減少內部流量放大。
• 性能隔離：用兩層 Worker 設計，由 Receive Worker 負責接收，Push Worker 負責推送，有效隔離了不同業務的影響。

Topic 老化機制

Topic 老化是必要的，其目的在於防止 Topic 數量達到上限導致新訂閲創建失敗，並避免非活躍消費組持續佔用磁盤資源。

在業務側進行了針對性適配，實現了“不存在則創建”的容錯邏輯，並補充了定時任務來觸發未使用 Topic 的老化。一個關鍵的注意事項是，只有被 ledger 處理過的 Topic 才會被納入老化機制。

私有云場景

在硬件環境相對較差的私有云場景中，偶現低概率的 entrylog 文件損壞問題（年均 1-2 次）。解決方案經歷了三個階段演進：第一階段嘗試跳過損壞文件，但需在消息丟失與恢復速度之間權衡；第二階段優化為優先讀取其他副本的數據；最終階段定位到 entrylog 寫入時的併發問題根源（相關修復代碼後續計劃貢獻給社區）。

定時任務處理

通過定時任務處理了幾類典型問題：

• 腦裂檢測：通過對比各節點 lookup 結果識別異常 topic
• 殭屍 ledger：清理已刪除但殘留的 ledger 元數據
• 分區不一致：修復 managed-ledger 與 admin 數據不同步

針對相關問題形成了通用的容錯策略：

• 重試機制+成功率監控：當成功率低於 80% 時觸發重建；
• 消費者健康檢查：當生產速率持續高於消費速率且積壓大於零時進行干預。

4

總結

關鍵設計：

• 規則引擎與推送模塊物理隔離
• 採用 listener 模式+合理超時配置（推薦 ackTimeout≥2h）
• 生產失敗時內存重試 1-2 次，超過閾值觸發 relocate

監控指標：精簡為 3 個核心指標（message in/out、積壓大小）

最佳實踐：開啓消費者自動老化，配置 retryLetterTopic 實現死信處理