Apache Pulsar的多租戶消息系統

本文由 「AI前線」原創，原文鏈接：Apache Pulsar的多租戶消息系統

作者｜Matteo Merli and Sijie Guo

譯者｜大愚若智

編輯｜Emily

AI 前線導讀：」本文介紹了 Apache Pulsar 為大型多層次企業量身打造的消息系統。」

在之前的博客文章中，我們介紹了多個選擇 Apache Pulsar 作為企業級實時業務所用消息解決方案的原因。後續文章中，將會深入介紹其中的一些企業級功能，例如預防數據丟失的持久化存儲、多租戶功能、多地域複製，以及加密和安全。

本文將著重介紹 Apache Pulsar 中的多租戶消息功能。多租戶是指通過一個軟體實例為多個租戶提供服務的能力。租戶是指對系統有著相同「視圖」的一組用戶。作為企業的消息中樞，Apache Pulsar 自誕生之日起就支持多租戶，因為該項目最初就是為了滿足 Yahoo 的嚴格需求，而當時市面上沒有任何可用的開源系統能夠提供多租戶功能，包括常用的日誌抽象系統，例如 Apache Kafka。為多個用戶或職能部門創建多個 Pulsar 實例的做法通常是無法接受的，因為這樣做會使得用戶難以跨越不同部門實時分享數據，造成了隔離。

作為一種企業級的消息系統，Pulsar 的多租戶能力按照設計可滿足下列需求：

• 確保嚴苛的 SLA 可順利滿足
• 保證不同租戶之間的隔離
• 針對資源利用率強制實施配額
• 提供每租戶和系統級的安全性
• 確保低成本運維以及儘可能簡單的管理

Apache Pulsar 通過下列方式滿足了上述需求：

• 通過為每個租戶進行身份驗證、授權和 ACL（訪問控制列表）獲得所需安全性。
• 為每個租戶強制實施存儲配額。
• 以策略的方式定義所有隔離機制，策略可在運行過程中更改，藉此降低運維成本並簡化管理工作。

Pulsar 簡介

為了幫助大家更好地理解 Pulsar 的多租戶能力，首先簡單看看 Pulsar 的消息模型。

與很多其他發布 - 訂閱系統類似，將數據送入 Pulsar 的應用程序可叫做生產者（Producer），使用來自 Pulsar 的數據的應用程序則可叫做消費者（Consumer）。消費者應用程序有時候也可稱之為訂閱者（Subscriber）。與一般意義上的發布 - 訂閱者式類似，主題（Topic）同樣也是 Pulsar 最核心的消息構造。大致來說，主題可以代表供生產者添加數據的渠道，而消費者可以從主題中拉取數據。一組消費者可以針對某一主題組成一個訂閱。不同的消費者組可以針對同一個主題選擇自己首選的消息消費者式：獨享（Exclusive）、共享（Shared）或故障轉移（Failover）。不同訂閱模式如圖 1 所示。

圖 1：Pulsar 的訂閱模式：獨享、共享和故障轉移

Pulsar 從設計之初就可以支持多租戶。因此主題可按照與多租戶有關的兩個資源進行組織：資產（Property）和名稱空間（Namespace）。資產代表系統中的租戶，租戶可以在自己的資產內配置多個名稱空間，每個名稱空間可包含任意數量個主題。名稱空間是 Pulsar 中每個租戶最基本的管理單位，用戶可針對名稱空間設置 ACL，調整副本數目設置，管理跨集群的消息數據多地域複製，控制消息的過期，並執行其他重要的運維操作。

圖 2：一個 Pulsar 部署中包含了三個相互獨立的租戶

如果希望進一步了解 Pulsar，建議閱讀 Pulsar 簡介一文。下文將進一步談談 Pulsar 實現多租戶能力所用的機制。

安全性

為了順利實現多租戶能力，首先需要確保每個租戶：(a) 只能訪問自己有權訪問的主題，並且 (b) 不能訪問自己本不應看到或訪問的主題。這是通過一種插接式（Pluggable）的身份驗證和授權機制實現的。

