sharetwitterlinkedIn

支撑超万家停车场:科拓停车基于 Pulsar 的消息总线架构演进

August 12, 2022
head img

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

导读

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

场景介绍

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

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

核心业务发展历程

  1. 早期缴费流程

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

  1. 过渡缴费流程

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

  1. 电子支付流程

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

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

业务对消息总线的需求

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

  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,社区活跃度高。

  1. 自建 MQTT 的对标方案 EMQ 默认提供 Apache Pulsar 桥接功能,无需做二次开发。
  2. 数据同步链路中的 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 的运用,能在流量低峰期为离线任务提供一定的计算资源,实现资源的最大化利用。

  1. DeltaStreamer 定制开发,支持 Pulsar 消息入湖

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

  • a. DeltaStreamer:稳定;数据延迟高,资源消耗大;
  • b. Flink on Hudi:资源消耗较低;大表同步效果不好,数据延迟较低。
  1. 增强部分 Pulsar IO 的应用

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

© StreamNative, Inc. 2022Apache, Apache Pulsar, Apache BookKeeper, Apache Flink, and associated open source project names are trademarks of the Apache Software Foundation.TermsPrivacy