Apache Pulsar：云原生时代的消息服务｜QCon

当新生事物出现时，人们总是有两种角度去观察它，要么把它看小，要么把它放大。

对于 Apache Pulsar 来说，把它看小的角度通常是“Apache Pulsar 只是一个新的消息队列而已“，或者“Apache Pulsar 只是一个新的数据管道而已”，又或者是“队列系统早就有了，只是 Apache Pulsar 更具扩展性也能解决某些场景问题而已，基本没啥本质区别”。

那么，事实果真如此吗？

带着这些问题，InfoQ 记者在 QCon 2021 全球软件开发大会上采访了 StreamNative 联合创始人、Apache Pulsar 和 Apache BookKeeper PMC 成员翟佳，和他聊了聊 Apache Pulsar 的历史、特点以及未来的趋势。

以下是视频采访的全部内容，为方便读者查看，视频下方也附上了文字内容。

InfoQ：翟老师，你好，欢迎来到 QCon 大会并接受我们的采访，请您先自我介绍一下吧。

翟佳：主持人好，我叫翟佳，来自 StreamNative，现在主要是做 Apache Pulsar、Apache BookKeeper 相关的设计和开发，也是这两个开源项目的项目管理委员会成员。更早之前，我还在 EMC 做过分布式文件系统的设计和开发。

InfoQ：我在 Pulsar 官网上看到它是这么定义的，它说 Pulsar 是一个云原生的分布式消息和流平台。在中文媒体的很多宣传里，对于 Pulsar 的定义怎么说的都有，我姑且就把它理解为是一个新一代的 Kafka。那么很多公司其实是把 Kafka 当成消息系统使用的，所以我想请你来聊一聊，这些年来开源消息系统都经历过怎样的迭代？

翟佳：你刚刚提到的消息系统确实是 Pulsar 诞生的一个初衷，因为在 2011 年、2012 年的时候，在雅虎内部需要解决的就是一个消息系统统一的问题。当时比较流行的 ActiveMQ、RabbitMQ 在雅虎内部也都有使用，所以 Pulsar 诞生的一个场景也是做内部的一个统一，要替换 ActiveMQ、RabbitMQ 这样的消息系统。也就是你刚才提到的 MQ 的场景需求。

你刚才也提到 Pulsar 是云原生的，这跟它当初诞生时雅虎的环境有关。雅虎当时是 Hadoop 生态的一个主要缔造者，它是先有的底层的存储层，也就是 BookKeeper 这样一个项目。我们之所以说它云原生也是因为 Pulsar 采用了一个存储和计算分离的这样一个架构，存储层就是我们刚刚提到到 BookKeeper，BookKeeper 它在雅虎内部主要是解决 Hadoop 生态，也就是 HDFS、NameNode 这样的一层 HA。你可以认为它是做元数据的存储，所以它有很高的一致性。刚好它又是一种 Log 的抽象，就是用 append-only 的模式，它跟我们提到的 MQ 的场景很类似，新的消息不断地追加，然后这个模式刚好可以应用在消息这个领域里面，所以它对云原生路线的选择跟它的技术背景有关系。就是先有了很优秀的、能够提供很好服务质量的存储系统，然后才有了 Pulsar 这样的存储和计算分离的架构。

有了这样的系统之后，它由于有存储和计算分离的架构，有 Write-Ahead-Log（WAL）存储层的抽象，它不仅可以支撑很多 MQ 的关键业务场景，不丢消息，对一致性要求很高，又可以提供比较高的带宽、比较低的延迟。所以这是很多用户把它用在原来 Kafka 的场景里面的原因。可能最开始的选择是 MQ 的方向，但是由于架构、由于本身存储层的特性，也会用到一些 Kafka 的场景里面，这是它跟 Kafka 的关系。

InfoQ：刚才你提到 Pulsar 是诞生于雅虎，你能更详细的介绍一下这个项目诞生的背景吗？这些年 Pulsar 发展得怎么样？

翟佳：Pulsar 的诞生我们刚刚提到过一点，开始做这个项目是在 2012 年，在当时，2011 年国内诞生了 RocketMQ，再往前一年，2010 年诞生了 Kafka，然后 Pulsar 在 2012 年诞生。

在 2012 年要选择云原生的存储计算分离的架构是一个很有挑战的事情。因为当时单个节点的网卡，单个节点的磁盘可能都不适合云原生这样的架构。所以在 2012 年之前，也就是 2010 年下半年到 2011 年，雅虎内部做了一个 Pulsar 的原型系统，它叫 HedWig。它主要是做这样的一个尝试：就是存储计算分离这样的架构能不能服务于消息这个场景。所以它诞生可能更早一些，先有 HedWig 这样一个原型系统，然后再立项 Pulsar。Pulsar 开源之前在雅虎内部的代号叫 CMS（Cloud Message Service），所以说它最开始诞生的初衷就是要做一个云的消息的服务。

有了前期原型系统的铺垫，决定了云原生这个路线之后，再往后 2013 年主要是做功能开发，2014 年开始在雅虎内部大规模部署，在雅虎内部经过线上产品的检验，又稳定运行了一两年以后，在 2016 年开源出来，2017 年捐给 Apache 软件基金会，2018 年从 Apache 软件基金会毕业成为顶级项目。