在 Pulsar 中，當客戶端連接到消息 Broker 後，Broker 會使用身份驗證插件為該客戶端創建身份，隨後（可能）為該客戶端分配角色令牌。該角色令牌是一個字元串，例如 admin 或 application-1，可代表一個或多個客戶端。角色令牌可用於控制客戶端針對特定主題進行生產或消費操作的許可權，並可用於管理租戶資產的配置。

默認情況下 Pulsar 可支持兩種身份驗證提供程序：TLS client auth 和 Athenz，後者是由 Yahoo 開發的身份驗證系統。用戶也可實現自己的身份驗證提供程序，詳情可參閱 Pulsar 的文檔。

身份驗證提供程序識別出某個客戶端的角色令牌後，Pulsar Broker 會使用一個授權提供程序來確定該客戶端有權執行什麼操作。授權是在資產層面上管理的，這意味著一個 Pulsar 集群中可以使用多個同時活躍的授權架構（Scheme）。例如，用戶可以創建一個 shopping 資產並為其設置一組角色，將其應用給企業中所用的購物應用程序；並創建一個 inventory 資產，僅將其應用給庫存應用程序。許可權是在名稱空間的層面上管理的，也就是在資產內部管理的。我們可以針對一個名稱空間，為特定角色的一系列操作，例如 produce 和 consume 分配許可權。有關如何在資產層面上配置授權並為名稱空間分配許可權的詳情，請參閱 Pulsar 的文檔。

最後，身份驗證和授權實現了租戶間的隔離，租戶無法訪問自己無權訪問的主題或執行無許可權的操作。下文一起看看 Pulsar 如何針對租戶進行資源隔離以滿足租戶對 SLA 的要求。

隔離

除了通過隔離滿足安全方面的需求，多租戶應用程序還需要滿足 SLA 的要求，為此 Pulsar 還針對健壯性和性能進行了隔離。這是通過軟隔離實現的，例如磁碟配額、流控制、限流調節。此外還有硬隔離，例如將某些租戶隔離在提供服務的某個 Broker 子網內部，並使用 BookKeeper bookie 實現存儲隔離。

在介紹具體的隔離機制前，先來看看 Apache Pulsar 集群到底是什麼樣的。圖 3 展示了一個典型的安裝環境。Pulsar 集群包含一組 Broker（用於服務發布 - 訂閱流量）、Bookie（用於消息存儲），以及一個負責整體協調和配置管理的 Apache ZooKeeper。Pulsar Broker 是負責接收和交付消息的組件，Bookie 則是為最終消費前的消息提供持久存儲的 Apache BookKeeper 伺服器。

圖 3：一個典型的 Apache Pulsar 環境。

軟隔離

Broker 和 Bookie 通常是被多個生產者和消費者共享的物理資源。為了保護租戶並滿足 SLA 要求，Pulsar 在 Broker 和 Bookie 方面提供了多種不同機制。

存儲

Apache Pulsar 使用 Apache BookKeeper 作為消息的持久存儲系統。Apache BookKeeper 中的每個 Bookie 通常可高效地為成百上千個 Ledger（每個 Ledger 是對一個主題創建的一個片段）提供服務。BookKeeper 能夠實現這樣的效率主要是因為它在設計上就考慮到了 I/O 隔離的需求。每個 Bookie 都有自己專用的日誌（Journal）（位於自己專用的磁碟驅動器上），藉此通過聚合的方式處理所有添加進來的寫操作。隨後消息會定期在後台清空（Flush），並存儲到專用的存儲磁碟驅動器中。這樣的 I/O 架構能實現讀寫操作的隔離，這意味著租戶可以用儘可能快的速度讀取，獲得存儲設備所能提供的最大化 I/O 性能，同時不至於影響到寫操作的吞吐率和延遲。

除了 I/O 隔離，不同租戶還可為不同名稱空間配置不同的存儲配額。Pulsar 還可讓租戶在配額耗盡後繼續執行指定的操作，例如阻止繼續生產消息，拋出異常，或丟棄老的消息。

Pulsar 的 Broker

