路线一：分布式数据路由组件+单机数据库，如ShardingSphere-Proxy+MySQL
路线二：共享存储架构（存算分离），如阿里云PolarDB、AWS Aurora
路线三：原生分布式数据库，如OceanBase
路线一：分布式数据路由组件+单机数据库
该路线本质上是分布式系统，主要由数据路由组件+单机数据库两大部分组成：
1）分布式数据路由组件
负责维护一套统一的数据分片路由规则，提供SQL解析、SQL路由、请求转发和结果合并的能力。支持数据分库分表、读写分离、分布式事务及弹性伸缩，通过规则配置实现透明化SQL路由。
数据路由组件都是无状态的，可按需水平扩展，可分为如下两类：
○ 客户端方式: 一般是作为增强版JDBC驱动集成至应用层，可随应用水平扩展。兼容所有基于JDBC的ORM框架（MyBatis/JPA）。如ShardingSphere-JDBC即为此种方式。
○ 代理端方式:即作为独立部署的DB代理服务，可按需水平扩展。业务应用统一通过该代理服务来访问DB。如MyCat、ShardingSphere-Proxy均为此种方式。
2）单机数据库
即多个单机数据库组成的DB集群，按需进行分库分表。一般以开源MySQL单机数据库居多，提供数据存储和执行能力。
业务请求经上层数据路由组件数据分片后，会分散到多个单机数据库。当单机数据库存在性能瓶颈时，可对单机数据库进行水平扩展，部署新的单机数据库，降低性能压力。
若有国产化信创要求，则可将MySQL内核升级为国产化内核以满足信创要求，如：
○ TXSQL（腾讯基于MySQL官方版本深度定制的企业级分支内核）
○ AliSQL（阿里云自研MySQL分支）
可看到，路线一无论是上层无状态的数据路由组件，还是底层有状态的单机数据库，均具备良好的水平扩展能力，因此这一路线可通过硬件堆叠，可近似线性地提升计算性能和存储容量，具有可支持超大规模集群的能力，适用于高并发、数据规模巨大、对延迟要求很高的在线交易场景。
路线一由于可基于开源的分布式数据路由组件和成熟稳定的单机数据库实现，改造成本低，且扩展灵活，自主可控性强，不依赖于任何厂商。该方式在很多互联网公司被普遍使用，在部分自研能力较强的金融机构中也有一定使用。
路线一是众多互联网公司应对高并发+大规模数据量+事务型场景的主流选择，已经过了众多互联网公司的多年大规模生产实践验证。
该路线对研发团队的能力有一定要求，尤其是在容灾、弹性能力、一体化运维、数据一致性、副本控制、分布式事务等方面若有较高需求，则需要进行大量优化增强。
路线二：分布式共享存储架构
该路线采用计算与存储分离设计，多个计算节点共享同一存储池（如共享磁盘或块存储），即上层是多组无状态的计算结点，底层是共享分布式云存储，共享存储提供跨节点读写。数据一致性主要依赖分布式存储引擎。
该路线充分利用分布式存储提供的高级特性，大部分公有云数据库（如Aws Aurora、阿里云PolarDB) 采用这条技术路线。但该路线需要对云底座有比较重的依赖。
路线三：原生分布式数据库
该路线是基于分布式数据库理论实现的分布式数据库，最上层一般是无状态的db proxy 集群，再往下则实现数据库基础的优化器、执行器、事务管理、存储引擎等组件，对分布式事务、全局MVCC等支持更为彻底。底层多采用自研或裸存储引擎，数据由DB自动打散并存储多个副本，通过paxos/raft等分布式一致性协议保证多个副本间数据一致。
该路线典型代表有Google Spanner,OceanBase等。
该路线在分布式事务、副本控制、数据一致性、容灾、弹性能力、一体化运维等方面更具有优势（原生实现,属于本身自带的特性），不需要像路线一那样需进行额外的大量的针对性增强。
