专车数据层「架构进化」往事

发布时间：2025-11-05 11:06:20 来源：码上建站 作者：IT科技

很多年前，专车读了子柳老师的数据事《淘宝技术这十年》。这本书成为了我的层架架构启蒙书，书中的构进一句话像种子一样深埋在我的脑海里：“好的架构是进化来的，不是化往设计来的”。

2015年，专车我加入神州专车订单研发团队，数据事亲历了专车数据层「架构进化」的层架过程。这次工作经历对我而言非常有启发性，构进也让我经常感慨：“好的化往架构果然是一点点进化来的”。

1 单数据库架构

产品初期，专车技术团队的数据事核心目标是：“快速实现产品需求，尽早对外提供服务”。层架

彼时的构进专车服务都连同一个 SQLServer 数据库，服务层已经按照业务领域做了一定程度的化往拆分。

这种架构非常简单，团队可以分开协作，源码下载效率也极高。随着专车订单量的不断增长，早晚高峰期，用户需要打车的时候，点击下单后经常无响应。

系统层面来看：

2  SQL优化和读写分离

为了缓解主数据库的压力，很容易就想到的策略：SQL优化。通过性能监控平台和 DBA 同学协作分析出业务慢 SQL ，整理出优化方案：

另外一个策略是：读写分离。

读写分离的基本原理是让主数据库处理事务性增、源码库改、删操作（ INSERT、UPDATE、DELETE），而从数据库处理 SELECT 查询操作。

专车架构团队提供的框架中，支持读写分离，于是数据层架构进化为如下图：

读写分离可以减少主库写压力，同时读从库可水平扩展。当然，读写分离依然有局限性：

3  业务领域分库

虽然应用层面做了优化，数据层也做了读写分离，但主库的压力依然很大。接下来，大家不约而同的想到了业务领域分库，也就是：将数据库按业务领域拆分成不同的业务数据库，每个系统仅访问对应业务的云南idc服务商数据库。

业务领域分库可以缓解核心订单库的性能压力，同时也减少系统间的相互影响，提升了系统整体稳定性。

随之而来的问题是：原来单一数据库时，简单的使用 JOIN 就可以满足需求，但拆分后的业务数据库在不同的实例上，就不能跨库使用 JOIN了，因此需要对系统边界重新梳理，业务系统也需要重构。

重构重点包含两个部分：

4 缓存和MQ

专车服务中，订单服务是并发量和请求量最高，也是业务中最核心的服务。虽然通过业务领域分库，SQL 优化提升了不少系统性能，但订单数据库的写压力依然很大，系统的瓶颈依然很明显。

于是，订单服务引入了缓存 和MQ 。

乘客在用户端点击立即叫车，订单服务创建订单，首先保存到数据库后，然后将订单信息同步保存到缓存中。

在订单的载客生命周期里，订单的修改操作先修改缓存，然后发送消息到MetaQ ，订单落盘服务消费消息，并判断订单信息是否正常（比如有无乱序)，若订单数据无误，则存储到数据库中。

核心逻辑有两点：

这次优化提升了订单服务的整体性能，也为后来订单服务库分库分表以及异构打下了坚实的基础。

5 从 SQLServer 到 MySQL

业务依然在爆炸增长，每天几十万订单，订单表数据量很快将过亿，数据库天花板迟早会触及。

订单分库分表已成为技术团队的共识。业界很多分库分表方案都是基于 MySQL 数据库，专车技术管理层决定先将订单库整体先从 SQLServer 迁移到 MySQL 。

迁移之前，准备工作很重要 ：

当准备工作完成后，才开始迁移。

迁移过程分两部分：历史全量数据迁移和增量数据迁移。

历史数据全量迁移主要是 DBA 同学通过工具将订单库同步到独立的 MySQL 数据库。

增量数据迁移：因为 SQLServer 无 binlog 日志概念，不能使用 maxwell 和 canal 等类似解决方案。订单团队重构了订单服务代码，每次订单写操作的时候，会发送一条 MQ 消息到 MetaQ 。为了确保迁移的可靠性，还需要将新库的数据同步到旧库，也就是需要做到双向同步。

迁移流程：

6 自研分库分表组件

业界分库分表一般有 proxy 和 client 两种流派。

代理层分片方案业界有Mycat，cobar等 。

它的优点：应用零改动，和语言无关，可以通过连接共享减少连接数消耗。缺点：因为是代理层，存在额外的时延。

