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迷你书和技能图谱。