为什么科拓停车选择OceanBase来构建智慧停车SaaS应用

本文来自OceanBase的客户——拓客停车的实践分享

科拓停车简介与业务背景

作为智慧停车行业的佼佼者，科拓停车致力于提供全方位的智慧停车解决方案。服务涵盖车场运营管理、互联网智慧停车平台以及停车场增值服务等。通过不断研发创新，打造出了多样化的硬件设备和软件系统，助力客户实现对车场的高效经营与管理。尤其对于拥有众多车场的集团客户而言，其经营管理平台能够从更高层面出发，帮助客户实现车场的统一管理。

今年，我们对集团级经营管理平台进行了重大升级，旨在帮助客户对车场进行深度经营。在业务升级过程中，我们对整个平台的技术架构进行了重构和升级，并引入了OceanBase技术栈。这一引入为集团客户提供了先进的数据管理和处理能力，稳定可靠的数据库解决方案。利用OceanBase的多租户特性，我们成功推动了平台的SAAS化演进，并实现了集团间数据的相互隔离。此外，OceanBase的分布式架构也为未来的系统扩展和业务发展提供了有力支持。

业务痛点

我们旧版的经营管理平台的技术架构核心是基于MySQL和Elasticsearch作为数据存储。平台所需的业务数据大部分是车场的日常运营数据，通过车场的接口上报到平台。整体架构如下图所示：

1700533996

随着经营时间的增加，以及今年业务流量回升甚至超过往年的情况，现有系统架构在性能和扩展性已无法满足业务的发展需求。从上图的数据流向可以清楚地看到所有集团和车场的数据最终都汇聚到Elasticsearch（8核32G、IO吞吐为大概350M/s的SSD盘）中。其中进出车明细索引已经达到近20亿条数据，kt-data应用在处理上报的数据时并发大概是100的TPS，因为需要处理的数据和打宽所需要拼接的数据都会从Elasticsearch查询出来，处理后再写入Elasticsearch，不同数据的逻辑复杂度也不一样，所以实际落到Elasticsearch上的并发操作远大于100。最终导致整个平台存在以下四个痛点。

痛点1：数据不够准确。

整个集团经营管理平台的核心数据依托于车场的业务数据，旧平台采用的是车场业务系统通过接口上报的方式，会有接口异常，以及车场业务调整导致数据不兼容等情况，从而引起数据质量问题，影响客户使用。

痛点2：Elasticsearch磁盘I/O性能出现瓶颈。

因Elasticsearch并不支持传统的SQL中的JOIN操作，在针对业务设计相应索引的时候，我们都是按照大宽表的方式进行设计的。根据接口上报的实时数据，去Elasticsearch中查询多个索引的数据，然后在内存中组装成大宽表写回Elasticsearch不同的索引中，随着流业务量的增加，整体并发升高，Elasticsearch磁盘I/O等各方面出现性能瓶颈。

痛点3：重度依赖Elasticsearch，OLTP场景支持不够友好。

在旧版平台上，我们主要侧重于数据分析和报表制作，以及基础的管理功能，此时Elasticsearch很好地支持了大多数的OLAP场景需求。然而，业务的深入发展促使OLTP的需求也逐渐增加，继续使用Elasticsearch变得不那么理想。例如，当我们为集团客户提供车牌修正功能时，需要同时记录修改操作的详细过程，在这种情况下由于Elasticsearch缺乏事务支持，对于同时保证修改成功并保存操作记录的要求变得难以满足。

痛点4：无法支撑平台SAAS化。

整个平台SAAS架构的升级，因素主要有以下几方面：

每个集团都是独立的，数据没有交互，部分集团也有数据隔离这样的需求，SAAS化后能减轻部分私有化部署和后期运维的成本。
进行资源隔离后，每个集团的数据体量相对所有集团聚合到一起会更小，系统就能拥有更好的性能和稳定性，以及扩展性。
可以根据集团的规模，选择不同规格的租户，能够更加清晰地计算每个集团使用的资源和费用预估。
私有化场景下，我们可以使用MySQL代替OceanBase，把MySQL当成是OceanBase的一个租户，简化私有化的部署和运营。

而Elasticsearch是无法支持多租户、SAAS化架构的，在Elasticsearch已经出现性能问题再进行节点扩容时，所需要的时间也较长，在扩展性上，也不满足我们随时可能会有新的集团接入的情景。

技术选型

上述痛点已经对客户日常使用和体验造成了一些不好的影响。同时随着业务的全面升级，我们考虑对整体的架构和数据存储组件重新设计和选型。其中的考虑因素包括以下4点。

兼容SQL语法：能够支持常规的join、sum等查询。
方便的多租户能力：为了满足客户资源隔离的需求和平台SAAS化的改造。
具备一定的OLTP能力：虽然有统计分析类的新增业务需求，但是分租户后一个集团的数据不再像以前所有数据汇聚到一个索引，每个租户下的数据量相对就小一些。
扩容要简单：客户是逐渐接入的，初期我们不会建设过大的服务集群（资源），希望能够随客户的不断接入，逐步去增加数据库的资源。

最终我们把目光投向了分布式数据库，前期我们对OceanBase、TiDB、openGauss等数据库进行了简单的预研，最终选择OceanBase的主要原因有三点。

其一，OceanBase和TiDB都支持多租户和兼容MySQL，而OceanBase的SQL兼容性更高。

