本文翻譯自《Apache Pulsar: A Unified Queueing and Streaming Platform》，作者 Addison Higham。原文連結：https://thenewstack.io/apache...
譯者簡介
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 中文交流群 ??
