关于作者
张居开，科拓停车成都研发分中心架构师，负责数据同步链路、中间件的预研、自建工作，同时主导或参与数据中台以及各业务线的复杂业务和技术难点攻关。Canal Contributor，主要贡献为在 Canal 1.1.6 版本贡献了 Pulsar 集成特性。

导读

科拓停车目前是智慧停车行业 Top3 的领军企业，其业务涵盖智慧停车解决方案、车场运营管理服务、互联网智慧停车平台、停车场增值服务等板块；旗下“速停车”平台已成为目前微信生态主流智慧停车平台之一。科拓停车成都研发分中心的主要职责包括技术和数据中台、城市停车平台，以及一些 C 端业务和中间件预研工作。 

场景介绍

智慧停车以停车位资源为基础，将无线通信技术、移动终端技术、GPS 定位技术、GIS 技术等综合应用于城市停车位的采集、管理、查询、预订与导航服务，实现停车位资源的实时更新、查询、预订与导航服务一体化，实现停车位资源利用率的最大化、停车场利润的最大化和车主停车服务的最优化。我国智慧停车行业起步较晚，现处于加速发展阶段，停车场能够实现无人化管理，车主自助完成入库、缴费和出库。

智慧停车产业链参与者包括上游设备供应商、中游智慧停车解决方案、下游智慧停车方案需求者。其中上游设备商可分为硬件、软件两类，硬件主要包括高清摄像头、地磁车检器等设备，软件则包括云计算、储存、信息处理等设备；中游为智慧停车方案提供商；下游为智慧停车方案需求者，包括政府、停车场商、车主等三类用户。

核心业务发展历程

1. 早期缴费流程

车辆到达出口➝岗亭保安算费用➝跟车主收现金➝找零➝开闸放行

2. 过渡缴费流程

车辆到达出口➝LED屏显示费用➝跟车主收现金➝找零➝开闸放行

3. 电子支付流程

扫单车场码/扫出口静态码/扫缴费机动态码➝付费离场/无感离场

整个发展历程主要解决的是停车场出口因缴费导致拥堵的问题。

业务对消息总线的需求

整体业务对消息总线的需求主要来自于两个方面：数字化转型与业务扩展，具体体现在以下几个方面：

1. 线下车场、设备、订单信息、进出车数据等如何上云
2. 整个链路如何满足日益增长的数据量
3. 核心关键业务如何保障稳定、高效、低延迟
4. 需要契合公司云原生发展方向，易于管理，易扩展

消息总线架构演进

1.0 - 单通道公有云架构

在业务初期，MQTT 服务、RocketMQ 与业务项目部署所使用的服务器均采购云上产品，这样能够快速搭建起整个业务链路，保障业务正常上线投入使用。随着业务的扩展、用户体验要求的提升，原有的单通道链路难以满足业务的吞吐量、可靠性等指标需求，整个系统的稳定性、可靠性、及时性等都有了更高的要求，我们在单通道架构的基础上设计了双通道架构。这也就是消息总线架构 2.0 版本。

2.0 - 双通道公有云架构

在新的架构中，车场对业务核心数据进行上报时会同时向两个通道发送，由业务系统做去重处理。这样设计的目的是提升可靠性，防止因数据传输延迟失败造成终端客户出现无法结账离场等故障。整个消息链路已经能够很好地支撑我们的业务，同时 MQTT 和 RocketMQ 属于云产品，拥有大部分云原生产品的特性，在遇到节假日流量高峰期时，能够通过横向扩展支撑业务的扩张。

但是整个架构同样存在几个比较严重的痛点：

1. 原有的 MQTT + RocketMQ 的组合难以满足上万车场的吞吐量需求和低延迟需求。
2. 云端服务的可靠性为 99.99%，意味着每年会出现约50分钟的故障时间，在业务侧是无法接受的，很容易出现群体事件。
3. 公司核心业务完全依赖具体的云服务商产品，后续可能出现多云业务、私有云业务、甚至迁移到其它云服务商的业务，如果其它云服务商没有对标的产品，那么会非常的被动。
4. 随着业务的发展，数据同步任务需求增加（DTS），加上数据入湖、数据中台的建设等因素，导致我们需要长期运营、维护多条消息链路的不同技术栈。
5. 随着业务的扩展，云上产品使用量的增加，带来成本的剧增。
6. 从长远发展、降本增效等方面考虑，最终我们采取了全链路自建的方式，下面主要通过三个方面介绍我们在自建消息总线的过程中对 Apache Pulsar 的运用与实践。

新一代架构：Apache Pulsar 实践

为什么选择 Apache Pulsar

科拓停车在继续改进消息总线的过程中，对消息总线提出了“高吞吐、低延迟、高可用、易扩展、多租户、易管理和 MQTT 桥接”等要求，并基于此对 Apache Pulsar 进行压力测试。经过对比，Apache Pulsar 可以满足上述要求，且在管理、监控、报警方面有完善的工具链，能够降低运维压力。