捐给 Apache 软件基金会之后，这个项目就开始了一个快速的发展期，很多国内外的互联网公司都开始使用 Pulsar，因为它确实解决了 MQ 场景里的问题，也解决了 Kafka 场景里面的一些问题。

特别是在 2019 年有了我们商业化的公司 StreamNative 的成立，用户对这个项目就更有信心了。包括腾讯最开始上线的一个很关键的业务场景，就是腾讯计费平台，也都是基于 Pulsar 来做所有计费的业务。还有国外的 Splunk 以及雅虎内部也有很多的场景都使用了 Pulsar，这样 Pulsar 的生态也随着我们国内外社区不断地成长，发展得越来越好了。

在 2018 年成为顶级项目之前，GitHub 的 Star 数增长虽然还好，但不是那么显著，在 2018 年底变成顶级项目之后，2019 年公司（StreamNative）成立，Star 数的增长就更加迅速了。我觉得国内的开源土壤对我们开源社区的构建，对我们开源项目初期的成长有很大的帮助。

InfoQ：我看到网上很多人对比 Kafka 和 Pulsar，包括刚才我们也做了一个对比，那你怎么去看待这两个技术呢？

翟佳：我们刚刚也提到，Pulsar 项目诞生的背景就是要解决雅虎内部的需求。它要有大集群、多租户的能力，能让雅虎内部各个业务部门的数据打通，所以它诞生的初衷不是为了去做 Kafka 的事情，大家都在同一个时代。

而且在 2012 年 Kafka 也没有像现在这么火，Pulsar 还是从自身的角度出发，就是要解决雅虎内部的问题，然后就有了这样的产品。之后它又选择了开源的路线，让产品变得更加稳定，能够借助社区给它添加更多的功能。所以说它最开始不是专门针对 Kafka 而设计的，但是诞生之初，它的设计为了解决自身的问题，会考虑到更丰富的应用场景，考虑自身业务的一些需求，所以说它确实也能够支撑 Kafka 所对应的一些业务需求。自然而然地，在开源之后，可能它解决了 Kafka 用户的一些痛点，被一些用户所选择，但这是一个自然而然的过程，并不是专门针对 Kafka 来做这个事。

InfoQ：郭斯杰之前说过，消息、流、存储将会逐步融合，你怎么理解这个观点呢？

翟佳：刚刚提到三个方向，消息、流和存储。我发现消息和流是很相关、模式也很类似的两个系统，你的消息也是需要一个载体来提供消息的存储和服务，消息进来的模式也是要按照时间、用户的数据等等固定的顺序，这样才能对外提供顺序性和一致性的保障。

流的场景也是一样，所有的数据源源不断地流入，然后按照时间顺序来做一个消费，所以从这个角度来看，它们两个是很贴近、概念很类似的一个场景。只不过在之前可能由于技术架构的原因，我们把消息和流分成了两种模型。在很多企业内部关键的业务场景里用各种 MQ 来保证消息的服务，在数据管道这种场景下用 Kafka 提供流的服务，但是本质上来说它们都是一样的，只是之前由于技术原因，把它们天然做了一个分隔。

Pulsar 的一个优势是它有很好的底层储存层 BookKeeper，它既可以保证很高的一致性，也可以通过 append-only Write-Ahead-Log（WAL）这种抽象来保证比较高的吞吐，它可以从技术上解决两个场景不同的需求，所以 Pulsar 从这个角度提供了很好的消息和流的融合。

在存储这个方向，之前大家可能把消息的存储这个事情看得有些太简单了，有很多用户认为我的消息要做系统解耦，在 MQ 的场景里面，可能有很多的消息都是从内存里直接就把消息消费完了，很少有需要把消息落地、存储的场景，所以当时的实现都很简单，包括 Kafka 在内，大家都是把消息直接落到文件系统里面，怎么简单怎么实现，这样对很多关键的业务场景，对很多需要数据堆积的场景来说，如果单单依靠一个文件系统来做，你的服务质量，你的稳定性可能就不太容易保障，因为文件系统不是专门为这个场景设计的，比如说你在 MQ 场景，我需要实时地刷盘，我需要保证这个数据持久性，它的备份数以及一致性要足够高，这个场景下它的性能可能就会降下来了，这也是我们说随着用户的应用数据场景不断丰富，随着你对消息系统的要求不断提高，它对底层消息系统的一些要求也会改变。所以现在来看，随着大数据的发展，随着用户数据量的提高，Pulsar 真正发挥了它的价值，它有一个专门为消息做的存储层，有了这样一个存储层，它可以跟我们刚刚提到的消息的服务、流的服务能够很好地结合起来。

所以说消息、流和存储在 Pulsar 这边是一个融合的方向，是一个融合的架构，这是我们从 Pulsar 这个角度来看这三个方向时一个很直观的感受。

InfoQ：Pulsar 之所以敢说它是新一代的消息系统，那它肯定是顺应了一些趋势，除了前面的消息、流、存储的趋势外，你们还看到了什么样的趋势？