除了 Bookie 層面上採取的機制，為了滿足 SLA 要求，Pulsar 還在 Broker 層面提供了不同的機制。首先，Pulsar Broker 中的一切事務均可非同步進行，此外還可對每個 Broker 所能使用的內存數量設置上限。如果 Broker 的 CPU 或內存用量超限，可在很短的時間內將流量（手工或自動）遷移至負載不那麼高的 Broker。每個 Pulsar Broker 中的負載管理器組件就是專門做這件事的。

此外還要注意，為滿足 SLA 要求，Pulsar 可以快速在 Broker 之間遷移流量，因為該系統的服務層和存儲層是分開的。這樣 Broker 就可以真正實現無狀態的特徵。與其他消息系統不同，其他系統中的消息分區只能存儲在 Broker 組成的子集中，而 Pulsar 的 Broker 無需在本地存儲任何數據。將主題從一個 Broker 到另一個 Broker 的開銷實現了最小化，因此流量可極為快速地再平衡，並能為租戶提供更迅速的保護。

其次，消息的生產和消費端均部署了流控制協議。在生產端，租戶可以為 Broker 和 Bookie 處於傳輸過程中的消息數量配置限制，這樣就可以抑制用戶以超出系統容納速度的方式發布消息。在消費端，租戶可以針對 Broker 交付給消費者的未完成消息數量進行限制。

最後，在消費端，Pulsar 還可將交付給消費者的消息數量限流調節為指定的速率。這樣即可防止消費者以超出系統處理速度的方式消費消息。

所有這些軟體機制確保了生產者和消費者的 SLA 都可妥善滿足。

硬隔離

上述機制主要是為了確保 Pulsar 能夠在滿足租戶 SLA 要求的前提下高效地共享資源（Broker 和 Bookie）。然而在某些情況下，應用程序還需要對物理資源進行隔離。Pulsar 可通過選項將某些租戶或名稱空間隔離到 Broker 的某個子集中，藉此滿足需求。這樣即可確保這些租戶或名稱空間可以全面使用 Broker 子集所具備的全部資源。

該選項還可用於對不同配置進行實驗、調試，或快速響應生產環境中出現的非預期情況。例如，某個用戶可能會觸發 Broker 執行糟糕的行為，進而導致其他租戶的性能受到影響。此時即可將這個租戶物理隔離到某個不為其他租戶流量提供服務的 Broker 子集中，直到通過部署修復程序順利解決這種情況後再取消隔離。

除了在 Broker 上對流量進行物理隔離，還可以對用於存儲消息的 Bookie 的流量進行隔離。為此可針對名稱空間配置必要的放置策略（Placement policy）。

Pulsar 使用的這些機制可以看作針對不同租戶提供的多集群環境的輕量級版本，但實際上，通常並不需要分別設置這一切。藉此即可實現類似於單一集群的物理隔離，同時可簡化運維工作。

結論

Apache Pulsar 是一種真正的多租戶消息系統，可在不同資源之間提供不同程度的隔離。本文介紹了 Pulsar 用於實現多租戶能力的各種機制，包括通過身份驗證和授權實現安全隔離，通過流控制、限流調節和存儲配額實現共享物理資源的隔離，以及通過放置策略實現物理資源的隔離。希望本文可以幫助大家更好地理解 Apache Pulsar 及其多租戶企業級功能。後續文章還將進一步介紹 Apache Pulsar 的另一項企業級功能：多地域複製。

如果對 Pulsar 感興趣，可通過下列方式參與 Pulsar 社區：

• Pulsar Slack 頻道，可自行在這裡註冊：
• https://apache-pulsar.herokuapp.com/
• Pulsar 郵件列表。

有關 Apache Pulsar 項目的更多常規信息，可訪問官網：http://pulsar.incubator.apache.org/，並可關注該項目的 Twitter 帳號：@apache_pulsar。

閱讀英文原文：

https://streaml.io/blog/multi-tenant-messaging-with-apache-pulsar/

更多乾貨內容，可關注AI前線，ID：ai-front，後台回復「AI」、「TF」、「大數據」可獲得《AI前線》系列PDF迷你書和技能圖譜。