Narvar 为何迁移到 Apache Pulsar
在 Narvar，我们每天通过服务的零售商和数百万消费者打交道。我们会及时提醒消费者，更新他们的账户信息，通知订单和包裹的状态以及退货状态。
我们的商业客户覆盖全球上百家最大的零售商和品牌，这些商业客户借助 Narvar 产品灵活的配置，满足消费者的各种需求。
Narvar 平台负责处理数据和事件，帮助零售商及时和他们的客户进行精准沟通。为了处理这个问题，我们试用了很多消息传递和处理技术来构建平台，从 Kafka 到 Amazon SQS，从 Kinesis Streams 到 Kinesis Firehose，从 RabbitMQ 到 AWS Lambda。
这其中很多系统都是和 AWS 绑定的，方便易用。在一段时间内，这些系统运行良好，可以满足我们的需求。
>>> 挑战 <<<
随着公司业务的发展，大量新的应用场景不断涌现，这些系统不能很好地满足新的需求，也不方便扩展。随着客户群的增长，按需扩展配置处理事件变得很困难。
我们发现越来越多的应用程序需要消费事件，这需要增加大量的新服务，因此会增加运维开销，或者使用费用昂贵的 Amazon Lambda。在某些业务场景中，Kinesis Firehose 不能灵活按照需要的格式和结构输出数据。
越来越多的应用场景对顺序保证和主题扩展性有强烈要求，我们的解决方案不能适应这些新挑战。
除了新兴业务场景带来的挑战，我们还面临着规模上的挑战。随着流量增长，我们需要更多的 DevOps 和开发支持来维持和扩展这些系统，而这显然是不可持续的。很多系统不能在容器中运行，配置和管理基础结构负担沉重，需要频繁的人工干预。
Kafka 虽然可靠，使用广泛并且开源，但扩展起来维护费用高昂。例如，增加吞吐量需要增加分区，调整消费者，需要开发人员和 DevOps 进行大量人工干预。
Kinesis Streams 和 Kinesis Firehose 的解决方案都是和特定云厂商 AWS 绑定的，这样很难把云解决方案和其功能分离，难以在其他云平台上使用 Kinesis 技术，也无法支持客户使用其他的云平台。
新兴业务场景带来诸多挑战，扩展过程中遇到各种麻烦，我们最终决定迁移到 Apache Pulsar。
>>> 为什么选择 Apache Pulsar <<<
Pulsar 和 Kafka 一样可靠，不和任何云厂商绑定，并且开源。和 Kafka 不同的是，Pulsar 运维开销很小，扩展也只需少量的人工干预。Pulsar 从一开始就支持容器化，并构建在 Kubernetes 上（即“云原生”）。
Pulsar 有很多复杂的组件，在 Pulsar 技术支持团队的帮助下很容易扩展。给特定的集群进行版本升级很容易，而且不会造成大量停机。Pulsar 技术支持团队给我们提供了系统监控面板（基于 Grafana），监控起来也很容易。
除了方便扩展和维护外，Pulsar 还具有与众不同的功能，这些功能帮我们实现了多种业务场景需求。例如，使用 Pulsar Functions，我们实现了很多功能，同时减少了对 Lambda functions 或其他额外服务的需求。
Pulsar 主题对顺序保证的强大支持帮助我们实现了更多的业务场景需求。
Pulsar 在一套系统中提供了广泛的特性和功能，因此我们淘汰了之前使用的多套解决方案。我们不再需要多种消息处理技术：使用 Kafka 处理发布/订阅，使用 RabbitMQ 和 Amazon SQS 处理消息队列。
同时，我们不需要使用 Kinesis Streams 处理数据，也不再需要 Kinesis Firehose 把流数据加载到数据存储中。从这些技术切换到 Pulsar，我们不仅降低了成本和复杂性，而且更容易支持其他云基础架构提供商。Narvar 在生产环境中使用 Pulsar 快一年了，Pulsar 的性能一直非常可靠。
作者：
ANAND MADHAVAN
Narvar 工程团队副总裁。斯坦福大学计算机科学硕士。曾就职 Snap Discover 产品的工程主管、Twitter Ads 的工程总监。
本文贡献者：
Gnana Prakash, Sherwin Pinto, Rajan Vijaykumar
Tommy Meusburger, Corey Hall
翻译：
Jennifer Huang
别忘了！
下个月我们还有 Pulsar 的线下分享会
在上海，11月16日
扫描下方二维码就可以报名啦！
免费的哦！
👇🏻点击「阅读原文」查看英文原文