關於 Apache Pulsar
Apache Pulsar 是 Apache 軟體基金會頂級專案，是下一代雲原生分散式訊息流平臺，集訊息、儲存、輕量化函式式計算為一體，採用計算與儲存分離架構設計，支援多租戶、持久化儲存、多機房跨區域資料複製，具有強一致性、高吞吐、低延時及高可擴充套件性等流資料儲存特性。
GitHub 地址：http://github.com/apache/pulsar/
當新生事物出現時，人們總是有兩種角度去觀察它，要麼把它看小，要麼把它放大。
對於 Apache Pulsar 來說，把它看小的角度通常是“Apache Pulsar 只是一個新的訊息佇列而已“，或者“Apache Pulsar 只是一個新的資料管道而已”，又或者是“佇列系統早就有了，只是 Apache Pulsar 更具擴充套件性也能解決某些場景問題而已，基本沒啥本質區別”。
那麼，事實果真如此嗎？
帶著這些問題，InfoQ 記者張浩在 QCon 2021 全球軟體開發大會（https://qcon.infoq.cn/2021/be...）上採訪了 StreamNative 聯合創始人、Apache Pulsar 和 Apache BookKeeper PMC 成員翟佳，和他聊了聊 Apache Pulsar 的歷史、特點以及未來的趨勢。
點選連結 ，檢視公眾號視訊採訪的全部內容，為方便讀者檢視，視訊下方也附上了文字內容。
InfoQ：翟老師，你好，歡迎來到 QCon 大會並接受我們的採訪，請您先自我介紹一下吧。
翟佳：主持人好，我叫翟佳，來自 StreamNative，現在主要是做 Apache Pulsar、Apache BookKeeper 相關的設計和開發，也是這兩個開源專案的專案管理委員會成員。更早之前，我還在 EMC 做過分散式檔案系統的設計和開發。
InfoQ：我在 Pulsar 官網上看到它是這麼定義的，它說 Pulsar 是一個雲原生的分散式訊息和流平臺。在中文媒體的很多宣傳裡，對於 Pulsar 的定義怎麼說的都有，我姑且就把它理解為是一個新一代的 Kafka。那麼很多公司其實是把 Kafka 當成訊息系統使用的，所以我想請你來聊一聊，這些年來開源訊息系統都經歷過怎樣的迭代？
翟佳：你剛剛提到的訊息系統確實是 Pulsar 誕生的一個初衷，因為在 2011 年、2012 年的時候，在雅虎內部需要解決的就是一個訊息系統統一的問題。當時比較流行的 ActiveMQ、RabbitMQ 在雅虎內部也都有使用，所以 Pulsar 誕生的一個場景也是做內部的一個統一，要替換 ActiveMQ、RabbitMQ 這樣的訊息系統。也就是你剛才提到的 MQ 的場景需求。
你剛才也提到 Pulsar 是雲原生的，這跟它當初誕生時雅虎的環境有關。雅虎當時是 Hadoop 生態的一個主要締造者，它是先有的底層的儲存層，也就是 BookKeeper 這樣一個專案。我們之所以說它雲原生也是因為 Pulsar 採用了一個儲存和計算分離的這樣一個架構，儲存層就是我們剛剛提到到 BookKeeper，BookKeeper 它在雅虎內部主要是解決 Hadoop 生態，也就是 HDFS、NameNode 這樣的一層 HA。你可以認為它是做後設資料的儲存，所以它有很高的一致性。剛好它又是一種 Log 的抽象，就是用 append-only 的模式，它跟我們提到的 MQ 的場景很類似，新的訊息不斷地追加，然後這個模式剛好可以應用在訊息這個領域裡面，所以它對雲原生路線的選擇跟它的技術背景有關係。就是先有了很優秀的、能夠提供很好服務質量的儲存系統，然後才有了 Pulsar 這樣的儲存和計算分離的架構。
有了這樣的系統之後，它由於有儲存和計算分離的架構，有 Write-Ahead-Log（WAL）儲存層的抽象，它不僅可以支撐很多 MQ 的關鍵業務場景，不丟訊息，對一致性要求很高，又可以提供比較高的頻寬、比較低的延遲。所以這是很多使用者把它用在原來 Kafka 的場景裡面的原因。可能最開始的選擇是 MQ 的方向，但是由於架構、由於本身儲存層的特性，也會用到一些 Kafka 的場景裡面，這是它跟 Kafka 的關係。
InfoQ：剛才你提到 Pulsar 是誕生於雅虎，你能更詳細的介紹一下這個專案誕生的背景嗎？這些年 Pulsar 發展得怎麼樣？
翟佳：Pulsar 的誕生我們剛剛提到過一點，開始做這個專案是在 2012 年，在當時，2011 年國內誕生了 RocketMQ，再往前一年，2010 年誕生了 Kafka，然後 Pulsar 在 2012 年誕生。
在 2012 年要選擇雲原生的儲存計算分離的架構是一個很有挑戰的事情。因為當時單個節點的網路卡，單個節點的磁碟可能都不適合雲原生這樣的架構。所以在 2012 年之前，也就是 2010 年下半年到 2011 年，雅虎內部做了一個 Pulsar 的原型系統，它叫 HedWig。它主要是做這樣的一個嘗試：就是儲存計算分離這樣的架構能不能服務於訊息這個場景。所以它誕生可能更早一些，先有 HedWig 這樣一個原型系統，然後再立項 Pulsar。Pulsar 開源之前在雅虎內部的代號叫 CMS（Cloud Message Service），所以說它最開始誕生的初衷就是要做一個雲的訊息的服務。
有了前期原型系統的鋪墊，決定了雲原生這個路線之後，再往後 2013 年主要是做功能開發，2014 年開始在雅虎內部大規模部署，在雅虎內部經過線上產品的檢驗，又穩定執行了一兩年以後，在 2016 年開源出來，2017 年捐給 Apache 軟體基金會，2018 年從 Apache 軟體基金會畢業成為頂級專案。
捐給 Apache 軟體基金會之後，這個專案就開始了一個快速的發展期，很多國內外的網際網路公司都開始使用 Pulsar，因為它確實解決了 MQ 場景裡的問題，也解決了 Kafka 場景裡面的一些問題。
特別是在 2019 年有了我們商業化的公司 StreamNative 的成立，使用者對這個專案就更有信心了。包括騰訊最開始上線的一個很關鍵的業務場景，就是騰訊計費平臺，也都是基於 Pulsar 來做所有計費的業務。還有國外的 Splunk 以及雅虎內部也有很多的場景都使用了 Pulsar，這樣 Pulsar 的生態也隨著我們國內外社群不斷地成長，發展得越來越好了。
在 2018 年成為頂級專案之前，GitHub 的 Star 數增長雖然還好，但不是那麼顯著，在 2018 年底變成頂級專案之後，2019 年公司（StreamNative）成立，Star 數的增長就更加迅速了。我覺得國內的開源土壤對我們開源社群的構建，對我們開源專案初期的成長有很大的幫助。
InfoQ：我看到網上很多人對比 Kafka 和 Pulsar，包括剛才我們也做了一個對比，那你怎麼去看待這兩個技術呢？
翟佳：我們剛剛也提到，Pulsar 專案誕生的背景就是要解決雅虎內部的需求。它要有大叢集、多租戶的能力，能讓雅虎內部各個業務部門的資料打通，所以它誕生的初衷不是為了去做 Kafka 的事情，大家都在同一個時代。
而且在 2012 年 Kafka 也沒有像現在這麼火，Pulsar 還是從自身的角度出發，就是要解決雅虎內部的問題，然後就有了這樣的產品。之後它又選擇了開源的路線，讓產品變得更加穩定，能夠藉助社群給它新增更多的功能。所以說它最開始不是專門針對 Kafka 而設計的，但是誕生之初，它的設計為了解決自身的問題，會考慮到更豐富的應用場景，考慮自身業務的一些需求，所以說它確實也能夠支撐 Kafka 所對應的一些業務需求。自然而然地，在開源之後，可能它解決了 Kafka 使用者的一些痛點，被一些使用者所選擇，但這是一個自然而然的過程，並不是專門針對 Kafka 來做這個事。
InfoQ：郭斯傑之前說過，訊息、流、儲存將會逐步融合，你怎麼理解這個觀點呢？
翟佳：剛剛提到三個方向，訊息、流和儲存。我發現訊息和流是很相關、模式也很類似的兩個系統，你的訊息也是需要一個載體來提供訊息的儲存和服務，訊息進來的模式也是要按照時間、使用者的資料等等固定的順序，這樣才能對外提供順序性和一致性的保障。
流的場景也是一樣，所有的資料來源源不斷地流入，然後按照時間順序來做一個消費，所以從這個角度來看，它們兩個是很貼近、概念很類似的一個場景。只不過在之前可能由於技術架構的原因，我們把訊息和流分成了兩種模型。在很多企業內部關鍵的業務場景裡用各種 MQ 來保證訊息的服務，在資料管道這種場景下用 Kafka 提供流的服務，但是本質上來說它們都是一樣的，只是之前由於技術原因，把它們天然做了一個分隔。
Pulsar 的一個優勢是它有很好的底層儲存層 BookKeeper，它既可以保證很高的一致性，也可以通過 append-only Write-Ahead-Log（WAL）這種抽象來保證比較高的吞吐，它可以從技術上解決兩個場景不同的需求，所以 Pulsar 從這個角度提供了很好的訊息和流的融合。
在儲存這個方向，之前大家可能把訊息的儲存這個事情看得有些太簡單了，有很多使用者認為我的訊息要做系統解耦，在 MQ 的場景裡面，可能有很多的訊息都是從記憶體裡直接就把訊息消費完了，很少有需要把訊息落地、儲存的場景，所以當時的實現都很簡單，包括 Kafka 在內，大家都是把訊息直接落到檔案系統裡面，怎麼簡單怎麼實現，這樣對很多關鍵的業務場景，對很多需要資料堆積的場景來說，如果單單依靠一個檔案系統來做，你的服務質量，你的穩定性可能就不太容易保障，因為檔案系統不是專門為這個場景設計的，比如說你在 MQ 場景，我需要實時地刷盤，我需要保證這個資料永續性，它的備份數以及一致性要足夠高，這個場景下它的效能可能就會降下來了，這也是我們說隨著使用者的應用資料場景不斷豐富，隨著你對訊息系統的要求不斷提高，它對底層訊息系統的一些要求也會改變。所以現在來看，隨著大資料的發展，隨著使用者資料量的提高，Pulsar 真正發揮了它的價值，它有一個專門為訊息做的儲存層，有了這樣一個儲存層，它可以跟我們剛剛提到的訊息的服務、流的服務能夠很好地結合起來。
所以說訊息、流和儲存在 Pulsar 這邊是一個融合的方向，是一個融合的架構，這是我們從 Pulsar 這個角度來看這三個方向時一個很直觀的感受。
InfoQ：Pulsar 之所以敢說它是新一代的訊息系統，那它肯定是順應了一些趨勢，除了前面的訊息、流、儲存的趨勢外，你們還看到了什麼樣的趨勢？
翟佳：我們覺得這個趨勢可能就是我們在第一個問題中提到的，它和雲原生比較相關。因為雲原生是一個很大的趨勢。剛剛我們也提到過，Pulsar 選的這套架構，當時也是一個很超前的架構，在 2012 年它就選擇了儲存計算分離這樣的架構，它具備雲原生這個優勢，同時再結合 Pulsar 本身每一層節點都是一個對等的架構，這樣會對線上運維有很大的幫助。包括我們說在你的服務層，你所有的 Broker 都是一個對等的架構。然後你的儲存層 BookKeeper 也是一個對等的架構。這樣你擴縮容的時候，你的大叢集不用維護每個節點 master/slave 的狀態。它的維護更加簡單。同時我們在雲上有一個很重要的初衷，就是我要做一個彈性的資源排程，從這個角度來說 Pulsar 也是剛好順應這個趨勢，跟它誕生的代號 CMS（Cloud Message Service）是一脈相承的關係，就是要做一個訊息的雲，要把雲上的各種資源能夠很容易地排程起來，能夠為訊息系統做一個服務。所以我覺得雲原生是 Pulsar 很大的一個優勢，也是我們順應的一個大趨勢。
InfoQ：好的，謝謝翟老師。
翟佳：感謝主持人。
相關閱讀
點選連結 ，獲取 Apache Pulsar 硬核乾貨資料！