案例实践 | 如何做好 Apache Pulsar 的运维？ASP 产品简介

运维好 Pulsar 通常都要需要从技术预研、技术验证、部署上线和日常运营这四个阶段入手。

整体可参考下面的思维导图：

• 技术预研：从预研开始就要考虑到在线上出现紧急故障时如何处理？运维的核心心法：目标是应急，工作在平时。
• 技术验证：技术验证主要分为业务验证和压测两个方面。业务验证比较简单，主要看 Pulsar 的特性和自己业务模型的匹配度，常见的包括消费模型的匹配（Share、Key-Shared 还是Exclusive等），还有消息特性的匹配如延迟队列、死信队列等。从运维侧来说我们更关注的可能是压测。后文会注重描述如何做好一场压测。
• 部署上线：部署前需要消除单点，做好演练并补全监控。需要有完备的应急机制，同时要保留最后的“压箱石”手段。
• 日常运营：日常运营的核心目标就是要降低故障发生的概率。

选择压测场景

现在基于 Pulsar 的压测结果非常多，但结果各不相同。造成这个问题的直接原因是，我们没有统一压测条件，我们在压测不同的场景。

最直接的影响条件，就是数据的可靠性。可靠性要求越高，磁盘占用也越多。不同的可靠性要求，直接影响了压测的性能。

4个可靠性等级

可靠性通常基于副本数量和刷盘策略来保障。刷盘策略又可以细分为副本的同步方式和数据写入磁盘的方式，这两种方式都有异步和同步两种可选。副本数量保持一致相对容易，刷盘策略的不同，其实对应了不同的应用场景，这里需要着重厘清。

我们根据不同的副本同步策略和数据写入磁盘策略，可以列出以下 4 个组合，组合的保障级别依次降低：

• L1：同步复制副本，同步写入磁盘
• L2：同步复制副本，异步写入磁盘
• L3：异步复制副本，同步写入磁盘
• L4：异步复制副本，异步写入磁盘

Pulsar 的默认配置是最严格的 Level 1，即要求所有副本都需要同步成功，同时内存中的数据也需要同步落盘成功。只有满足这个条件，才会认为一条消息是发送成功了。Pulsar默认执行了最严格的可靠性策略，最大程度保证消息不丢。

最松的 Level 4 ，只需要有一个副本成功写到消息代理的内存，即认为消息接收成功。这是相对松散但是性能最高的方案，毕竟一旦副本同步或者是落盘过程中出现问题，消息就有丢失的风险。

Kafka和 RocketMQ 和默认采用 level 4 的方案。

因此，在压测前我们首先需要明确自己的可靠性等级，将相应的压测场景和条件确定下来。在实际使用过程中也需要根据自己的业务场景来判断使用哪种级别的数据可靠性。

选择合适的机型

在 Pulsar压测前就需要结合业务特点、场景和预算等，选择合适的机型来部署 Pulsar 服务。

本文中我们主要从影响程度比较高的网络和磁盘层面做分析。同时，做任何的测试前，都需要做好基准测试，下图提供了相应的基准测试工具，可供参考。

网络影响

网络是一定要测试的，使用 iperf 测试即可。因为网络问题会带来显著的影响，而测试相对容易提前暴露问题。诸如，一个千兆带宽的内网却无法跑满带宽，这可能是因为中间的交换机配置错误，导致带宽只有百兆。因此任何时候都要以实测为准。

磁盘影响

磁盘是容易引起 Pulsar 性能瓶颈的另一“大户”，需要重点关注。

Pulsar使用 Bookkeeper 作为底层的分布式存储。我们需要熟悉其中最基础的两种存储盘，包括 Journal 盘和 Ledger 盘。其中，数据会先写入 Journal盘，而且是顺序写入，因此速度会很快。这同时也会快速清除已经写入的数据，因此 Journal 盘所需的空间可以不大。与此同时，数据会类似“双写”的方式落到Ledger盘。注意，在写入 Ledger盘之前会先在内存中完成排序，之后再写入。

