Apache Pulsar PMC成员翟佳：Pulsar 2021 展望与规划
导读
在 2.28 TGIP-CN 直播活动上，我们邀请到 StreamNative 联合创始人兼 CTO、Apache Pulsar PMC 成员翟佳，他为大家分享了 Apache Pulsar 2021 年展望与发展路线图。下面是翟佳分享视频的简洁文字整理版本，供大家参考。
Hi，各位小伙伴好，我是来自 StreamNative 的翟佳，欢迎大家参加牛年第一场 Pulsar 社区的 TGIP 活动，在此与大家分享 2021 年 Pulsar 项目和社区主要规划。
（扫描二维码可以观看视频并下载 PPT）
在这之前，我们先做一些简单回顾，帮助大家进一步熟悉 Apache Pulsar。
Apache Pulsar 基础回顾
在 Apache Pulsar 出现之前，消息领域分为两个场景：RabbitMQ、Kafka，它们的消费模式、架构、实现方式很不一样。Apache Pulsar 的出现，一方面为既定局面带来一些活力，起到“鲶鱼”的角色，比如促进 Kafka 的发展、RabbitMQ 的改进；另一方面 Pulsar 融合了这两种场景，通过 Pulsar 本身带有的能力，大大减轻用户在消息场景运维和使用的困难。
为什么采用 Pulsar ？
Pulsar 架构之坚实基础
Pulsar 有两方面坚实的基础：
•拥有云原生的架构，存储和计算分离；•拥有专门为消息和流存储而设计的存储引擎。
上述 Pulsar 云原生的架构，为 Pulsar 带来以下三个特点：
•灵活扩容；•独立扩展；•快速容错。
Apache BookKeeper - 为消息、流专门设计的存储引擎
除了云原生架构，Pulsar 另一方面的优势是有为消息、流专门设计的存储引擎：Apache BookKeeper，它的特点如下：
•低延时、高吞吐、持久化；•强一致；•高可用；•I/O 隔离。
BookKeeper 不单单可以用来存储消息，也可以用于存储元数据。
有了上述两个坚实的基础，就可以在 Pulsar 之上构建其它对用户友好的一些 feature，比如构建 Pulsar 大集群、支持多租户。
跨地域复制
除此之外，跨地域复制对开发者比较友好，与 Pulsar 中很多异步的操作相关，能保证 Pulsar 提供很高的带宽、很低的延迟。
跨地域复制对开发者友好，体现在：
•Broker 原生；•Pub/Sub 一体；•管理简单：只需要一两条 NameSpace 的 Config 命令就可以自动搭建跨地域复制的集群；•配置灵活：默认全联通、集群间互联互备等。
Pulsar 内置的诸多特性与优势，不断吸引越来越多的开发者来使用它。
Apache Pulsar 的发展历程
基于图中 Github 的 Star 增长情况我们可以很直观的看到：
从 Pulsar 开源到 2018 年 9 月毕业成为 Apache 顶级项目，经过两年多的高速的发展，在 Github 有 7300+ Star，全球贡献者超过 370 位，感谢大家对 Pulsar 的认可！
从曲线上可以看到一些拐点，比如 18 年毕业成为顶级项目、19 年、20 年都会有特殊拐点：
第一个时间点是 2018 年 9 月从 Apache 软件基金会毕业成为顶级项目。2019 年 8 月我们举办了一场全天 Meetup，也邀请到了亚洲其他的小伙伴比如 Yahoo！JAPAN 分享实践经验。2020 年，StreamNative 申请组织策划了两场 Pulsar 峰会，包括 2020 年 6 月 Pulsar Summit NA（针对欧美开发者）；11 月举办了 Pulsar Summit Asia 亚洲峰会，进行了 2 天，共有 40+ 演讲，三个论坛。
如上图，2020 年很多国内、国外的小伙伴积极地拥抱 Pulsar 开源社区。近期我们也启动了一个活动，征集已落地 Pulsar 的企业组织，将其标志上传到 Pulsar 官网，如果有小伙伴希望自己公司的标志获得展示，请点击长期活动 | Apache Pulsar 官方：部署企业标志上传征集提交。
上述公司大部分属于互联网公司，当然我们看到也有电商、零售、金融、教育、安全、电信、IoT、直播领域，他们都在使用 Pulsar 。
2021 Pulsar 的主要规划
如上图，Pulsar 作为一个流原生消息平台，主要包括存储（Stream Storage）、消息（Messaging）、计算（Processing）三个方面的工作。
Messaging 是 Pulsar 诞生之初的一个主要方向。在这个方向我们提供了多语言客户端的支持、通过 Pulsar IO 和外部系统打通，还有通过 Debezium 来做 CDC 的支持等。
经过 18 年到 19 年的发展，社区在上图蓝色 Processing 方面做了很多的工作，与 Queries 的引擎比如 Presto 和 HIVE 进行深度整合，让 Presto 和 HIVE 能够直接读取 Pulsar 的 topic ，再结合 Pulsar 本身自带的 Schema，将 Pulsar topic 作为的一个表直接查找 Pulsar topic 中的数据。在 Streaming & Batch Processing 方面，与大数据处理引擎包括 Storm、Flink、Spark 进行深度整合。在 Processing 方向的思路是与现有的大数据生态做深度的融合，让大数据生态能够更好地访问 Pulsar，把 Pulsar 当作数据的存储引擎。
除此之外，Pulsar 推出了 Pulsar Function — 一个轻量级的计算框架。Pulsar Function 可以减轻很多数据的传输，可以靠近数据端完成计算，目前很多 IoT 场景的用户如涂鸦智能、EMQ、中国电信及一些车联网公司都在使用 Pulsar Function。
除了 Messaging 和 Processing ，Pulsar 拥有一个很坚实的基础，就是拥有专门为消息、流存储而设计的存储引擎 Apache BookKeeper。结合 Pulsar 对分区再分片的存储特性，我们很自然地把老的分片迁移到二级存储中，所以 Pulsar 的架构很容支持二级存储。二级存储的介质包括云上的各种资源：S3、HDFS…2020年，我们在做一些尝试，比如在数据从 BookKeeper 搬移到二级存储的过程中，把 Pulsar 的消息变成列存的格式，直接存储在二级存储中。
总体来说，Pulsar 现在不单单集中于消息这个方向，在计算、存储方面也有很大加强。
消息领域
很多用户在使用 Pulsar 的过程中，会发现客户端应用的改造和迁移会很难落地。比如 Kafka 往 Pulsar 迁移过程中，客户很可能也会有大量基于 Kafka Clients 的应用需要更改，由于需要更改协议导致迁移很困难。
由于短时间不可能完全从 Kafka 迁移到 Pulsar，导致对后台的运维甚至整个业务的切换带来很大的不便捷性。
Pulsar 和 Kafka 一样是以 topic 作为基础，以 log 作为抽象，Pulsar 的一致性、延迟、吞吐会更优，在这个基础上要复用 Pulsar 的存储层，在 Broker 端实现协议的解析，用户的切换成本更低。所以我们开始尝试在 Pulsar Broker 端提供 Protocol Handler 插件（现在已经实现 Kafka、AMQP、MQTT 协议的支持）的方式来支持多种协议。这种在 Broker 端做协议解析的方法，可以更方便地支持多种协议。其次还利用 Pulsar 在存储层拥有存储、计算分离的优势，服务上层多种协议。
KoP（Kafka on Pulsar）
KoP 是我们在这个方向的第一个尝试。目前 StreamNative 联合合作伙伴已推出了 KoP 项目，主要满足想要从 Kafka 应用程序切换到 Pulsar 的用户的强烈需求。
KoP 将 Kafka 协议处理插件引入 Pulsar broker，从而实现 Apache Pulsar 对原生 Apache Kafka 协议的支持。将 KoP 协议处理插件添加到现有 Pulsar 集群后，用户不用修改代码就可以将现有的 Kafka 应用程序和服务迁移到 Pulsar，从而使用 Pulsar 的强大功能。
如图右侧是现有的 KoP 相关特性：
•Broker 的插件，Client 不需要做任何的改动；•共享访问；•支持 Kafka 0.10-2.x 版本；
KoP 当前版本还存在一些不足，2021 年会在几个方面进行优化改进：
•连续 Offset：详情可以参见 PIP 70[1]，增加对连续 ID 的支持。•性能改进：实现与 Kafka broker 类似的机制，无需 KoP 针对 Kafka 发送的 batch 消息进行拆包解包，将 Kafka 发送过来的消息直接以 Kafka 格式进行存储，并在 Pulsar Client 增加对 kafka 协议的解析器。•支持 Envoy，并实现 Pulsar Schema 与 Kafka Schema 的兼容。
KoP 目前主要由 StreamNative 与腾讯 TEG 同事进行协作改进，目前上述改进正在抓紧实现中，预计在 2021 年第 1 季度左右发布 KoP 新版本，在新版本中将解决上述提到的连续 Offset 与性能等问题。
AoP（AMQP on Pulsar）
AoP（AMQP on Pulsar）是 StreamNative 联合中国移动共同开发推进的项目，类似 KoP，主要解决 AMQP 应用程序迁移到 Pulsar 的需求。当前 AoP 实现了对 AMQP 协议 0.9.1 版本的支持，2021 年计划对 AMQP 1.0 协议进行整合支持。目前除了中国移动正在大规模应用 AoP 外，国外也有越来越多的用户正在使用 AoP，希望更多小伙伴加入到 AoP 使用中来，共同丰富 AoP 场景，协作增强 AoP 功能。
MoP（MQTT on Pulsar）
MQTT 协议在物联网应用十分广泛，类似 KoP、AoP，当前 Pulsar 也通过 MoP 项目提供了对 MQTT 协议的支持。当前 MoP 支持 QoS level 0、QoS level 1 协议，2021 年计划实现对 QoS level 2 协议的支持。
Broker 端规划
上述 KoP、AoP、MoP 规划都是我们针对消息解析方面的加强，除此之外，我们也规划了 broker 端的较大功能更新，如延迟消息、ReadOnly Broker、Transcation 等方面。
增强延迟消息，降低资源消耗
目前 Pulsar 已支持该功能，但当前实现方式过于简单，比较消耗资源。目前正在进行新的实现设计，新设计对用户提供的接口不会改变，但在 broker 端的实现会借助时间轮的方式，使得插入、查找、消息到期时间等处理更方便更高效，避免过度使用内存、重构 Index。预计延迟消息的功能增强会在上半年推出。
推出 ReadOnly Broker
对 Pulsar 和多数消息系统来说，当前一个 topic 分区只能为一个 borker 来服务，如果一个 topic 过热、有大量 consumer，这样就造成一个 broker 资源无法支撑，目前部分社区用户存在这样的场景需求。ReadOnly Broker 的实现，可以支持对一个 topic 的 consumer 过量请求分散在多个 broker 上，如此以来就能支持单 topic 上数十万级别 consumer 的支持。该功能将在 2021 年实现推出。
持续增强 Transcation（事务）
在 Pulsar 2.7.0 版本中提供了 transcation 开发者预览版，提供了 tanscation API、tanscation buffer 以及持久化相关的功能，但功能尚不完全。在即将推出的 Pulsar 2.8.0 版本中，transcation 将包括更多持久化方面的功能特性，并进行增强。
完善 REST 协议支持
目前 Pulsar 已经提供诸多语言的客户端，但也存在一个问题，就是除了原生以及官方维护的客户端外，其他语言客户端存在些许功能不足。如果同时使用多个语言客户端，这个问题将很棘手。针对上述问题，今年将在现有的 REST Protocl 中增加更多与读、写相关的 API，开发者就可以通过 REST 接口访问 Pulsar broker，对多语言的支持将更加便捷。可参见[PIP 64][2]，查看详情。
存储方向
下述几个方向是存储方面的功能更新。
去 ZooKeeper
有 Pulsar 社区成员担忧 ZooKeeper 的扩展性，关于这一问题，目前 Pulsar 社区已经启动去 ZooKeeper 进程，并已有多个 PR 合并，大家可以关注 [PIP 45][3]、[BP-29][4]、[BP-28][5]、[BP-30][6] 了解详情。
整体来说，去 ZooKeeper 会在 Pulsar 和 BookKeeper 社区两侧共同发力。从 BookKeeper 侧来讲分三步走：第一步，做 Metadata API 的抽象，将 ZooKeeper 当作 Metadata API 的实现；第二步，在 BookKeeper 中实现对 etcd 的支持，用 etcd 替换之前 BookKeeper 内部使用的 ZooKeeper；第三步，通过 BookKeeper 本身具备的 Table Service 提供自服务──三步走下来，BookKeeper 则能去除对 ZooKeeper 的依赖。在 Pulsar 侧，实现方式类似。
增强『批流融合』
我们希望把 Pulsar 当作在计算领域批流融合的存储引擎，因此计划加强批流融合的建设。在 Pulsar 中，对用户来说每一个 partition 不再是单一的整体，可以按用户制定的时间建立多个分片，Pulsar 内部可以管理分片。基于分片的架构可以将老的分片移到二级存储的架构中。现在社区正在推进 Streaming Offloader，即把分片大小和底层在二级存储的大小解耦。另一方面，社区也在推进 Columnar Offloader ，需要先和 Flink 和 Streaming Offloader 打通，还未做集成。为了开发者使用更加方便，目前进行了 Pulsar Flink 的兼容，把 Pulsar Flink Connector 捐献到 Flink 上游仓库，并在此之下支持批流融合。今年会有雏形和大家见面。
计算方向
Function Mesh
在计算方面，我们一方面的工作是与其他系统集成，以便让其他引擎更好地使用 Pulsar，另一方面则是优化 Pulsar Functions。下图是 Function 的抽象，计算对象是消息，计算模式如图所示。Function 对收到的每条消息进行计算并写进 Output topic，在 Function 中计算的消息也可以写到 Log topic。
Function 为开发者提供了很多便利，简单的计算都可以通过 Function 完成。我们希望为开发者提供更多的便利，可以将 Function 结合起来，由此提出一个新概念 Function Mesh。其主要基于 K8s 开发，现在这个功能已在 StreamNative 内部完成开发，正在测试阶段，欢迎大家申请试用。
WebAssembly Rust Runtime
Function 支持 Java、Python、Go 三种运行时，每一个运行时都类似于 Function worker，每添加新功能就需要在三种语言的基础上添加。为了增加维护的便利，我们计划推出 Rust 版本的 Runtime 封装。多种语言都可以通过 WebAssembly 的格式交给 Function worker，从而运行 Function。多种运行时集合成一套，不影响开发者的使用，但是增加了内部维护的便捷。
Pulsar 云服务
我们发现 50% 以上的用户将 Pulsar 部署在 K8s 上，StreamNative 做了很多入口工作。今年 StreamNative Cloud 计划增加对 MicroSoft Azure、腾讯云支持。国内小伙伴可以免费试用 StreamNative Cloud 在阿里云上的服务[7]，开启 Pulsar 云端之旅。
社区活动
目前 TGIP 国内外的直播已正常举办，大家可以通过参加 TGIP 直播获取第一手 Pulsar 资讯动态。因疫情的好转，我们也逐步开始启动线下 Meetup、Contributor Club 等活动，让 Pulsar 社区用户可以面对面地深入交流。
同时今年将举办至少两场 Pulsar Summit，目前 Pulsar 北美峰会讲师报名已启动。Pulsar 亚洲峰会将在下半年举办，希望能和大家在线下碰面。我们也申请参加 ApacheCon Asia 和 ApacheCon，欢迎使用 Pulsar 和 Apache 开源项目的小伙伴们积极参与。
结束语
我在上面从消息、存储、计算三个层面对 Apache Pulsar 项目做了简单回顾与 2021 规划展望，希望对大家深入了解 Apache Pulsar 有所帮助。Apache Pulsar 作为下一代云原生分布式消息流平台，项目和社区正在快速发展之中，希望更多开发者能够加入到 Apache Pulsar 社区中来，让我们携手共建更加优秀的开源项目和社区！
引用链接
[1] PIP 70: https://github.com/apache/pulsar/wiki/PIP-70%3A-Introduce-lightweight-broker-entry-metadata[2] [PIP 64]: https://github.com/apache/pulsar/wiki/PIP-64%3A-Introduce-REST-endpoints-for-producing%2C-consuming-and-reading-messages[3] [PIP 45]: https://github.com/apache/pulsar/wiki/PIP-45%3A-Pluggable-metadata-interface[4] [BP-29]: https://bookkeeper.apache.org/bps/BP-29-metadata-store-api-module/[5] [BP-28]: https://bookkeeper.apache.org/bps/BP-28-etcd-as-metadata-store/[6] [BP-30]: https://docs.google.com/document/d/155xAwWv5IdOitHh1NVMEwCMGgB28M3FyMiQSxEpjE-Y/edit#heading=h.56rbh52koe3f[7] StreamNative Cloud 在阿里云上的服务: https://streamnative.io/en/cloud/hosted