应用层分片方案业界有sharding-jdbc，TDDL等。

它的优点：直连数据库，额外开销小，实现简单，轻量级中间件。缺点：无法减少连接数消耗，有一定的侵入性，多数只支持Java语言。

神州架构团队选择自研分库分表组件，采用了client 模式，组件命名：SDDL。

订单服务需要引入是 SDDL 的 jar 包，在配置中心配置数据源信息 ，sharding key  ，路由规则等，订单服务只需要配置一个datasourceId 即可。

7 分库分表策略

专车订单数据库的查询主维度是：乘客，乘客端按乘客user_id和 订单order_id查询频率最高，我们选择 user_id 做为sharding key ，相同用户的订单数据存储到同一个数据库中。

分库分表组件SDDL和阿里开源的数据库中间件 cobar 路由算法非常类似的。

为了便于思维扩展，先简单介绍下 cobar 的分片算法。

假设现在需要将订单表平均拆分到4个分库 shard0 ，shard1 ，shard2 ，shard3 。首先将 [0-1023] 平均分为4个区段：[0-255]，[256-511]，[512-767]，[768-1023]，然后对字符串（或子串，由用户自定义）做 hash， hash 结果对1024取模，最终得出的结果slot 落入哪个区段，便路由到哪个分库。

cobar 的默认路由算法 ，可以和雪花算法 天然融合在一起， 订单order_id 使用雪花算法，我们可以将slot的值保存在10位工作机器ID 里。

通过订单order_id可以反查出slot, 就可以定位该用户的订单数据存储在哪个分区里。

) {

;

();

专车 SDDL 分片算法和 cobar 差异点在于：

虽然解决了主维度乘客分库分表问题，但专车还有另外一个查询维度，在司机客户端，司机需要查询分配给他的订单信息。

我们已经按照乘客 user_id 作为 sharding key ，若按照司机driver_id查询订单的话，需要广播到每一个分库并聚合返回，基于此，技术团队选择将乘客维度的订单数据异构到以司机维度的数据库里。

司机维度的分库分表策略和乘客维度逻辑是一样的，只不过 sharding key 变成了司机driver_id。

异构神器 canal 解析乘客维度四个分库的 binlog ，通过SDDL写入到司机维度的四个分库里。

这里大家可能有个疑问：虽然可以异构将订单同步到司机维度的分库里，毕竟有些许延迟，如何保证司机在司机端查询到最新的订单数据呢 ？

在缓存和MQ这一小节里提到：缓存集群中存储最近七天订单详情信息，大量订单读请求直接从缓存获取。订单服务会缓存司机和当前订单的映射，这样司机端的大量请求就可以直接缓存中获取，而司机端查询订单列表的频率没有那么高，异构复制延迟在10毫秒到30毫秒之间，在业务上是完全可以接受的。

专车管理后台，运营人员经常需要查询订单信息，查询条件会比较复杂，专车技术团队采用的做法是：订单数据落盘在乘客维度的订单分库之后，通过 canal 把数据同步到Elastic Search。

业务中有一些配置表，存储重要的配置，读多写少。在实际业务查询中，很多业务表会和配置表进行联合数据查询。但在数据库水平拆分后，配置表是无法拆分的。

小表广播的原理是：将小表的所有数据（包括增量更新）自动广播（即复制）到大表的机器上。这样，原来的分布式 JOIN 查询就变成单机本地查询，从而大大提高了效率。

专车场景下，小表广播是非常实用的需求。比如：城市表是非常重要的配置表，数据量非常小，但订单服务，派单服务，用户服务都依赖这张表。

通过 canal 将基础配置数据库城市表同步到订单数据库，派单数据库，用户数据库。

8 平滑迁移

分库分表组件SDDL 研发完成，并在生产环境得到一定程度的验证后，订单服务从单库 MySQL 模式迁移到分库分表模式条件已经成熟。

迁移思路其实和从 SQLServer 到 MySQL非常类似。

整体迁移流程：

9 数据交换平台

专车订单已完成分库分表 , 很多细节都值得复盘：

面对这些问题，架构团队的目标是打造一个平台，满足各种异构数据源之间的实时增量同步和离线全量同步，支撑公司业务的快速发展。

基于这个目标，架构团队自研了dataLink用于增量数据同步，深度定制了阿里开源的dataX用于全量数据同步。

10 写到最后

专车架构进化之路并非一帆风顺，也有波折和起伏，但一步一个脚印，专车的技术储备越来越深厚。

相关文章