为什么已有Kafka，我们最终却选择了Apache Pulsar？

Posted 2021-04-20 AI前线

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了为什么已有Kafka，我们最终却选择了Apache Pulsar？相关的知识，希望对你有一定的参考价值。

来源｜转载自ApachePulsar公众号

作者｜Daniel Ferreira Jorge

译者｜Sijie Guo

编辑｜Debra

AI 前线导读：Apache Pulsar 提供了太多无法忽视的好处。我们决定部署 Apache Pulsar，并对此非常满意。我们已经将超过 30% 的生产数据迁移到 Pulsar 上，并计划在未来六个月内将所有数据迁移到 Pulsar 上。

更多干货内容请关注微信公众号“AI 前线”（ID：ai-front）

在一家商业公司，采用任何一项新技术，包括开源技术，都有一定的风险，即使这项技术具有显著的技术优势。Apache Pulsar 的引入经过了我们的深思熟虑和充分调研。我想跟大家分享一下我们使用和调研 Apache Pulsar 的经验。因为我们相信肯定有其他和我们类似的公司也可以从 Pulsar 中受益。

Apache Pulsar 是我们为了支持 STICORP 客户应用而采用的一项关键技术。STICORP 是一家总部位于巴西的软件公司。我们提供软件解决方案来帮助 7,000 多家客户管理和自动化他们的税务报告，帮助他们确保税务报告的合规性，避免处罚，并确定可以节省税收的地方。这需要管理大量的税务文档，以及大量由客户行为触发产生的工作流程。这些税务文档包括发票，发货和付款等。在一天内，单个客户可能就会产生超过 200,000 个需要我们进行处理的税务文档。

我们的系统通过与客户和政府系统进行集成自动获取这些税务文档，并以便于客户分析这些文档背后的数据价值的方式组织它们。这些文档的内容和复杂性取决于需要解决的特定业务流程。例如，有些文档是基于发票，发货订单，和客户与供应商之间的付款记录等，而另外一些文档是用于记录这些活动完成时的附加文档。

处理这些文档中的所有不同信息需要一个包含多个步骤的工作流程。文件通常以加密形式到达，因此第一步是解密它们。然后将文档中的 XML 格式的原始消息内容转换为 JSON 格式。从那之后，这些文档会被划分到多个主题（Topic）并被丢到事件总线（Event Bus）上。其他工作流程会监听事件总线，并处理这些文档，最终将处理结构汇总到下游的 Couchbase NoSQL 数据库中，供其他应用程序访问。

性能和可扩展性对我们来说至关重要。因为生成这些文档的交易的天然性质，我们可以看到单个客户在突发高峰时刻可能就会产生每秒 25,000 条消息。能够支持大量主题对我们来说也很重要 - 能够将文档中的信息分解为多个主题，可以帮助我们更加轻松地组织和管理数据，将数据正确的分发和连接到相应的工作流进行处理；但这也意味着我们对于单个客户可能就需要使用 30 个不同的主题。

为什么我们需要新技术

我们最初使用 Apache Kafka 来实现事件总线。虽然我们有一个稳定的 Kafka 基础设施，并且决定去做出基础设施的改变通常并不容易，但我们意识到 Kafka 不是满足我们需求的最佳技术 - Kafka 并不是为我们今天生活的云原生（Cloud Native）世界所设计的，因此我们需要花费大量时间才能使其适用于我们的应用程序。我们使用 Kafka 面临的主要挑战是它不善于处理大量主题。此外，Kafka 的架构让我们感到痛苦 -因为 Kafka Broker 是绑定存储状态的，扩展或缩小 Kafka 集群需要重新平衡分区，这会影响我们的性能和请求时延，并限制我们对工作负载变化做出反应的方式和速度。

部署 Apache Pulsar

在寻找替代方案时，我们了解了 Apache Pulsar 并决定对其进行评估。由于 Apache Kafka 和 Apache Pulsar 使用类似的消息概念，因此我们看到所有的 Kafka 用例可以使用 Pulsar 实现，其方式与使用与 Kafka 完全相同。兼容是促使我们切换到 Pulsar 的原因之一。

我们还注意到了 Pulsar 在架构设计上与 Kafka 的一些重要差异。一个关键的区别是存储和计算的分离 - Pulsar Broker 是无状态的，与存储相互分离；而在 Kafka 的数据直接存储在 Broker 上。这是架构设计差异上的一个例子，它允许 Pulsar 能够实现一些在 Kafka 上做很困难或不可能的事情。这其中的例子包括：

主题可扩展性：我们需要拥有超过 100,000 个主题（不考虑增长），这不仅有助于我们管理应用程序处理的不同类型的数据，还允许个别客户使用自定义应用程序连接到系统中的数据。Pulsar 的架构可以轻松处理数百万个主题。
性能：由于 Pulsar 的分层架构，以及 IO 隔离的特性，读取和写入使用不同的物理存储。因此，读取的峰值根本不会影响写入性能，反之亦然。Pulsar 还支持非持久性主题，允许非常高的吞吐量，完全不需要持久性的主题，这对于实时应用程序非常有用。
消息队列： Pulsar 提供了统一的消息模型，不仅支持类似 Kafka 的消费模式，也支持消息队里的消费模式。在不需要考虑有序性的应用场景中，Pulsar 可以直接当消息队列进行使用。Pulsar 在订阅（Subscription）级别而不是主题级别执行此操作，因为你可以在同一个主题中同时有按序消费的消费者和不按序消费的消费者，这对于很多场景是非常有价值。另一个场景，如果新的消费者需要从头开始读取一个主题里面的所有消息，那么对于 Kafka 来说，你将被迫要么牺牲吞吐量，要么重新平衡分区，或者要么牺牲有序性。而使用 Pulsar，您只需添加新订阅，Pulsar 就会将消息扇出到新增的消费者，以增加新消费者的吞吐量。
操作更简单：使用 Apache Kafka，任何容量扩展都需要重新平衡分区，同时还需要将被平衡的分区重新拷贝到新添加的 Broker 上。使用 Pulsar，我们可以轻松添加和删除节点，而无需重新平衡整个集群。此外，使用 Pulsar，你永远不必担心一个分区是否会超过 Broker 的物理磁盘空间；但是在 Kafka 中，一个分区的容量不能超过一台 Broker 的物理磁盘空间。
无限的数据保留期：我们的一些客户甚至需要在几个月后访问他们的文档。我们希望能够将数据保存在 Pulsar 中，而不会删除它，并在以后需要时使用它。这样我们不必重新从客户或者政府部门导入数据，我们也不必担心丢失消息。当我们需要使用新的一套系统来执行一个新的业务流程时，我们不需要访问数据库，我们可以简单地将文档从消息总线中拉取出并为新的业务流程重新处理它们即可。

由于 Apache Pulsar 提供了太多无法忽视的优点，我们决定实施并部署了 Apache Pulsar，在使用的过程中也对 Apache Pulsar 非常满意。我们已经将超过 30％的生产数据流迁移到 Pulsar，并计划在未来六个月内将所有数据流都迁移到 Pulsar。