Apache Pulsar 在腾讯云上的最佳实践

本次 Meetup，腾讯云高级工程师林宇强为大家带来了议题为《Apache Pulsar 在腾讯云上的最佳实践》的精彩演讲，接下来的篇幅将从系统架构、设计思路、寻址服务、跨集群迁移、跨地域容灾几个方面详细为大家介绍 Apache Pulsar 在腾讯云上的最佳实践。

Pulsar 系统架构

上图是一个很常见的 Pulsar 部署架构，ZK 采用了腾讯云 TSE ZK；对接内部的配置中心、CICD 平台可以实现标准化部署，其余的 Bookie 和 Broker 和开源自建的部署模式差别不大。

这里需要介绍下腾讯云自研部分的诊断三件套：Metrics，Trace，日志采集。

Metrics：Broker 自研采集→上报 Monitor 集群 Topic →Pulsar Sink 聚合预处理→腾讯云监控。这里值得说明的是我们在 Broker 和云监控之间加了一层 Pulsar Broker 集群（Monitor 集群）作为缓冲，并使用 Pulsar 自带的 Sink 来进行 Metrics 数据的预处理，因为该监控链路是地域级别，比如广州地区只部署一套，而对外提供业务服务的 Broker 集群数则规模较多，总的 Topic 数规模大，故而需要中间增加一层来缓解对云监控的压力，这是量变引发质变的结果。

Trace：Broker 自研采集→Trace 日志→Filebeat 上报→APM，这也是演进的结果。原先的架构是 Skywalking 采集→内存排队上报→APM，这种架构看似简单，但是当 Broker 的流量规模到达一定程度时，Trace 产生的速度高于上报的速度，导致内存不断增长进而 OOM，因此 Trace 最终也是回归原始，放弃 Skywalking，利用磁盘承受住短时的洪峰。当然，也有一部分业务持续高流量，造成上报永远追不上 Trace 日志的产生，这种情况下也只有两种做法：对于对消息轨迹不强求的业务，关闭 Trace 上报；对于流量大并且对轨迹仍然有要求的，只能通过升配的方式，调大 Filebeat 的可用核心数硬抗。

CLS日志采集：Metrics 和 Trace 由于和 Broker 自身的逻辑有强耦合，我们只能针对 Broker 进行定制化开发。但是日志采集是个普适性功能，因此我们直接采用腾讯云 CLS 来实现我们的目的：日志采集汇总，根据环境、地区、集群分类，关键字监控，日志长时间存档，关键字告警等。

Lookup Service：Lookup Service 是个地域级别的模块，每个地区只部署一套，用于同一个地区所有 Broker 集群的路由、寻址功能，这个模块后续会重点介绍。

设计背景及思路

介绍完 Pulsar 系统架构，接下来介绍一下我们在腾讯云场景下所面临的问题及解决思路。

• 完全容器化：包括 ZK、BK、Broker 以及其他周边设施，全部部署在容器平台上。

• 多环境、多地区：这是云服务提供商相比常规的业务。我们不仅有测试、预发、线上环境，线上环境还有多个地区，比如北京、上海、广州、新加坡、香港等，每个地区分别有多个集群。

• 多可用区（同城多机房）：云自身自带同城多机房，因此可以很方便做同城多活的容灾。

• 集群数量多、Topic 规模大：集群数量多、Topic 多，这对应的我们要设计标准化部署流程，前面讲到的监控链路也是在这个背景下的产物。

• 产品形态多种多样：产品形态对应的是部署架构上的差别，租户、Broker、Bookie 之间的部署关系。

• 虚拟网络，接入方式多样：这是云服务提供商必然要面对的多网络平面的问题。

• 支持集群热迁移：在客户端 url 不变的前提下，将租户从集群1迁移到集群2，这也是云服务提供商所需的产品能力，比如将一个集群从标准版升级到专业版，那么就对应租户和底层物理资源分配上的迁移。

虽然 Pulsar Broker 可以称作为云原生消息队列，但是实际上，Broker在运行时是有状态的，比如：Topic 和 Broker 之间的归属关系。

因此我们在进行容器化的时候，整体的思路就是让 Pod 和 VM 尽可能划上等号，于是我们做了以下设计：

• 固定 IP：IP 不会随着 Pod 的销毁重建而随机变化。

