Apache Pulsar的多租户消息系统

ApachePulsar

摘要：

本文介绍了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。

作者：Matteo Merli and Sijie Guo，阅读英文原文：Multi-tenant messaging with Apache Pulsar