翟佳：我们觉得这个趋势可能就是我们在第一个问题中提到的，它和云原生比较相关。因为云原生是一个很大的趋势。刚刚我们也提到过，Pulsar 选的这套架构，当时也是一个很超前的架构，在 2012 年它就选择了存储计算分离这样的架构，它具备云原生这个优势，同时再结合 Pulsar 本身每一层节点都是一个对等的架构，这样会对线上运维有很大的帮助。包括我们说在你的服务层，你所有的 Broker 都是一个对等的架构。然后你的存储层 BookKeeper 也是一个对等的架构。这样你扩缩容的时候，你的大集群不用维护每个节点 master/slave 的状态。它的维护更加简单。同时我们在云上有一个很重要的初衷，就是我要做一个弹性的资源调度，从这个角度来说 Pulsar 也是刚好顺应这个趋势，跟它诞生的代号 CMS（Cloud Message Service）是一脉相承的关系，就是要做一个消息的云，要把云上的各种资源能够很容易地调度起来，能够为消息系统做一个服务。所以我觉得云原生是 Pulsar 很大的一个优势，也是我们顺应的一个大趋势。

InfoQ：所以说现在 StreamNative 公司就是基于开源的 Apache Pulsar 来构建你们的商业模式对吧？

翟佳：对。

InfoQ：能否聊聊你们创业的一些背景以及具体的商业模式？

翟佳：StreamNative 是 2019 年 1 月份成立的，公司的创始成员都是 Pulsar 和 BookKeeper 背后的核心开发者和维护者，创立这家公司主要的一个初衷是希望把 Pulsar 这个技术能够推广开，能够真正解决现在运维人员、业务人员它们遇到的消息系统里面的一些问题。

有了这个初衷之后，我们发现，相比在国外，在国内做社区可能会更有优势一些，因为国内有更多的用户，有更大的数据场景可以更快地帮开源系统做迭代，所以我们就选择了从社区先出发，通过跟社区用户的合作，共同打造一个更加完善更加稳定的消息系统。

这可能跟很多开源商业化公司最开始的步调是一致的。最开始有一个活跃的社区，有足够丰富的功能吸引社区的用户。在这个基础之上，再去考虑我们的商业化，所以现在我们的商业化版本也都是基于社区的版本，Pulsar Core 和我们自己商业化版本里面用的 Pulsar 都是一模一样的。每次 Pulsar 发版之前，我们会把自己内部的改动贡献给社区，保证我们的版本是一致的，再一起往前走。对用户来说，他们可以享受到 Pulsar 最新的一些特性，包括一些很好的企业级特性。比如说 Pulsar 开源之初自带的多租户、跨集群的复制特性，这些跟业务、运维直接相关的很强大的一些功能，能够帮用户解决很多问题。

我们商业化的产品还是依照 Pulsar Core 来，但是也有一些不同的地方，比如对于很多小企业的用户来说，他们比较关注的很多跟运维监控、安全、Audit、消息的 tracing、LDAP、鉴权认证、实时监控等等这些周边的功能会放在我们的闭源版本里面，这些功能可能不会影响社区大部分用户，只是有一些用户对这些刚好有很强的需求，又需要有一些商业化团队的支持，这类用户可能是我们特定的一个目标。这是我们商业化的一个初衷，Pulsar Core 这一块我们会跟社区保持一致，在 Pulsar Core 周边的一些服务是我们商业化产品的一些主要特性。

InfoQ：那你怎么看 Snowflake 这家公司？

翟佳：我觉得 Snowflake 这可能跟我们的路线不太一样，我们还是依托社区，靠社区来做很多 inbound request，然后培养社区，社区里面有一部分人愿意付费，愿意来找我们，买我们的服务。

Snowflake 走的是一个闭源的路线，我觉得 Snowflake 和 StreamNative 走的一个共同的方向其实是 SaaS，就是走云服务这一块，这一块我们看到的路线是有点类似的，因为我们刚才提到 Pulsar 很好的一个优势就是云原生，我可以很好地借助云上的资源，满足很多在云上的弹性调度、安全、多租户等等需求，可以跟云更好地结合在一起。

Snowflake 是做云的数仓，我觉得 Snowflake 解决的很直接的问题就是要降低用户的使用成本，它的计费模式不是按照你集群付费，而是按照你的使用量来计费，这样对于用户来说，你的成本可能就会更低。

我们在云上也会有一套跟 Snowflake 类似的系统，这个系统也是可以跨多云，同时也是按照用户的使用量来计费。从这个角度来说，大家的初衷都是一样的，就是希望在减轻用户的管理运维成本的同时，降低你的 TCO，降低你总体使用的成本，这也是我们说云吸引用户的最主要的原因，它也是一个更弹性的，按照你的用量来计费的这样一个思路。

我们跟 Snowflake 不一样的地方，我觉得我们主要还是从开源社区去做推动，而 Snowflake 可能更加注重商业化方面的事情，这也是我们未来需要多提高的地方。

InfoQ：好的，谢谢翟老师。

翟佳：感谢主持人。