共计 3136 个字符，预计需要花费 8 分钟才能阅读完成。
本文翻译自《Apache Pulsar: A Unified Queueing and Streaming Platform》，作者 Addison Higham。原文链接：https://thenewstack.io/apache…
译者简介
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 中文交换群 👇🏻
