本文由 「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。
阅读英文原文：
更多干货内容，可关注AI前线，ID：ai-front，后台回复「AI」、「TF」、「大数据」可获得《AI前线》系列PDF迷你书和技能图谱。
