专车数据层架构进化往事：从无到有的道路

好的架构是进化来的，不是设计来的

早在十年前，我在子柳老师的《淘宝技术这十年》中就读到了一句话，至今仍铭记在心：“好的架构是进化来的，不是设计来的。”2015年，我加入神州专车订单研发团队，亲历了专车数据层架构的演进之路。

这一路走来，我们不断探索、不断创新，从无到有，从小到大，逐步构建起了一套稳定可靠、高性能、可扩展的数据层架构。下面，就让我来分享一下这段进化往事。

1. 雏形初现

2015年，专车业务刚刚起步，订单数据量相对较小，我们采用了最简单的单库单表架构。随着业务的快速发展，数据量激增，单库单表架构的弊端逐渐显现：

• 性能瓶颈：单表数据量过大，导致查询和更新操作性能下降。
• 数据一致性问题：随着数据量的增加，并发操作带来的数据一致性问题也日益突出。
• 可扩展性差：单库单表架构难以满足业务快速增长的需求，扩展起来非常困难。

2. 分库分表探索

为了解决上述问题，我们开始探索分库分表技术。经过调研和评估，我们选择了MySQL的垂直分库分表方案。

垂直分库分表是指按照业务维度将数据拆分到不同的数据库中，每个数据库只存储特定业务领域的数据。这样做的好处是：

• 降低数据库压力：将数据分散到多个数据库中，可以有效降低单个数据库的压力，提高整体性能。
• 提高数据一致性：不同的数据库只存储特定业务领域的数据，减少了跨业务领域的数据交互，从而提高了数据一致性。
• 增强可扩展性：分库分表架构可以方便地通过增加或减少数据库实例来实现横向扩展，满足业务快速增长的需求。

3. 数据模型优化

随着业务的不断发展，我们发现原有的数据模型存在一些不足之处：

• 数据冗余：一些数据在多个表中重复存储，造成了数据冗余和维护成本高的问题。
• 查询效率低下：数据分散在多个表中，导致复杂查询需要进行多次表连接，效率低下。
• 可扩展性差：数据模型缺乏扩展性，难以适应业务变化和新需求。

为了解决这些问题，我们对数据模型进行了优化，采用了实体属性值（Entity-Attribute-Value，EAV）模型。EAV模型将数据组织成三张表：

• 实体表：存储实体的唯一标识和类型。
• 属性表：存储实体的属性名。
• 值表：存储实体属性的值。

EAV模型具有以下优点：

• 消除数据冗余：通过将数据拆分成实体、属性和值三个维度，消除了数据冗余问题。
• 提高查询效率：通过将属性和值存储在单独的表中，可以快速查询特定属性的值，提高查询效率。
• 增强可扩展性：EAV模型具有很强的扩展性，可以轻松添加新的实体和属性，满足业务变化和新需求。

4. 技术栈升级

随着数据量的持续增长，MySQL垂直分库分表的方案也逐渐遇到了瓶颈。为了进一步提升数据层架构的性能和可扩展性，我们决定将MySQL替换为分布式数据库TiDB。

TiDB是一款分布式NewSQL数据库，具有以下优势：

• 高性能：TiDB采用分布式架构，可以将数据分散存储在多个节点上，并通过负载均衡技术提高整体性能。
• 强一致性：TiDB提供了强一致性保证，确保数据在所有副本上保持一致，避免了数据不一致问题。
• 高可用性：TiDB采用多副本机制，保证了数据的高可用性，即使部分节点故障，也不会影响数据的访问和使用。
• 可扩展性强：TiDB支持在线弹性扩容，可以方便地通过增加或减少节点来满足业务增长的需求。

5. 未来展望

随着专车业务的不断发展，我们对数据层架构提出了更高的要求。未来，我们将重点关注以下几个方面：

• 数据实时化：探索流计算技术，实现数据的实时处理和分析，为业务提供更及时的洞察。
• 数据治理：建立完善的数据治理体系，规范数据管理，确保数据的准确性和一致性。
• 数据安全：加强数据安全防护，采用加密、脱敏等技术，保障数据的安全性和隐私性。

总结

专车数据层架构的进化之路是一段不断探索、不断创新的旅程。从无到有，从小到大，我们逐步构建起了一套稳定可靠、高性能、可扩展的数据层架构。

这一路走来，我们遇到了挑战，也取得了成果。我们坚信，好的架构是进化来的，而不是设计来的。只有不断实践、不断总结，才能打造出真正符合业务需求、助力业务发展的优秀架构。