以下文章來源於AI前線，作者AI前線小組 譯
本文由微信公眾號 「AI 前線」原創（ID：ai-front），未經授權不得轉載。
作者 | Chris Bartholomew
譯者 | 無明
編輯 | Natalie
AI 前線導讀： 對於雲原生分散式應用程式的開發人員來說，為把更多精力放在應用程式和微服務開發上，而不是浪費時間處理複雜的訊息基礎架構，他們需要一個解決方案幫助管理好這些基礎架構。
構建訊息基礎架構的第一步是選擇合適的訊息中介軟體技術。可選方案有很多，從各種開源框架（如 RabbitMQ、ActiveMQ、NATS）到一些商用產品（如 IBM MQ 或者 RedHat AMQ），除此之外，我們還有 Kafka。不過，我們最後沒有使用 Kafka，而是選擇了 Pulsar。
為什麼最終選擇了 Pulsar？下面列出了選擇 Pulsar 而不是 Kafka 的 7 大理由。
1. 流式處理和佇列的合體
Pulsar 就像一個合二為一的產品，不僅可以像 Kafka 那樣處理高速率的實時場景，還支援標準的訊息佇列模式，比如多消費者、失效備援訂閱和訊息扇出等等。Pulsar 會自動跟蹤客戶端的讀取位置，並把這些資訊儲存在高效能的分散式 ledger（BookKeeper）當中。
與 Kafka 不同，Pulsar 具備傳統訊息佇列（如 RabbitMQ）的功能，因此，只需要執行一個 Pulsar 系統就可以同時處理實時流和訊息佇列。
2. 支援分割槽，但不是必需的
如果你用過 Kafka，就一定知道分割槽是怎麼回事。Kafka 中的所有主題都是分割槽的，這樣可以增加吞吐量。通過分割槽進而劃分到不同的 broker，單個主題的處理速率可以得到大幅提升。但如果某些主題不需要太高的處理速率，又該怎麼辦呢？對於這類情況，如果能不考慮分割槽，避免隨之而來的 API 和管理工作，不是更好嗎？
Pulsar 就可以做到。如果只需要一個主題，可以使用一個主題而無需使用分割槽。如果需要保持多個消費者例項的處理速率，也不需要使用分割槽，Pulsar 的共享訂閱可以達到這一目的。
如果確實需要分割槽來進一步提升效能，Pulsar 也可以支援分割槽的使用。
3. 日誌固然不錯，但 ledger 更勝一籌
Kafka 開發團隊預見了日誌對於一個實時資料交換系統的重要性。日誌通過追加的方式寫入系統，寫入速度很快。日誌中的資料是序列的，可以按照寫入的順序快速讀取資料。相比隨機讀取和寫入，序列讀取和寫入速度更快。對於任何一個提供資料保證的系統來說，持久化儲存方面的互動都是一個瓶頸，而日誌抽象最大限度地提升了這方面的效率。
日誌固然好，但當資料量過大時，也會給我們帶來一些麻煩，單臺伺服器上儲存所有日誌已經成為一個挑戰。在日誌佔滿伺服器儲存之後該怎麼辦？如何進行擴容？或者儲存日誌的伺服器當機，需要重新從副本建立新的伺服器時，該怎麼辦？將日誌從一臺伺服器拷貝到另一臺伺服器耗時很長，特別是想要同時保持系統實時資料時，完成這個操作就更難了。
Pulsar 對日誌進行分段，從而避免了拷貝大塊的日誌。通過 BookKeeper， Pulsar 將日誌分段分散到多臺不同的伺服器上。也就是說，日誌不會儲存在單臺伺服器上，任何一臺伺服器都不會成為整個系統的瓶頸。這使故障處理和擴容更加簡單，只需要加入新的伺服器，而無需進行再均衡處理。
4. 無狀態
對於雲原生應用程式開發人員來說，最喜歡的東西就是無狀態。無狀態元件啟動速度快、可替換，還可以實現無縫擴容。如果訊息中介軟體也是無狀態的，那豈不是更好？
Kafka 不是無狀態的，每個 broker 都包含了分割槽的所有日誌，如果一個 broker 當機，不是所有 broker 都可以接替它的工作。如果工作負載太高，也不能隨意新增新的 broker 來分擔，而是必須與持有其分割槽副本的 broker 進行狀態同步。
在 Pulsar 架構中，broker 是無狀態的。但是完全無狀態的系統無法持久化訊息，所以 Pulsar 不是依靠 broker 來實現訊息持久化的。在 Pulsar 架構中，資料的分發和儲存是相互獨立的。broker 從生產者接收資料，然後將資料傳送給消費者，但資料儲存在 BookKeeper 中。
Pulsar 的 broker 是無狀態的，所以如果工作負載很高，可以直接新增新的 broker，快速接管工作負載。
5. 簡單的跨域複製
跨域複製是 Pulsar 的拿手好戲。Pulsar 在設計之初就考慮到了這個特性，配置也很容易。無論是全域性分散式應用程式還是災備方案，都可以通過 Pulsar 搞定。
6. 穩定的表現
基準測試（http://openmessaging.cloud/do...）表明，Pulsar 可以在提供較高吞吐量的同時保持較低的延遲。
7. 完全開源
Pulsar 提供了很多與 Kafka 相似的特性，比如跨域複製、流式訊息處理（Pulsar Functions）、聯結器（Pulsar IO）、基於 SQL 的主題查詢（Pulsar SQL）、schema registry，還有一些 Kafka 沒有的特性，比如分層儲存和多租戶。更讚的是，這些功能特性都是開源的。
結 論
以上，我們有很多理由選擇 Pulsar 來構建訊息基礎架構服務。除了上述原因之外，Pulsar 的其他特性也帶來了很多便利，比如多租戶、名稱空間、認證和授權、文件、對 Kubernetes 的友好支援等等。
英文原文：
更多關於 Apache Pulsar 的動態和乾貨分享，請關注 ApachePulsar 公眾號！