• Pod 与 Node 网络拉平：针对腾讯云的场景，Client 一定不是运行在 Broker 部署的容器集群上，如果不拉平的话，Lookup 时就得考虑容器网络（Overlay）和基础网络（Underlay）之间的映射关系，会让 Lookup 变得很复杂。

• 云盘：Pod 中挂的数据盘为云盘，真正的计算存储分离。

• 与 CVM 共存：每个 Pod 独占一台 CVM，两者 CPU 和内存参数对等，这样能最大程度保证 Pulsar 运行时的物理隔离性，当然，这也是腾讯云 EKS（TKE Serverless）天然提供的能力。另外，在容器化迁移过程中，同一个集群必然存在 Pod 节点和 CVM 节点同时存在，因此也需要考虑这二者之间的相容性。

• 优雅停机：Pod 销毁时，需要确保触发 Pulsar 的 Shutdown 逻辑，否则对 Client 来说就会变得强烈感知，这也是容器场景和 CVM 场景在 CICD 流程上的差异导致需要注意的地方。

• Liveness probe 调优：Liveness probe 也有一个有意思的点，由于 k8s 自身的各种健康检查机制其实都是依赖于一个超时时间，如果 Broker 启动阶段不能在约定超时时间内返回正确的结果，k8s 容易误判为失败，造成 Broker 无限重启。举个例子：假设某个 Broker 集群有几万个 Topic，那么其 Broker 启动时间可能需要耗时90s以上，如果 Liveness 设置超时时间低于该值，就需要特别注意。当然，这也是我们集群规模多导致，我们的不同集群可能是不同的业务场景在使用，因此很多类似的参数都需要针对性调优。

• Helm 编排：Pulsar 的部署步骤其实比较繁杂，Bookie 部署、Bookie 初始化、Broker 部署、Broker 初始化，以及所需的 Secret、ConfigMap、网络模块等，要讲这么多模块有序的编排起来，Helm 当然是最好的选择。

Topic 数多会引发以下问题：

• ZK 元数据过多，负载高

• 启动变慢，K8s 就绪误判

• Broker 重启爆炸半径大

• Lookup 性能变差

• 监控采集聚合引发质变

腾讯云 Pulsar 目前提供两种产品形态，对应底层就是部署架构的多样性，当然，这会对应最终每个实例的售卖价格和腾讯云本身的成本。

• 共享版：Bookie 和 Broker 都是共享的，本质和一个公司自建一个集群给公司内所有业务团队共用是一个模型，共享版下的一个实例对应 Pulsar 的一个租户。

• 专业版：Bookie 和 Broker 都是独占的，且该集群只有一个租户，该租户独占完整的所有物理资源。

腾讯云 Pulsar 提供了多种网络接入方式，网络接入即 Broker 和 Client 之间的网络连通关系。

• 内网接入

内网接入在本质上和常规的公司内自建使用类似，Broker 和 Client 都处在同一个内网之中，且二者之间是完全互通的，Client 连接的 IP 也都是 Broker 的节点原始 IP，无任何网络转换。

• VPC 接入

VPC 即虚拟私有网络，每个用户可以创建多个VPC，每个VPC下又可以创建多个子网。想了解更多可查看：https://cloud.tencent.com/document/product/215/20046。

两个 VPC 之间通常是无法互通的，比如图上的10.0.0.0/8和192.168.0.0/16，除非使用云联网、对等连接等 VPC 之间的互通产品，但是这个不在我们的讨论范围。

如图所示，Broker 部署在10.0.0.0/8，而 Client 在192.168.0.0/16，那么这时候，Client 想要访问 Broker 就变得不可能。

在云网络场景，VPC 提供了云虚拟网关（仅内部组件）来支持两个 VPC 之间的互通，我们便称之为跨网络平面互通。

当然，其本质就是做网络映射，比如：

• Broker1：在10.0.0.0/8的 IP 是10.2.0.1，我们通过云虚拟网关创建 Broker1 在192.168.0.0/16的 IP 为192.168.1.1，那么当 Client 在10.0.0.0/8中就需要用10.2.0.1访问Broker1，当 Client 在192.168.0.0/16中就要用192.168.1.1来访问 Broker1。

• 由于 Pulsar Client 的连接协议是先 Lookup 后直连的方式（这个可以参照后面的 Lookup 寻址时序图），就对 Broker 的 Lookup 接口提高了要求，Broker 就需要自动化地判定：

  1、当 Client 来自于10.0.0.0/8网络，返回10.2.0.1

  2、当 Client 来自于192.168.0.0/16网络，返回192.168.1.1