由于 Journal盘和 Ledger盘的用途不同，所以对他们性能要求也不同：

• Journal盘的性能敏感，延时越低越好，同时磁盘空间不需要很大。
• Ledger 盘的吞吐量重要，尤其需要大规模数据写入的时候。同时需要根据业务的数据量，评估好 Ledger 盘的大小。

磁盘的基准测试

磁盘的基准测试相对复杂，我们建议使用 fio 对 Journal 和 Ledger 盘做基准测试，命令可参考下图。

根据测试结果选择合适的 Journal盘和 Ledger盘，再做后续的压测才是相对合理的。如果用的是云服务，也可以直接使用云厂商提供的监控页面观测 IOPS、吞吐量等数据。

确定性能参数

在压测开始前我们还需要确定下我们压测的参数，常见的影响因子包括：

• topic 数量
• 分区数量
• TPS 等

当然，这些数据都不一定适合你的业务场景需求。因此，我们需要结合自己的场景来配置这些参数，再使用 OpenMessaging^[1] 等第三方测试框架进行测试。

稳定运营的流量高点（High 值）

压测最终的目标，是在给定硬件配置和性能参数的情况下，找出集群负载的三个指标，即理论上限的（Max 值），长时压力下时耗稳定的容量值（High 值）和正常范围的扩容值（Normal 值）。

要注意，我们重点关注的应该是 High 值，而不是理论上的最高上限的 Max值。这是因为，处于 Max 值时系统的延迟会非常高，会出现各种奇怪问题，难以为继。某些业务可能在 Max 值下尚能运行，但无疑会提升其他故障发生的概率。例如有些业务系统，依赖消息队列做强事务时，Max 值下会导致业务响应非常缓慢，几乎无法使用。

在 High 值时，即便系统负载依然很高，但是应该相对稳定，不应该出现级联故障。这是我们在生产环境运行时，时刻需要牢记的关键指标。

因此，对于这三个指标做好告警就是运维的基本工作。例如当处于 Normal 值时，需要短信通知相关人员尝试扩容。当出现 High 值时，此时的 CPU和内存可能都处于 80～90%。这时候，留给我们运维的时间就不多了。请根据不同的报警级别，做对应的通知吧。

消除单点

Pulsar 的三大组件，包括Pulsar Broker、Bookkeeper和Zookeeper 本身都没有单点问题，但我们仍然要考虑一些极端情况。

• 机房级单点：需要把数据分散到不同的 AZ(Availability Zone可用区) 里。注意，在 broker 端可加上 VIP 和domain。客户端要使用域名连接服务。
• 机架级单点：虽然数据是多副本写入的，但仍然需要引入机架感知，将副本分散在不同的机器上。
• 单个 Pulsar 集群级单点：需要部署多个 Pulsar 集群，然后在客户端中配置多个集群连接，客户端也支持自动切换。
• 城市级单点：如果多个 Pulsar 集群需要跨城部署怎么办？可以使用 Geo 异步复制数据。
• kubernetes 单集群的单点：单个kubernetes集群也会成为单点，这个时候就需要考虑跨 k8s 进行集群部署。

想要完全消除单点，成本会非常高。因此，我们需要根据自己业务对数据丢失的容忍度来判断，需要维护到什么程度。

通过演练补全监控

如果线上发生了一个故障，但最后恢复了却无人知道原因，那这对运维来说，将是一个灾难。

任何一个故障我们都可以通过演练来模拟，这类有成熟的混沌工程可以使用。

故障过程对业务没影响是基本要求，但重点是我们需要在监控上有所体现。如果一个故障演练下来在监控系统上看不出任何痕迹，那就要考虑对这个系统再深入一些，看看哪些 metrics 我们没有获取到。最终完成监控的补全。这样我们才可以基于这个监控系统的数据进行有效的报警通知。

应急机制

运维人员是系统的最后一道屏障。在程序出现问题，且没法快速修复时需要有一些兜底措施。

最基本的要做到，限流和隔离：

