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 頻道，可自行在這裏註冊：
• apache-pulsar.herokuapp.com/
• Pulsar 郵件列表。

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

閱讀英文原文：

streaml.io/blog/multi-…

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