前言

對于開發(fā)云原生分布式應(yīng)用程序的開發(fā)人員來說室囊，他們應(yīng)該把更多的精力放在應(yīng)用程序和微服務(wù)上扮匠，而不是把時間浪費在處理復(fù)雜的消息基礎(chǔ)設(shè)施上吵血，他們需要一些解決方案幫助他們管理好這些基礎(chǔ)設(shè)施。

構(gòu)建消息基礎(chǔ)設(shè)施的第一步是選擇合適的消息中間件技術(shù)。在這方面有很多選擇，從各種開源框架（如 RabbitMQ指煎、ActiveMQ、NATS）到一些商用產(chǎn)品（如 IBM MQ 或者 RedHat AMQ）先壕。當(dāng)然嗡害，除了這些之外，我們還有 Kafka兰怠。不過梦鉴，我們最后并沒有選擇 Kafka，而是選擇了 Pulsar揭保。

為什么我們最終選擇了 Pulsar肥橙？下面列出了選擇 Pulsar 而不是 Kafka 的 7 大理由。

流式處理和隊列的合體

Pulsar 就像是一個合二為一的產(chǎn)品秸侣，不僅可以像 Kafka 那樣處理高速率的實時場景存筏，還能支持標(biāo)準(zhǔn)的消息隊列模式宠互，比如多消費者、失效備援訂閱和消息扇出椭坚，等等予跌。Pulsar 會自動跟蹤客戶端的讀取位置，并把這些信息保存在高性能的分布式 ledger（BookKeeper）當(dāng)中藕溅。

與 Kafka 不一樣的是匕得，Pulsar 具備傳統(tǒng)消息隊列（如 RabbitMQ）那樣的功能，因此巾表，只需要運行一個 Pulsar 系統(tǒng)就可以同時處理實時流和消息隊列汁掠。

支持分區(qū)，但不是必需的

如果你用過 Kafka集币，就一定知道分區(qū)是怎么回事考阱。Kafka 中的所有主題都是分區(qū)的，這樣可以增加吞吐量鞠苟。通過分區(qū)乞榨，單個主題的處理速率可以得到大幅提升。但如果某些主題不需要太高的處理速率当娱，那該怎么辦吃既？對于這類情況，就不需要考慮分區(qū)了跨细，以避免復(fù)雜的 API 和管理方面的工作鹦倚，這樣不是更好嗎？

Pulsar 就可以做到冀惭。如果你只需要一個主題震叙，而不需要分區(qū)，那使用一個主題就好了散休。如果你需要使用多個消費者實例來提升處理速率媒楼，其實也不需要使用分區(qū)，因為 Pulsar 的共享訂閱可以達(dá)到你的目的戚丸。

如果你確實需要分區(qū)來進(jìn)一步提升性能划址，你也可以使用分區(qū)。

日志固然不錯限府，但 ledger 更勝一籌

Kafka 開發(fā)團(tuán)隊預(yù)見了日志對于一個實時數(shù)據(jù)交換系統(tǒng)的重要性猴鲫。因為日志是通過追加的方式寫入系統(tǒng)的，所以數(shù)據(jù)寫入速度很快谣殊。又因為日志中的數(shù)據(jù)是串行的拂共，所以可以按照寫入的順序快速讀取數(shù)據(jù)。相比隨機(jī)讀取和寫入姻几，串行讀取和寫入速度更快宜狐。對于任何一個提供數(shù)據(jù)保證的系統(tǒng)來說势告，持久化存儲方面的交互都是一個瓶頸，而日志抽象最大限度地提升了這方面的效率抚恒。

日志固然是好咱台，但當(dāng)它們的量增長到很大的時候，也會給我們帶來一些麻煩俭驮。在單臺服務(wù)器上保存所有日志已經(jīng)成為一個挑戰(zhàn)回溺。在服務(wù)器存儲被日志填滿之后該怎么辦？如何進(jìn)行伸縮混萝？或者保存日志的服務(wù)器宕機(jī)遗遵，需要重新從副本創(chuàng)建新的服務(wù)器，該怎么辦逸嘀？將日志從一臺服務(wù)器拷貝到另一臺服務(wù)器是很耗費時間的车要，特別是如果你想要在保持系統(tǒng)實時數(shù)據(jù)的情況下完成這個操作就更難了。

Pulsar 對日志進(jìn)行分段崭倘，從而避免了拷貝大塊的日志翼岁。它通過 BookKeeper 將日志分段分散到多臺不同的服務(wù)器上。也就是說司光，日志并不是保存在單臺服務(wù)器上琅坡，所以任何一臺服務(wù)器都不會成為整個系統(tǒng)的瓶頸。這樣就可以更容易地處理故障残家，要進(jìn)行伸縮也很容易榆俺，只需要加入新的服務(wù)器，不需要進(jìn)行再均衡跪削。

無狀態(tài)

對于云原生應(yīng)用程序開發(fā)人員來說，他們最喜歡的東西就是無狀態(tài)迂求。無狀態(tài)組件啟動速度快碾盐，可替換，還可以實現(xiàn)無縫的伸縮揩局。如果消息中間件也是無狀態(tài)的毫玖，那豈不是更好？

Kafka 不是無狀態(tài)的凌盯，因為每個 broker 都包含了分區(qū)的所有日志付枫，如果一個 broker 宕機(jī)，并非任意一 broker 都可以接替它的工作驰怎。如果工作負(fù)載太高阐滩，也不能隨意添加新的 broker 來分擔(dān)。broker 之間必須進(jìn)行狀態(tài)同步县忌。

在 Pulsar 架構(gòu)中掂榔，broker 是無狀態(tài)的继效。但是完全無狀態(tài)的系統(tǒng)是無法用來持久化消息的，所以 Pulsar 其實是有維護(hù)在狀態(tài)的装获，只是不是在 broker 上瑞信。在 Pulsar 架構(gòu)中，數(shù)據(jù)的分發(fā)和保存是相互獨立的穴豫。broker 從生產(chǎn)者接收數(shù)據(jù)凡简，然后將數(shù)據(jù)發(fā)送給消費者，但數(shù)據(jù)是保存在 BookKeeper 中的精肃。

因為 Pulsar 的 broker 是無狀態(tài)的秤涩，所以如果工作負(fù)載很高，就可以直接添加新的 broker肋杖。

簡單的跨域復(fù)制

跨域復(fù)制是 Pulsar 的拿手好戲溉仑。Pulsar 在設(shè)計之初就考慮到了這個特性，配置也很容易状植。要搭建一個全球化的分布式 Pulsar 集群浊竟，并不需要你擁有博士學(xué)位。

穩(wěn)定的表現(xiàn)

一些基準(zhǔn)測（http://openmessaging.cloud/docs/benchmarks/pulsar/）表明津畸，Pulsar 可以在提供較高吞吐量的同時保持較低的延遲振定。

完全開源

Pulsar 提供了很多與 Kafka 相似的特性，比如跨域復(fù)制肉拓、流式消息處理（Pulsar Function）后频、連接器（Pulsar IO）、基于 SQL 的主題查詢（Pulsar SQL）暖途、schema registry卑惜，還有一些 Kafka 沒有的特性，比如分層存儲和多租戶驻售，所有這些特性都是開源的露久。

結(jié) 論

為此，我們有理由選擇 Pulsar 來構(gòu)建我們的消息基礎(chǔ)設(shè)施服務(wù)欺栗。其實除了上述這些原因之外毫痕，使用 Pulsar 還有其他好處，比如多租戶迟几、命名空間消请、認(rèn)證和授權(quán)、文檔类腮、對 Kubernetes 的友好支持臊泰。