博文推荐｜Apache Pulsar: 统一消息流平台

本文翻译自《Apache Pulsar: A Unified Queueing and Streaming Platform》，作者 Addison Higham。原文链接：https://thenewstack.io/apache-pulsar-a-unified-queueing-and-streaming-platform/

译者简介

Addison 是 StreamNative 主管工程师。本文译者为刘梓霖 。

现在我们可以大胆宣言：种种迹象表明，Apache Pulsar 这个开源分布式消息系统正站在现代应用架构和开发的风口浪尖。

为什么我们敢于这样讲呢？

随着工程师团队面对越来越复杂的挑战，解决层出不穷的问题所需的技术和工具也在不断发展。这其中常用的一种工具是消息传递。

消息传递基于消息队列。消息在客户端应用程序之间进行异步排列，由一个“broker” 充当各应用程序之间的媒介。

在早期的技术中，broker 是相对简单的。但随着实际需求的变化消息系统也随之发生了变化。分布式消息系统便是建立在这个概念的基础上，不仅具有可靠性、可扩展性和持久性的优点，且多个 “broker” 可以帮助分担负载。

大多数的分布式消息系统支持一种类型的语义：流或队列。从以往经验看，每一种都有其最适合的特定类型的场景。Apache Pulsar 的独特之处在于它同时支持流和队列这两种语义。

在探讨使用统一的消息流系统带来的优势之前，让我们先退一步，分别研究一下消息队列和流技术。

流系统是行业中相对较新的创新技术，它可以以有序、低延迟的方式移动大量数据。流系统非常适合于移动数据（比如：日志、指标或者点击事件的数据等）并将其集中到一个位置，同时实现高并发和高吞吐。

举个例子，比如从大型云部署中的 10,000 台机器中获取点击或者指标数据。流系统为这一操作过程提供了便利。

某种程度上，消息队列与流系统有些类似，即将多个系统链接在一起。然而，消息队列历史较久，而且更多地是关于点对点的通信，帮助广泛的应用程序交换信息。

这两种系统的访问模式也是不同的：流系统专注于按照顺序到达的消息和处理同一批的多个消息组，可能也用于聚合或转换数据。

相比之下，在消息队列中，事件通常是一次处理一个。就像在工作队列中一样，每个消息可能就代表某个特定的“任务”。换句话说，流用于移动和处理大量的数据组，而队列往往是关于单个消息的精细化处理，以促进系统中的某些工作。

最常见的流平台是 Apache Kafka 和 AWS 的 Kinesis。最常见的队列系统包括 RabbitMQ 和 ActiveMQ。在云上，还有 Google 的 Pub/Sub、AWS SQS 和 SNS。

Apache Pulsar：统一消息队列和流

首先，简单回顾一下历史。

由于需要对非常大规模的工作负载进行队列化，Yahoo 内部最初是在 2010 年左右开发了 Pulsar 。Yahoo 服务规模庞大，分布在许多不同的团队和数据中心。

当时，他们正在使用 流行的 Java 社区标准 Java 消息服务（JMS），这，就需要一个新系统既可以满足 JMS 标准要求，又能具备分布式和可扩展性。

尽管 Pulsar 早期原型系统 API 最初专注于消息传递这一场景，但该系统的架构设计也使其成为流系统任务处理的理想方案，这使得 Yahoo 团队能够在更广泛的场景下灵活使用该系统。

这项被称为 “Cloud Messaging Service” 的服务在 Yahoo 内部落地非常成功，广为人知。借此势头，Yahoo 继续在内部开发 Cloud Messaging Service，并于 2016 年将其开源，这就是 Pulsar 项目的由来。

2018 年，该项目毕业成为为 Apache 软件基金会的顶级项目。从此之后，Pulsar 在全球企业的落地迅速增长。原因显而易见：许多企业如 Yahoo ，都需要更具可扩展性的消息系统解决方案。

