本文翻譯自《Apache Pulsar: A Unified Queueing and Streaming Platform》，作者 Addison Higham。原文鏈接：https://thenewstack.io/apache-pulsar-a-unified-queueing-and-streaming-platform/
譯者簡介
Addison 是 StreamNative 主管工程師。本文譯者為劉梓霖 。
現在我們可以大膽宣言：種種跡象表明，Apache Pulsar 這個開源分布式消息系統正站在現代應用架構和開發的風口浪尖。
為什麼我們敢於這樣講呢？
隨着工程師團隊面對越來越複雜的挑戰，解決層出不窮的問題所需的技術和工具也在不斷發展。這其中常用的一種工具是消息傳遞。
消息傳遞基於消息隊列。消息在客戶端應用程序之間進行異步排列，由一個「broker」 充當各應用程序之間的媒介。
在早期的技術中，broker 是相對簡單的。但隨着實際需求的變化消息系統也隨之發生了變化。分布式消息系統便是建立在這個概念的基礎上，不僅具有可靠性、可擴展性和持久性的優點，且多個 「broker」 可以幫助分擔負載。
大多數的分布式消息系統支持一種類型的語義：流或隊列。從以往經驗看，每一種都有其最適合的特定類型的場景。Apache Pulsar 的獨特之處在於它同時支持流和隊列這兩種語義。
在探討使用統一的消息流系統帶來的優勢之前，讓我們先退一步，分別研究一下消息隊列和流技術。
流系統是行業中相對較新的創新技術，它可以以有序、低延遲的方式移動大量數據。流系統非常適合於移動數據（比如：日誌、指標或者點擊事件的數據等）並將其集中到一個位置，同時實現高並發和高吞吐。
舉個例子，比如從大型雲部署中的 10,000 台機器中獲取點擊或者指標數據。流系統為這一操作過程提供了便利。
某種程度上，消息隊列與流系統有些類似，即將多個系統鏈接在一起。然而，消息隊列歷史較久，而且更多地是關於點對點的通信，幫助廣泛的應用程序交換信息。
這兩種系統的訪問模式也是不同的：流系統專注於按照順序到達的消息和處理同一批的多個消息組，可能也用於聚合或轉換數據。
相比之下，在消息隊列中，事件通常是一次處理一個。就像在工作隊列中一樣，每個消息可能就代表某個特定的「任務」。換句話說，流用於移動和處理大量的數據組，而隊列往往是關於單個消息的精細化處理，以促進系統中的某些工作。
最常見的流平台是 Apache Kafka 和 AWS 的 Kinesis。最常見的隊列系統包括 RabbitMQ 和 ActiveMQ 。在雲上，還有 Google 的 Pub/Sub、AWS SQS 和 SNS。
Apache Pulsar：統一消息隊列和流
首先，簡單回顧一下歷史。
由於需要對非常大規模的工作負載進行隊列化，Yahoo 內部最初是在 2010 年左右開發了 Pulsar 。Yahoo 服務規模龐大，分布在許多不同的團隊和數據中心。
當時，他們正在使用 流行的 Java 社區標準Java 消息服務（JMS），這，就需要一個新系統既可以滿足 JMS 標準要求，又能具備分布式和可擴展性。
儘管 Pulsar 早期原型系統 API 最初專注於消息傳遞這一場景，但該系統的架構設計也使其成為流系統任務處理的理想方案，這使得 Yahoo 團隊能夠在更廣泛的場景下靈活使用該系統。
這項被稱為 「Cloud Messaging Service」 的服務在 Yahoo 內部落地非常成功，廣為人知。藉此勢頭，Yahoo 繼續在內部開發 Cloud Messaging Service，並於 2016 年將其開源，這就是 Pulsar 項目的由來。2018 年，該項目畢業成為為 Apache 軟件基金會的頂級項目。從此之後，Pulsar 在全球企業的落地迅速增長。原因顯而易見：許多企業如 Yahoo ，都需要更具可擴展性的消息系統解決方案。
雖然像 Apache Kafka 這樣的流系統有能力進行進一步的擴展 （在數據再平衡方面仍需要投入大量的人力）— 但其流系統的 API 功能仍然有些差強人意。它不僅要求開發者在純流模式的限制下工作，同時還要求開發人員學習一種新的思維和設計方式，這使得消息場景變得更加困難。
但有了 Pulsar ，情況就截然不同了。開發人員可以使用熟悉的 API， 以熟悉的方式工作；同時也提供了更多的可擴展性和流系統的能力。
同時滿足可擴展消息服務和流處理這兩個需求是我在 Instructure 的團隊面臨的挑戰之一。為了解決這個問題，我們發現了 Pulsar。
Instructure 的大規模業務場景需要高可擴展消息系統支撐。起初，我們試圖通過圍繞流系統技術架構來重新構建。機緣巧合之下我們發現 Apache Pulsar 可以幫助團隊在不需要基於流重新設計構架的複雜性的前提下去獲得所需要的消息系統能力。。
當 Instructure 團隊開始使用 Pulsar 時，Pulsar 的帶來的好處立竿見影，於是便在生產系統上開始大規模部署 Pulsar。Instructure 採用 Pulsar 後，應用程序之間的通信變得更加便捷，我們也可以在各個團隊之間共享數據。
然而，Pulsar 不僅能很好地解決消息工作負載，其所支持的流處理也是大多數企業內部存在的真正需求。Pulsar 提供了一個比其他流系統更容易使用、操作和集成的系統。
例如，Pulsar 高可擴展。當需要增加集群規模時，用戶不需要 「rebalance」 集群。它在支持多租戶和數百萬級主題的同時，也不會大幅增加延遲，這使得許多團隊可以輕鬆共享一個集群。
這意味着企業不再需要在研發自己的工具上投入大量精力。他們從而可以專注於從消息和數據中挖掘價值，而不是在管理基礎設施上浪費過多時間。
對於 Iterable （著名跨渠道營銷平台）來說，Pulsar 提供了可擴展性、高可用性來取代 RabbitMQ 並最終取代 Iterable 內部其他消息系統——包括 Kafka 和 Amazon SQS。正如 Greg Methvin 所指出，Apache Pulsar 不僅非常適合流處理場景，也非常適合消息隊列需求。
Apache Pulsar 優勢
已經採用了 Apache Pulsar 的人可能已經發現，與同類別的 RabbitMQ 或 ActiveMQ 等系統相比，Apache Pulsar提供了更具可擴展性的消息隊列功能，以及更多的可擴展和更易上手的的流系統功能（其內置功能包括跨地域複製和多租戶）。
值得一提的是， 使用 Apache Pulsar 是一個簡單的數學題：一個統一了流和消息隊列的平台比同時運維兩套流平台和消息隊列平台少至少一項技術。用戶只需要使用一種技術就可以更輕鬆地開發產品並將其推向市場，且更高效高質量地利用企業已有數據。
除了增加的 IT 成本和運維兩種獨立技術的支出外，流系統和隊列系統還沒有很好地集成，從而導致數據孤島現象的出現。而當擁有了一個統一的系統時，你可以處理更多事情，也可以基於同一底層系統打通各種數據和應用程序、數據查詢、數據分析、流系統等。
使用 Apache Pulsar 時無需將數據導出到另一個系統或團隊中，因為企業基於同一項中台技術、同一個中台存儲服務來囊括數據的整個生命周期，用戶不再需要手動處理數據生命周期的不同階段。有了 Apache Pulsar ，架構得到極大簡化，數據流轉和數據治理也更加輕鬆。
正如 Iterable 資深工程師 Greg Methvin 所總結的那樣，「Pulsar 的獨特之處在於它不僅支持流和隊列的場景，同時還支持更廣泛的功能。它已是我們目前使用的架構中其他分布式消息系統的替代品。此外，Pulsar 還涵蓋了我們對 Kafka、RabbitMQ 和 SQS 的所有使用場景，我們可以專心圍繞單個統一系統去構建專業知識和工具。」
使用 Apache Pulsar，魚和熊掌可以兼得。
▼關注「Apache Pulsar」，獲取乾貨與動態▼
👇🏻 加入 Apache Pulsar 中文交流群 👇🏻
留言列表