这也就是 Pulsar 这个服务在云服务场景所要面对的问题。

• 公网接入

前面介绍了 VPC 接入，其实公网接入和 VPC 接入也是类似的。

唯一的差别是:

• VPC 接入：Broker 和 Client 处在两个不同的内网网络平面。

• 公网接入：Broker 部署在内网，而 Client 来自于公网，可以直接把公网看作一个特殊的 VPC 就很好理解了。

寻址服务

下面我们来介绍下腾讯云的寻址服务的思路来源，也是寻址服务的价值所在。

我们看下 RocketMQ 的服务，其架构分为 NameServer 和 Broker。

• NameServer 保存了集群的元数据：Topic 和 Broker 之间的归属关系，这样就可以动态地配置 Topic 和 Broker 之间的从属关系，也可以将 Topic 在不同的 Broker 集群之间调度。

• RocketMQ 同 Pulsar 一样，也有类似 Lookup 的寻址流程，只不过 RocketMQ Client 寻址的请求对象是 NameServer，而 Pulsar Client 寻址的请求对象是 Broker，从这方面看来，架构上可以理解为 Pulsar Broker 相当于是 RocketMQ NameServer 和 RocketMQ Broker 结合到了一起。

优缺点：

Pulsar 这样做部署架构简单，不会额外多出一个 NameServer 服务，但是同样也失去了 Topic 在物理集群之间的调度能力。

RocketMQ 虽然多出了一个模块，但是其提供的集群调度能力，是一种非常重要的运维能力。

这种调度能力，恰恰是云服务所需要的，有了这种调度能力，我们的云服务才能对集群有可运维性和灵活的资源调度方式。

如前面所说，在云服务场景，针对 Pulsar Broker，我们需要提供的内网、VPC、公网三种网络接入场景，和 Pulsar Broker 本身提供的 Lookup 能力的矛盾。使用寻址模块，便有以下好处：

• 将多网络接入这种云服务场景收敛在寻址服务内核中，而 Broker 仍然只提供最纯粹的内网服务，更好地保持 Broker 的原始能力以及与开源的衔接。

• 动态地增减接入点（即不同的网络接入方式的概念名称），对于一个 Pulsar 集群来说增加、减少一个内网、VPC、公网接入点时，不需要对 Broker 做任何变动。

• 实现扩缩容的自动化和无感知化，Broker 的扩缩容，等同的也需要对该集群的所有接入点中的网络映射进行扩缩容变更，由于寻址模块的存在，这部分全部收敛在该模块，Broker 的扩缩容不需要对存量节点做任何变动。

前面介绍了很多寻址模块和寻址流程，这里来重点介绍下 Pulsar-Client 的寻址时序，来补充下对前面的介绍，以及科普下 Pulsar Client 的机制：

• 第一步：获取 Topic 分区数：Client→CLB→Broker，一对多指的是该请求落到 CLB 后面的任意一台 Broker 都能对等返回正确结果。

• 第二步：单分区 Topic Lookup：针对单个分区进行 Lookup，询问该 Topic 当前的 Owner Broker 地址，同样是一对多，不同 Broker 之间提供对等服务。

• 第三步：基于第二步返回的该 Topic 分区的 Owner Broker 地址，进行直连，随后进行消息收发。一对一，特指此时的直连必须精准连接 Broker 集群中的某台 Broker，比如 Broker-2，连接别的 Broker 则会连接失败。

这就是 Pulsar-Client 初始化一个 Producer/Consumer 的步骤。

我们的寻址模块切入点在哪呢？

就是第一和第二步，如图所示，在这两个步骤中间加入一层代理层，这样就可以在寻址返回结果上针对多网络接入、Topic 和物理集群从属关系调度上做一些篡改，以达到我们的目的。

上图是我们加入寻址模块后，Pulsar 架构上的改变，整个架构就变得和 RocketMQ 有点类似，有一个中央元数据服务用来管理 Topic 资源和物理计算资源之间的关系。

跨集群迁移

前面铺垫了这么多，介绍了寻址模块以及架构上的优化，接下来介绍下在此之上我们所做的产品化能力——跨集群迁移。

