再見了Kafka，MQ新王Pulsar大廠實踐！

本文介紹公司選擇 Apache Pulsar 的原因，使用 Apache Pulsar 的場景，Apache Pulsar 實踐應用中遇到的問題及使用 Apache Pulsar 的未來規劃。

1 背景

傳統金融公司或券商一般使用統一接入服務或元件來處理對外業務。接收到使用者請求後，根據業務規則將請求轉對應業務系統 / 模組。有些請求會轉發給MQ，請求寫入後，下游業務系統從MQ獲取請求，並在處理後透過MQ原路返給客戶，整個請求過程封閉執行，功能有限。

1.1 訊息佇列下傳統架構帶來的挑戰

採用上述傳統架構，目前只支援MQ，但難以獲取MQ細節。由於是定製系統，支援語言有限。現有MQ對業務發展和業務創新不足：

• 黑盒系統，難觀測，MQ是黑盒系統，難觀測到架構細節
• 直接交換（Direct Exchange），無法路由：由於架構目前只支援MQ，無法支援需要路由的場景
• 弱校驗接入，安全風險高：現有系統的密碼認證、校驗等檢驗較弱，安全風險高
• 定製系統，有限語言支援：定製系統接入語言的支援有限，導致我們選擇範圍少，難以在原有系統基礎上改造

隨業務擴充套件和架構改進，公司現有MQ系統 / 元件面臨挑戰，而系統現存問題如安全性等在金融場景中刻不容緩。

2 金融場景的業務需求

業務需求主要三類：

2.1 身份識別 & 安全控制

身份識別，主要用於確定接入訊息佇列的客戶端和接入者的身份資訊，指定相應的安全規則，拒絕不合法接入者，進而實現預期的安全要求。從最基礎的層面看，需要識別控制接入的系統、IP，根據業務場景及特定需求，進行許可權限制。

2.2 路由分發

指訊息根據規則由寫入佇列路由至對應的佇列。現有MQ支援場景有限，若想支援更多，需投入大量時間精力開發（涉及上下游系統改造），同時引入其他問題。較好解決方案是MQ系統原生支援更多模式及特性，如 TOPIC 模式、流式訊息處理。若MQ系統支援路由，則系統的接入複雜度大大降低，可透過更優方式操作接入層，每個系統只需要對接一組 topic，路由負責分發；也可更有針對性最佳化效能（路由、轉發、協議轉化都是消耗效能的操作）。

原系統架構通訊機制是點對點，封閉執行，請求訊息無法共享，只能間接採用介面卡或日誌採集方式實現分發，此類做法難以有效滿足實時性要求。

2.3 審計

訊息釋出者 / 接收者都屬於整個系統的參與者，且是重中之重。系統安全性主要影響系統的所有參與者；因此，從安全形度出發，對訊息審計要求較高。另一急迫需求是對訊息流向控制。若可進行身份識別和安全控制，則可在審計時完善和最佳化安全資訊，進而保證在業務入口處拒絕無效、非法請求，保證內部系統健壯。記錄接入的訊息釋出者 / 接收者資訊還可用於異常情況監控、稽核審計。

3 新增業務的系統需求

新增業務對訊息系統提出更高要求，主要包括可用性、訊息傳送延遲、擴縮容、訊息回溯。

3.1 需求一：高可用、低延遲

網際網路行業，高可用低延遲是系統基本要求。從單點到災備，到同城跨機房，再到異城跨多中心或先跨城、災備，再跨城多中心（兩地三中心）模式都已常態，很多公司業務系統正在或將往此發展。這樣的系統對高可用、低延遲要求較高。因此需考慮當系統複雜度增加（如災備、跨城等場景）時，如何將延遲降到最低。

3.2 需求二：快速擴容與恢復