虽然像 Apache Kafka 这样的流系统有能力进行进一步的扩展 （在数据再平衡方面仍需要投入大量的人力）— 但其流系统的 API 功能仍然有些差强人意。它不仅要求开发者在纯流模式的限制下工作，同时还要求开发人员学习一种新的思维和设计方式，这使得消息场景变得更加困难。

但有了 Pulsar ，情况就截然不同了。开发人员可以使用熟悉的 API， 以熟悉的方式工作；同时也提供了更多的可扩展性和流系统的能力。

同时满足可扩展消息服务和流处理这两个需求是我在 Instructure 的团队面临的挑战之一。为了解决这个问题，我们发现了 Pulsar。

Instructure 的大规模业务场景需要高可扩展消息系统支撑。起初，我们试图通过围绕流系统技术架构来重新构建。机缘巧合之下我们发现 Apache Pulsar 可以帮助团队在不需要基于流重新设计构架的复杂性的前提下去获得所需要的消息系统能力。

当 Instructure 团队开始使用 Pulsar 时，Pulsar 的带来的好处立竿见影，于是便在生产系统上开始大规模部署 Pulsar。Instructure 采用 Pulsar 后，应用程序之间的通信变得更加便捷，我们也可以在各个团队之间共享数据。

然而，Pulsar 不仅能很好地解决消息工作负载，其所支持的流处理也是大多数企业内部存在的真正需求。Pulsar 提供了一个比其他流系统更容易使用、操作和集成的系统。

例如，Pulsar 高可扩展。当需要增加集群规模时，用户不需要 “rebalance” 集群。它在支持多租户和数百万级主题的同时，也不会大幅增加延迟，这使得许多团队可以轻松共享一个集群。

这意味着企业不再需要在研发自己的工具上投入大量精力。他们从而可以专注于从消息和数据中挖掘价值，而不是在管理基础设施上浪费过多时间。

对于 Iterable （著名跨渠道营销平台）来说，Pulsar 提供了可扩展性、高可用性来取代 RabbitMQ 并最终取代 Iterable 内部其他消息系统——包括 Kafka 和 Amazon SQS。正如 Greg Methvin 所指出，Apache Pulsar 不仅非常适合流处理场景，也非常适合消息队列需求。

Apache Pulsar 优势

已经采用了 Apache Pulsar 的人可能已经发现，与同类别的 RabbitMQ 或 ActiveMQ 等系统相比，Apache Pulsar 提供了更具可扩展性的消息队列功能，以及更多的可扩展和更易上手的的流系统功能（其内置功能包括跨地域复制和多租户）。

值得一提的是， 使用 Apache Pulsar 是一个简单的数学题：一个统一了流和消息队列的平台比同时运维两套流平台和消息队列平台少至少一项技术。用户只需要使用一种技术就可以更轻松地开发产品并将其推向市场，且更高效高质量地利用企业已有数据。

除了增加的 IT 成本和运维两种独立技术的支出外，流系统和队列系统还没有很好地集成，从而导致数据孤岛现象的出现。而当拥有了一个统一的系统时，你可以处理更多事情，也可以基于同一底层系统打通各种数据和应用程序、数据查询、数据分析、流系统等。

使用 Apache Pulsar 时无需将数据导出到另一个系统或团队中，因为企业基于同一项中台技术、同一个中台存储服务来囊括数据的整个生命周期，用户不再需要手动处理数据生命周期的不同阶段。有了 Apache Pulsar ，架构得到极大简化，数据流转和数据治理也更加轻松。

正如 Iterable 资深工程师 Greg Methvin 所总结的那样，“Pulsar 的独特之处在于它不仅支持流和队列的场景，同时还支持更广泛的功能。它已是我们目前使用的架构中其他分布式消息系统的替代品。此外，Pulsar 还涵盖了我们对 Kafka、RabbitMQ 和 SQS 的所有使用场景，我们可以专心围绕单个统一系统去构建专业知识和工具。”

使用 Apache Pulsar，鱼和熊掌可以兼得。

关注公众号「Apache Pulsar」，获取干货与动态

加入 Apache Pulsar 中文交流群 👇🏻

​