Apache Pulsar 是我們為了支持 STICORP 客戶應用而采用的一項關鍵技術。STICORP 是一家總部位於巴西的軟件公司。我們提供軟件解決方案來幫助 7,000 多家客戶管理和自動化他們的稅務報告，幫助他們確保稅務報告的合規性，避免處罰，並確定可以節省稅收的地方。這需要管理大量的稅務文檔，以及大量由客戶行為觸發產生的工作流程。這些稅務文檔包括發票，發貨和付款等。在一天內，單個客戶可能就會產生超過 200,000 個需要我們進行處理的稅務文檔。

我們的系統通過與客戶和政府系統進行集成自動獲取這些稅務文檔，並以便於客戶分析這些文檔背後的數據價值的方式組織它們。這些文檔的內容和復雜性取決於需要解決的特定業務流程。例如，有些文檔是基於發票，發貨訂單，和客戶與供應商之間的付款記錄等，而另外一些文檔是用於記錄這些活動完成時的附加文檔。

處理這些文檔中的所有不同信息需要一個包含多個步驟的工作流程。文件通常以加密形式到達，因此第一步是解密它們。然後將文檔中的 XML 格式的原始消息內容轉換為 JSON 格式。從那之後，這些文檔會被劃分到多個主題（Topic）並被丟到事件總線（Event Bus）上。其他工作流程會監聽事件總線，並處理這些文檔，最終將處理結構匯總到下遊的 Couchbase NoSQL 數據庫中，供其他應用程序訪問。

性能和可擴展性對我們來說至關重要。因為生成這些文檔的交易的天然性質，我們可以看到單個客戶在突發高峰時刻可能就會產生每秒 25,000 條消息。能夠支持大量主題對我們來說也很重要 - 能夠將文檔中的信息分解為多個主題，可以幫助我們更加輕松地組織和管理數據，將數據正確的分發和連接到相應的工作流進行處理；但這也意味著我們對於單個客戶可能就需要使用 30 個不同的主題。

為什麽我們需要新技術

我們最初使用 Apache Kafka 來實現事件總線。雖然我們有一個穩定的 Kafka 基礎設施，並且決定去做出基礎設施的改變通常並不容易，但我們意識到 Kafka 不是滿足我們需求的最佳技術 - Kafka 並不是為我們今天生活的雲原生（Cloud Native）世界所設計的，因此我們需要花費大量時間才能使其適用於我們的應用程序。

在尋找替代方案時，我們了解了 Apache Pulsar 並決定對其進行評估。由於 Apache Kafka 和 Apache Pulsar 使用類似的消息概念，因此我們看到 所有的 Kafka 用例可以使用 Pulsar 實現，其方式與使用與 Kafka 完全相同。兼容是促使我們切換到 Pulsar 的原因之一。

我們還註意到了 Pulsar 在架構設計上與 Kafka 的一些重要差異。一個關鍵的區別是 存儲和計算的分離 - Pulsar Broker 是無狀態的，與存儲相互分離；而在 Kafka 的數據直接存儲在 Broker 上。這是架構設計差異上的一個例子，它允許 Pulsar 能夠實現一些在 Kafka 上做很困難或不可能的事情。這其中的例子包括：

主題可擴展性：我們需要擁有超過 100,000 個主題（不考慮增長），這不僅有助於我們管理應用程序處理的不同類型的數據，還允許個別客戶使用自定義應用程序連接到系統中的數據。Pulsar 的架構可以輕松處理數百萬個主題。
性能：由於 Pulsar 的分層架構，以及 IO 隔離的特性，讀取和寫入使用不同的物理存儲。因此，讀取的峰值根本不會影響寫入性能，反之亦然。Pulsar 還支持非持久性主題，允許非常高的吞吐量，完全不需要持久性的主題，這對於實時應用程序非常有用。
消息隊列： Pulsar 提供了統一的消息模型，不僅支持類似 Kafka 的消費模式，也支持消息隊裏的消費模式。在不需要考慮有序性的應用場景中，Pulsar 可以直接當消息隊列進行使用。Pulsar 在訂閱（Subscription）級別而不是主題級別執行此操作，因為你可以在同一個主題中同時有按序消費的消費者和不按序消費的消費者，這對於很多場景是非常有價值。另一個場景，如果新的消費者需要從頭開始讀取一個主題裏面的所有消息，那麽對於 Kafka 來說，你將被迫要麽犧牲吞吐量，要麽重新平衡分區，或者要麽犧牲有序性。而使用 Pulsar，您只需添加新訂閱，Pulsar 就會將消息扇出到新增的消費者，以增加新消費者的吞吐量。
操作更簡單：使用 Apache Kafka，任何容量擴展都需要重新平衡分區，同時還需要將被平衡的分區重新拷貝到新添加的 Broker 上。使用 Pulsar，我們可以輕松添加和刪除節點，而無需重新平衡整個集群。此外，使用 Pulsar，你永遠不必擔心一個分區是否會超過 Broker 的物理磁盤空間；但是在 Kafka 中，一個分區的容量不能超過一臺 Broker 的物理磁盤空間。
無限的數據保留期：我們的一些客戶甚至需要在幾個月後訪問他們的文檔。我們希望能夠將數據保存在 Pulsar 中，而不會刪除它，並在以後需要時使用它。這樣我們不必重新從客戶或者政府部門導入數據，我們也不必擔心丟失消息。當我們需要使用新的一套系統來執行一個新的業務流程時，我們不需要訪問數據庫，我們可以簡單地將文檔從消息總線中拉取出並為新的業務流程重新處理它們即可。
由於 Apache Pulsar 提供了太多無法忽視的優點，我們決定實施並部署了 Apache Pulsar，在使用的過程中也對 Apache Pulsar 非常滿意。我們已經將超過 30％的生產數據流遷移到 Pulsar，並計劃在未來六個月內將所有數據流都遷移到 Pulsar。

喜歡小編輕輕點個關註吧！

為什麽已有Kafka，我們最終卻選擇了Apache Pulsar？