本文主要向大家介绍了【云计算】在STICORP环境下使用ApachePulsar构建数据驱动的应用程序教程，通过具体的内容向大家展现，希望对大家学习云计算有所帮助。

背景介绍

在一家商业公司，采用任何一项新技术，包括开源技术，都有一定的风险，即使这项技术具有显著的技术优势。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。

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标大数据云计算大数据安全频道！