跨集群迁移特指一个租户从物理集群1迁移到物理集群2，两个集群同时提供服务，在线热切换，Client 轻微感知。

如图所示，整个流程也很简单，寻址服务保存了租户和物理集群的路由关系，路由关系一变更，即集群迁移变更。

基于 Pulsar Lookup 寻址的协议，路由关系的切换粒度可以做到租户粒度、Namespace 粒度、Topic 粒度、分区粒度。

切换的方式：路由切换+Topic unload

机制上来说，这个切换流程很简单，难点在前置准备工作上：

• 元数据迁移：租户、Namespace、Policies、Topic、订阅、Token 等。

• 消息双向同步：切换过程中两个集群同时提供服务，为了提供可回滚能力，发送的消息需要在两个集群之间双向同步，保证两个集群都有完整的所有消息。

• 进度同步：每个 Topic 的订阅消费进度不同，需要定时同步，尽量较少切换过程中的重复消费。

消息同步比较简单，我们采用了 Pulsar 自带的 GEO-Replicator 功能，这里不再赘述。

这里简单介绍下进度同步的机制。

1. 消息迁移：在消息同步阶段（GEO-Replicator）会在消息头部携带消息的源集群里的消息 IP。

2. 定时同步：定时将源集群的消费进度同步到目标集群，基于 Compact topic 同步和持久化。

3. 进度缓存：目标集群读取 Compact topic 中的消费进度信息，将消费进度加载到内存。

4. 投递过滤：在 Pulsar 的投递流程 Dispatcher 处理过程中，过滤掉本要投递，但是已经在源集群进度中投递过的。

跨地区容灾

地区容灾，也是我们基于寻址服务的架构改进后，所开发出的产品化能力。

本质和跨集群迁移类似，但是由于跨地区的网络时延问题，在侧重点上有所不同：

如图所示，假设我们的 Pulsar 实例在广州地区，Client 也在广州地区，但是由于不可抗力，导致广州地区的 Pulsar 实例全部宕机，并且短时间内无法迅速恢复，我们可以暂时将 Client 的流量切到上海地区的容灾实例，来保证 Client 在线业务的迅速恢复。

• 同一时间只有一个集群提供服务。

• 短时间、临时性切换：由于跨地区时延的不可控（特别是国外地区），容灾机制一定是临时的，待广州地区恢复后，理应尽快将流量回切。

• 元数据定时同步：因为我们无法预测广州集群何时宕机，且该场景的使用频度较低，这是一种权衡的结果。

• 消息、进度不同步：面对的是广州集群全部宕机，此时广州集群磁盘中的数据暂时无法读取，另一个原因就是跨地区时延大，做实时消息同步的性价比太低。

• 切换：基于域名解析切换，因为广州和上海的寻址服务互相独立隔离，这个时候如果广州集群有堆积，那部分只能继续堆积着，等广州地区恢复了才有机会重新消费。

• 回切：由于上海集群只是用来紧急容灾，在广州集群恢复后，必定要重新切回广州，回切的过程中比较重要的就是上海集群上堆积的消息，需要回写到广州，这个过程中不可避免会出现一部分重复消费和消费顺序错乱（同一分区内）。

该方案是面对地区级别灾难场景下的容灾，因为每个地区本身已经是多可用区部署（同城多机房），因此整个地区不可用的概率较低，因此跨地区容灾的整个产品设计侧重主要用于应急，而不是为了像跨集群迁移一样的热切换，需要做到非常严格的双向同步。

总结

我们先从腾讯云 Pulsar 的整体架构讲起，介绍了在腾讯云的场景下所需要面对的问题，引出了寻址模块（Lookup Service），并介绍了寻址模块的引入对于 Pulsar 的部署架构上的优化。随后介绍了 Lookup Service 解决的两个核心问题：多网络 Lookup 和集群间调度，并保证对客户端接入的无感知和对架构的低侵入性。由于寻址模块的存在，我们便能基于它做进一步的产品化能力，跨集群迁移和跨地区容灾，从而能够在不同级别的灾难场景下都能提供相应的修复措施和运维能力。

未来，我们还会继续在容灾能力、Pulsar 周边生态对接、存储优化等方面继续努力，以提供成本更低、稳定性更高的 Pulsar 产品。

扫描下方二维码关注本公众号，

了解更多微服务、消息队列的相关信息！

解锁超多鹅厂周边！