在科拓的整个技术架构发展的过程中，我们希望通过使用 Apache Pulsar 来统一业务上的消息总线和数据同步链路中的消息中间件，在获得更高的性能、稳定性、可扩展性等的同时减轻整个团队的技术债务。

为什么选择 Apache Pulsar，主要有以下几个因素：

1. Apache Pulsar 特性亮点

1.1 云原生：符合我们整体技术规划，我们的业务很明确，白天流量高，深夜和凌晨流量低，对系统的弹性有需求；
1.2 存算分离，易于扩展；
1.3 多租户：便于各业务组之间通过租户进行隔离，同时能够支持大量 topic 的场景；
1.4 基于 Java，社区活跃度高。

2. 自建 MQTT 的对标方案 EMQ 默认提供 Apache Pulsar 桥接功能，无需做二次开发。
3. 数据同步链路中的 Kafka 在某些方面不如 Pulsar，比如：Kafka 横向扩容时对性能的影响较大，topic 过多时性能受影响较大等。

以下是 RocketMQ、Kafka、Pulsar 的对比情况：

3.0 - EMQ + Pulsar：自建业务消息链路

要自建整个业务的消息链路，需处理 MQTT 和 RocketMQ。通过对相关技术的预研、比对，最后的消息链路架构如下：

在自建的过程中我们做了如下几件事情：

1. 用 EMQ 替换 MQTT，用 Pulsar 替换 RocketMQ；
2. 通过 EMQ 桥接功能实现将 EMQ 的消息推送到 Pulsar：桥接是 EMQ 产品内部的实现，通过在管理系统里面做相应的配置可以将 EMQ 中的消息转发到 Pulsar 中；
3. 通过自研的 Sink 程序实现 Pulsar 中的消息下发到 EMQ：Sink 程序是 Java 实现的，通过 Pulsar client 消费消息，再通过 MQTT 协议将消息转发到 EMQ。由于我们自建时 MoP（MQTT-on-Pulsar）尚未开源，并且自建系统一直很稳定，后续未对自建系统进行调整。
4. 所有需要使用到消息总线的线上业务系统统一使用 Pulsar。同前面提到的双通道公有云架构类似，核心的业务逻辑消息都是走双链路，其他业务方在使用时也会根据具体情况选择单链路或双链路。

Pulsar 作为数据同步链路核心组件

我们基于 Canal 二次开发自建数据同步链路，总共有两个大的版本，V1.0 架构如下：

在这个版本中对 Pulsar 的运用相对较少，而在 V2.0 核心系统的跨云数据同步中，我们对Canal、Canal-admin、Canal-adapter 都做了不少定制化开发和优化。V2.0 完全采用 Pulsar 作为消息中间件，同时我本人也是 Canal-1.1.6 版本中 Pulsar 集成的核心 Contributor。

V2.0 的架构和 V1.0 的类似，流程上是一致的，我们可以通过下面的一张图来简单看下Pulsar 替换 Kafka 后的具体应用细节以及所带来的好处，如图所示：

1. 多分区：我们以前使用 Kafka 的时候使用单分区，当时没有深入研究。集成 Pulsar 后实现了根据配置自动创建自定义分区数的 topic；
2. 高可用：Canal-adapter 在消费 Pulsar 消息时采用的是 Failover（灾备）模式，在多分区场景下真正实现多个 adapter 的集群化，从而实现高可用；
3. 低延迟：实现了在有限的资源内跨云同步核心系统近百万张表的数据，数据延迟稳定在 2s 内，当然这期间对 Canal 也做了一定的优化；
4. 采用 Pulsar Function 按车场 ID 进行分流，计算每个车场的流量等数据信息。

未来规划

1. 基于 K8s 实现弹性伸缩

针对公司白天流量高、凌晨流量低的业务场景，以及公司整体业务支持容器化部署的发展规划，我们最终会将 Pulsar 上K8s，和部分业务一样实现弹性伸缩。结合 Spark on K8s 的运用，能在流量低峰期为离线任务提供一定的计算资源，实现资源的最大化利用。

2. DeltaStreamer 定制开发，支持 Pulsar 消息入湖

目前数据入湖（Hudi）整个消息链路还是使用的 Kafka，为了实现最终消息链路的统一，DeltaStreamer 需要定制化开发来支持 Pulsar。目前我们数据入湖同时使用 DeltaStreamer 和 Flink on Hudi，两种技术方案各有优缺：

• a. DeltaStreamer：稳定；数据延迟高，资源消耗大；
• b. Flink on Hudi：资源消耗较低；大表同步效果不好，数据延迟较低。

3. 增强部分 Pulsar IO 的应用

我们基于 Canal 定制了可视化配置的数据同步，所以对 Pulsar Connector 运用相对较少。目前期待 Pulsar 入湖相关 connector 的开发进展。