其二，OceanBase架构简单，核心组件就OBServer；openGauss开源版本其实是一个单机数据库（通过其它组件实现分布式部署）；TiDB的组件更多，如果出现问题后期维护成本可能更大。

其三，OceanBase的binlog接入相对TiDB简单，提供oblogproxy和canal-for-obd插件，Canal是我们公司采集binlog的主要工具。

功能和性能验证

环境准备

• 服务器配置：总共2台，1台 8核16g 磁盘（data:500G,redo:200g)，1台 4核 8g

• 租户test：4核8G （1zone 1unit）

• OceanBase Version：4.1.0.1(社区版)

• OceanBase Release：102000042023061314.el7

部署结构如下图所示:

1700534074

基础功能验证

首先，我们进行了MySQL基础功能验证。对INSERT、UPDATE、DELETE、CREATE TABLE、DROP TABLE、ALTER、CREATE INDEX等系列操作进行了简单的功能验证，均能正常使用。

其次，Canal-adapter数据写入功能验证。因为我们已经基于Canal做了比较完善的数据同步服务，所以并没有花更多的时间去研究OceanBase提供的相关服务。使用测试环境数据和线上业务数据分别进行了验证，均能支持MySQL历史数据和实时数据同步到OceanBase。唯一的问题是有些异常信息与MySQL的不一致，通过调整adapter的代码进行了适配。

最后做了Canal拉取binlog功能验证。OceanBase社区版并没有binlog，Canal也无法直接接入，最终通过oblogproxy和canal-for-obd配合完成binlog拉取。在这个过程中遇到了两个问题：一是oblogproxy的版本和OceanBase不完全兼容，一定要按照官方要求的版本进行配合使用；二是canal-for-obd是单独部署的单节点，前期和oblogproxy都没有设置监控，不是特定稳定。

性能测试情况

我们只是在测试环境按照官方提供的TPCH性能测试方案进行了简单的测试，测试数据如下：

1700534090

测试结果表示，总共执行了20个sql语句，90%的sql语句执行时间小于1s，整体上能够满足业务需求。

落地实现

系统架构

在整个平台基于OceanBase实现SAAS化的落地过程中，我们要遇到两个问题。

第一个问题是平台的基础业务数据（车场的真实业务数据)，如何按租户实现数据同步链路隔离，最终保障准确的将数据落到各自的租户。

数据同步方面，我们在Canal这个体系上有丰富的经验，我们通过Canal把原始的业务数据汇聚到一个又一个的topic里面，当集团需要数据的时候我们又从topic中将其分离出来写入不同的租户中。这一步我们是通过自研的一个数据过滤/分发程序，结合MQ和Canal同步组件实现整个数据同步链路的建设。从这一步就保障了租户的数据隔离，数据同步链路上各租户间互不影响。

第二个问题是我们的应用程序如何与OceanBase交互实现租户间的切换访问。我们最开始以为OBProxy提供类似的功能，了解后发现好像并不支持，最后通过对几个中间件的了解，最终发现mycat2很契合这种场景，操作也非常简单。我们只需要按照租户在mycat2中创建对应的数据源，然后使用mycat2的透传功能，就能实现租户间的切换，mycat2的注解功能也减轻了我们上层应用SAAS实现AOP（切面)的逻辑。

      /*+ MYCAT:TARGET(c0) */
 select * from db1.travelrecord;
整体架构如下图所示：

整体架构如下图所示：

1700534110

租户和资源规划

从我们公司整体业务来看，关键在于车场，车辆进出场和缴费是绝对核心，对管理平台的可用性要求较低，对不可避免的故障或短暂中断有一定的容忍度。虽然OceanBase的故障恢复很快，比如重启方便，重启恢复的时间比较短，但我们也需要考虑极端情况，平台核心数据来自于车场的业务数据，如果OceanBase出现数据损坏，或者数据丢失的情况，我们能够重新全量同步对应车场的业务数据到OceanBase，因此，我们在使用OceanBase集群时，一直是单zone的模式，每个租户也是单Unit，这种模式是不具备高可用的，

当然，如果对系统的可用性有很高的要求，在资源允许的情况下，还是建议按照多zone，每个zone下多OBServer，甚至建设多Region的集群。

对于每个租户资源划分的问题，我们有两种方案：一个集团一个租户，根据集团的规模来规划租户资源的大小；一个租户多个集群，规模很小同时没有明确数据隔离需求的就规划到一个租户中。通过这两种方案实现资源的合理规划和充分利用。

集群扩容

我们创建的初始集群资源使用是比较少的：3台OBServer(4核16G)，随着业务的发展，我们首先升级了服务器的硬件资源，直到每个OBServer升级到16核64G，再横向扩展OBServer节点以扩展整个集群的资源（添加节点可参考文档）。

其中需要注意的是

oceanbase-ce的版本要选择相同的，同时因服务器的版本不同也有所区别。
启动时memory_limit、log_disk_size、cpu_count等参数需要更具实际情况规划好。

总结

尽管我们仍处于对OceanBase的初步使用阶段，但已经显现出令人满意的效果。OceanBase在整个平台的业务升级和技术重构方面扮演着关键角色。其优秀的SQL兼容性和高性能使我们能够回避各种大宽表和统计汇总表的场景。通过常规的关联查询和聚合函数，能够满足绝大部分业务需求，使整体业务实现更加简单、清晰。

同时，多租户提供的强大资源隔离和管理能力是我们成功实施整个平台的SAAS化建设的关键。即使在初期阶段，我们已经感受到了多租户特性为我们的业务带来的巨大价值。