金融業業務主要特性之一是請求可能在某時間段或某個週期激增，過了這個時間視窗，流量逐漸正常。該特性要求系統可快速橫向擴縮容，出於成本考慮，按最高流量部署整個系統架構顯然不合理。最好解決方案是系統可根據單層流量合理安排系統架構或系統部署方式，在流量突然增加時，系統可快速擴容，支撐業務。最理想的情況是系統的所有元件都有快速擴縮容、恢復能力。

3.3 需求三：訊息有序、訊息防重

一些場景需保證訊息有序或防重。經常對一些介面進行冪等操作，若可保證上游訊息不重複，就可減小下游壓力。

3.4 需求四：可回溯、序列化

若業務系統出現問題，但測試環境難復現，就要引入訊息回溯，即重放一遍出現問題的時間視窗中的所有請求，驗證是否能復現並排查，這可大大減輕排查工作量。

還可以此進行灰度驗證和並行驗證。

4 選擇 Apache Pulsar

明確業務需求和系統需求，發現 Apache Pulsar 完美契合。

4.1 叢集模式

支援跨叢集同步。建設系統雙活，跨叢集的地域複製在客戶端無感的情況下實現訊息同步。

4.2 算存分離

根據使用情況橫向擴充套件儲存 / 計算，客戶端對此操作無感知。基於二級儲存，擴充套件訊息的使用場景，為資料分析、訊息審計提供可能。

4.3 客戶端接入認證模組外掛化

支援自定義開發。因業務需求，在客戶端接入時，要求鑑權、認證，有效保證訊息的來源可靠、可控。

4.4 完善的 Rest API

可檢視佇列情況。之前使用的訊息系統有很好效能，但可觀測性欠缺，排障困難，同時訊息系統管理方式原始，難適配大規模系統管理要求。而 Apache Pulsar 完善 Rest API 不僅可獲取系統執行指標，且有助叢集高效管理。

4.5 Functions

基於 Functions 可實現訊息的路由開發、過濾和統計等。

4.6 訊息重放

可設定訊息的持久化模式和過期時間，允許訊息重放。

4.7 多語言支援

快速便捷接入。

5 Pulsar業務實踐

使用 Apache Pulsar 構建統一訊息平臺，期望整合客戶、交易、行情、資金四大資料流，應用於行情分發、實時風控等。本文主要介紹應用場景下的新架構的優勢和不足，以及其對開發、運維影響。

5.1 請求路由——簡化系統

訊息路由流程如圖。從 A 元件發請求寫入 Topic A，然後路由模組將 topic 資訊路由，分發到多個對應 topic，訂閱這些 topic 的下游元件就可處理相關訊息。元件 A 只需向固定佇列寫訊息，無需關注 Topic B、C、D 資訊，下游系統只需瞭解接收訊息的佇列，無需關注 Topic A，從而簡化整個網路結構。

這種訊息路由模式簡化了系統整體架構，目前路由系統仍待最佳化：

• 雖路由分發的工作量減輕，但排查問題步驟增加。如元件 A 發訊息後，元件 B 未收到訊息時，需先檢查元件 A 是否寫入 Topic A、路由模組是否成功路由該訊息，再看元件 B 是否正確訂閱該訊息
• 目前測試效果看，由於訊息鏈路變長，時延增加
• 由於每個佇列的訊息都會持久化，導致儲存和佇列中都出現資料冗餘
• 路由模組是新增模組，運維學習成本高

5.2 資料廣播——降低時延

資料廣播採用傳送 / 訂閱模式，用於同步訊息。之前不需要同步行情到業務系統或透過其他方式（如同步資料庫）實現。但隨業務增長，同步時效和使用者體驗競爭度越來越激烈。如何讓使用者更快看到資訊？以同步行情場景為例，先同步資料庫再查閱的方式，時延相對較長；而廣播模式的業務系統只需訂閱所需 Topic，查閱時即可直接讀資料，有效降低時延。

5.3 訊息通知——安全管控