• 限流：可保证整个系统在极端情况下不会崩溃。Pulsar 内置了broker/topic/subscribe 级别的限流^[2]功能。
• 隔离：Pulsar同时也提供了基于 Broker 和 Bookkeeper 级别的隔离策略，可以把一些热点 namespace/topic 和普通的数据隔离开。

运维三板斧

运维人员都要准备好自己“安身立命”的三板斧：

1. 有单点吗？
2. 有监控吗？
3. 有应急预案吗？

任何一个运维方案，任何一次迭代变更，都需要再问下这三个问题。这保证了我们运维方案的底线。

最后，回到 Pulsar 的日常运营。

日常运营最核心的目标，就是要降低故障发生的概率。本质上就是要控制变量的发生。

我们需要对严格对待突发类和变更类的事件对集群稳定性的影响。

• 突发类：包括流量突发和环境异常，这通常通过我们摸清 High 值和消除单点来避免。
• 变更类：包括版本变更和人为变更等。版本变更升级之前要做灰度、出险故障时做降级。人为变更需要遵守发版流程和规范。

ASP 产品介绍

Pulsar 项目本身的价值早已超越了一般顶级开源项目，其应用之广泛、影响力之巨大，已经能作为底层基础设施而存在。但开源版本的运维复杂度，至今都相对较高，这对 Pulsar 项目的推广和使用都带来了一定的阻力。

我们结合多年的 Pulsar 运维经验，凝聚成今天的 AscentStream Platform（ASP）产品，从多个维度帮助我们有效解决了 Pulsar 运维复杂度过高的难题。

我们的核心思路：

• 保持核心不变：保持上游优先，同时提供灵活性，保持灵活对接企业的各类环境。
• 提供功能插件：提供消息轨迹、Kafka 协议兼容、更好的限流插件、K8S 多环境支持和各类灵活接入插件、认证和授权插件等，这帮助我们更好的固化经验，解决已有问题。
• 提供管控界面：提供完善的界面化管控，包括自动化运维，自动化扩缩容，提供 API 灵活对接企业环境。完善对 Functions 和 Geo 等管控的支持。完善更好的 K8S 兼容性。
• 提供支持服务：基于上述的保障，我们运维侧才有能力和信心给客户提供更多的专家服务。

消息轨迹

消息轨迹是非常实用的功能。这解决了平时难以解决的“不可能三角”，即业务开发、平台开发和平台运维人员之间的问题定位和定责问题。

我们根据日常定位经验，通过msgid完成生产消费过程的串联。这帮助我们能快速提供定位问题。

这里的核心数据包括：

• 生产者，生产时间，生产者地址
• 消费组信息，重试次数
• 消费者，消费动作(推送/确认)

做好 Pulsar 运维，对于消息的全生命周期管理是第一个需要开发完善的功能。

完善的管控

我们对 Pulsar 做了大量的自定义埋点，同时对不合理的指标做了指标削减。并参考现有监控，自研了一整套的界面化监控和告警。对于日常开发和运营，也提供了很多实用工具。有效的提升了开发和运营的效率。

Functions 增强

我们给客户交付的环境中，已经较多使用 Function、Sink和 Source 功能。因此对 Function 类任务的管控也是日常开发和运维需要重点关注的对象。

通过对任务全周期的管控，包括包管理、任务管理，流程串联等，目前已经可以实际支撑起一个内部 FaaS 系统平台的功能。

跨云多环境支持

我们对 Pulsar 有大量的支持和使用经验。从中也会发现，大量的头部企业，其内部环境相对复杂以及对容灾、冗余都有着很强的需求。

这时候，你需要对跨云、多环境有支持能力，同时做到统一和自动化的管理。

综上所述，我们深入探讨了如何精通 Pulsar 的运维实践。首先，我们从"内功心法"的角度出发，详细解析了运维的四个关键阶段；其次，我们从"外功法门"的视角，分享了宝贵的经验积累，并介绍了 ASP 产品的功能特性。我们期望通过这种"内外兼修"的全面阐述，为大家提供丰富的参考和启示。

我们也期待大家来我们 AscentStream^[3] 官网做进一步交流和体验。

参考资料