雖訊息通知涉及業務較少，但這業務場景很重要。整體業務流程圖如下。由於訊號源不唯一，因此訊息釋出到計算引擎後，計算引擎需根據訊號源的資訊進行邏輯、安全等計算。計算完成後調起Task，再由啟用的 Task 向相關業務系統發業務請求，執行後將結果返給發起訊號源的服務，該服務根據返回的結果觸發下一個訊號源。

該場景涉及業務對安全和管控要求嚴格，不僅要限制訊號源傳送的訊息或訊號，截斷 / 過濾某些訊號，還要對返回結果處理：哪些可返回，哪些要過濾或轉換成其他內容。如不使用MQ，訊息源會直接發訊息給計算引擎，在計算引擎執行安全或管控策略後，將訊息發到 Task；Task執行完成後，其結果要再進行一輪安全管控處理。這部分重複操作對效能影響大，同時策略更新、訊號狀態檢視的時效性沒那麼實時。

引入Pulsar後，將管控審計模組剝離，專門針對訊號佇列和結果佇列進行過濾、審計、統計，並實時輸出結果到管理端。運維或審計人員看到這些資訊後，可控制、更新相應策略。這模式不僅精簡資料流，還可增加資料補充渠道，也更清晰定義各服務模組邊界。

6 問題發現與解決方案

6.1 實現 REQ-REP 模式

透過匯流排模式進行相容。

常見呼叫方式是客戶端發起呼叫請求，服務端處理完成後返回響應。但引入匯流排（同步轉非同步），在多節點部署場景，節點 1 發請求，服務端收到請求後返回處理結果，所有節點都要監聽這條處理結果，節點 2 收到歸屬節點 1 的響應訊息時咋處理？節點 2 要先訂閱並獲取回包的訊息，判斷是否自身節點發起請求的響應，若不是，則丟棄該訊息。若按這模式實現，則發訊息時，每個節點都要快取自身傳送的訊息 ID；服務端處理完後，按協議回包資料要帶上請求的訊息 ID，每個節點都訂閱獲取所有回包，並校驗快取中是否有該訊息 ID，若不存在，則丟棄訊息。

該實現存在嚴峻問題：節點發起一個查詢大量資料的請求時，假定 Apache Pulsar 設定一個訊息大小為8M，TPS 為 1000，那是不是每個節點都要收到這麼多請求的回包流量呢？假如有 5 個節點，每個節點本應該只接收 200 個請求的回包流量就夠了，但現在的模式需要每個節點承受 1000 個請求的回包流量，而其目的僅僅是為了過濾操作。如果節點負載效能達到上限，需要擴容節點，將導致網路頻寬成倍增加。由於 Apache Pulsar 可以支援大量 Topic，雖然透過給每個節點配置一個回包佇列等方式可以解決這一問題，但我們想嘗試透過 broker 的 FILTER 功能，來解決該問題。

6.2 實現讀寫分離

廣播場景涉及讀寫分離。若增加大量訂閱節點，最好避免將所有節點的連結集中在 Topic 的 owner broker。針對該問題，可行的解決方案是合理分配使用的 Topic 和 Partition。

Apache Pulsar 2.7.2 還不支援讀寫分離，Apache Pulsar 升級到 2.8就可輕鬆實現讀寫分離，滿足訊息廣播。

6.3 解決多網路卡問題

基於公司網路安全考慮，內部存在多種網路分割槽及網段，不同的網路分割槽 / 網段使用不同IP，伺服器存在多個網路卡，供跨分割槽系統間通訊。目前若使用 IP 註冊 broker，只能註冊某網段的 IP；如果使用域名註冊 broker，則不同網路區域的 DNS 解析又需要進行不同的配置。若broker支援多網路卡通訊，這些問題就沒了。目前解決方案是用 proxy 代理客戶端的請求，外部系統也只連到 proxy，我們也會為 proxy 增加一些高可用配置。

7 容災

先在單機房、單叢集小規模執行。作為業務系統的基礎設施，Pulsar自身可用性極為重要，建設同城雙中心單叢集的雙活規劃：