从缘起看未来：分布式数据库中间件 ShardingSphere | 图书推荐

分布式数据库中间件生态圈 ShardingSphere 是由分布式数据库中间件解决方案 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar 组成的，它们均提供了标准化的数据分片、分布式事务和数据库治理功能，适用于 Java 同构、异构语言、容器、云原生等各式各样的应用场景。

ShardingSphere 的初衷是，充分合理地在分布式的场景下利用关系型数据库的计算能力和存储能力，而非实现一个全新的数据库。ShardingSphere 遵循的理念是，通过观察不常发生改变的事物来获取其本质。如今，关系型数据库依然占有巨大的市场份额，是各个公司的核心业务基石，未来也难于被撼动。ShardingSphere 在目前阶段的关注点是在原有基础上扩展功能，而非完全颠覆传统数据库的功能。

ShardingSphere 已于 2018 年 11 月 10 日正式进入 Apache 软件基金会孵化器，并正式被命名为 Apache ShardingSphere。

1 缘起

ShardingSphere 从开源至今，悄然地完成了从默默无闻到进入 Apache 软件基金会成为知名项目的进阶。目前，已经有 70 多家公司声明，在生产环境中使用了 Apache ShardingSphere。那么，它究竟起源于何处，又经历了怎样的发展历程呢？下面我们就一起回顾一下 ShardingSphere 这两年来所走过的路。

内部应用框架

ShardingSphere 的前身是 Sharding-JDBC，它最初是当当网架构部开发的内部应用框架 dd-frame 的其中一个模块，名为 dd-rdb。这个模块专门用于数据库访问以及简单的分库和分表。当当网的应用框架缘起于 2014 年，定位是针对整个电商平台提供的统一开发框架，它的主要目标如下。

• 分离技术与业务代码，封装技术细节，让应用开发人员将精力集中在业务开发上。

• 统一开发框架，使公司中所有项目的架构相似，降低跨组沟通及人员转组的成本。

• 提供工具箱，标准化技术组件。

• 组件可插拔，不强制业务开发人员使用框架的全部内容。

• 灵活地提供定制化功能，框架本身对引入其他第三方技术组件不做限制。

• 推动服务化。

• 提供统一的监控和日志标准。

• 模板代码自动化生成，降低书写难度。

• 为私有云和自动化运维做准备，将系统划分为业务、框架、云平台、治理几个层次。

dd-frame 的模块组成如图 1 所示。

图 1 dd-frame 的模块组成

dd-frame 的核心模块 dd-container 的使用方式与 Spring Boot 类似，只是在 2014 年时，Spring Boot 还未十分流行，因此才出现了“重复造轮子”的情况。

最初，开发 dd-rdb 只是为了使当当网内部的 MyBatis 的使用、数据库访问代码的生成以及基于 Spring 的多数据源路由等功能更加标准化。然而，随着对数据分片需求的不断增加，单纯的动态多数据源路由已经无法满足应用开发方的需求了，因此当当网决定在 dd-frame 的 dd-rdb 模块中实现一套完善的数据分片框架。

由于数据分片功能相对独立，因此当当网于 2016 年年初将此模块从 dd-rdb 中剥离，向社区开源，并将其命名为 Sharding-JDBC，表明它是一个在 Java 的 JDBC 层实现分库和分表的数据库中间层框架。

开源之后，社区讨论最多的经典话题之一是，Sharding-JDBC 为何选择在 JDBC 层实现数据分片，而不开启一个独立的代理层进行数据分片。其实原因很简单，因为 Sharding-JDBC 是由基于 Java 开发的应用框架 dd-frame 演化而来的，它本身就是 Java 框架，而非独立部署的中间件。

值得一提的是，除了 Sharding-JDBC，dd-frame 中还开源了另外的两个项目——DubboX 与 Elastic-Job。

DubboX 是服务化模块 dd-soa 的核心组件，是在阿里巴巴开源的 Dubbo 的基础上进行的扩展及二次开源，目前 DubboX 已捐献回 Dubbo，Dubbo 已进入 Apache 孵化阶段。

Elastic-Job 是作业模块 dd-job 的核心组件，是一个分布式的作业调度框架，分为可以通过 jar 提供轻量级服务的 Elastic-Job-Lite，以及可以通过 Mesos 提供一站式资源调度与弹性作业的 Elastic-Job-Cloud。

开源历程

ShardingSphere 的前身 Sharding-JDBC，是 dd-frame 2.x 版本中的重点规划模块，于 2015 年 9 月进入开发阶段，历经 3 个月的紧张开发与测试，于 2015 年 12 月正式完成，其 1.0.0 版本在当当网内部正式发布。

由于采用 dd-frame 作为 Java 应用脚手架的项目非常多（当时当当网 70%以上的 Java 项目中都用到 dd-frame），因此凭借着对 dd-frame 1.x 的完全兼容，Sharding-JDBC 迅速在公司内部推广开来。由于之前开源的 DubboX 和 Elastic-Job 都收获了良好的口碑，因此 Sharding-JDBC 自然而然地走上了开源之路。

不少国内的优秀开源产品都是先在公司内部经受时间的充分验证，然后再剥离业务逻辑和内部环境依赖，最终开源贡献给社区的。这样做的好处是产品相对成熟，但也有一些缺憾，具体如下。

• 后续支持匮乏。产品已经足够应对公司的业务场景需求，缺乏后续提升的动力。文档和技术支持也相对较少，甚至会出现文档和代码不同步的状况。

• 与公司业务场景耦合较为严重。大部分产品都是为了解决特定领域的问题而产生的，比如有的公司可能并不需要分表，有的公司只需支持几种预定制的分片策略。

• 开源不完整。和公司业务耦合紧密的部分无法开源。

• 缺乏黏性。成型的项目功能繁多、代码结构复杂，社区志愿者难于扩展或修改其核心逻辑。如果测试覆盖率不够，便难以保证修改后的代码质量。以上一系列问题会导致项目与社区间的黏性不高，难于找寻可合作开发的志愿者。

• 分支众多，难于维护。由于开源之后公司缺乏持续提升的动力，和本公司关系不大的功能需求得不到重视，因此各公司都开发自己的分支。开源项目虽然在最初给社区注入了新鲜思想，但最终并没有吸取社区的精华。

为了弥补这些缺憾，当当网采用了全新的开源策略，在 Sharding-JDBC 完成初版的时候即向社区和公司内部同时推广，这样做的好处如下。

• 后续支持完善。Sharding-JDBC 与当当网内部落地绑定，可以同时获得来自公司内部和社区的支持。虽然无法承诺社区的优先级高于公司内部的优先级，但开发团队会综合考虑社区与公司内部的需求，以更广阔的视角尽量整合与优化升级路线。

• 完整开源。代码的 snapshot 版本将会首先出现在 GitHub 上。

• 共同发展。Sharding-JDBC 的初版代码相对简单，社区的开源爱好者可以非常轻松地理解其核心，为可持续发展奠定良好基础，并且 Sharding-JDBC 也会吸纳社区精华，让更多地爱好者参与代码贡献。

坚定了与社区共谋发展的开源路线之后，Sharding-JDBC 又经过了两个月的解耦和精炼，于 2016 年 2 月在 GitHub 上发布了首个版本。从首次开源至今，Sharding-JDBC 经历了许多“关键时刻”。

• 2016 年 2 月，1.0.0 版本发布，主要功能是分库和分表，实现了 JDBC 接口，并且完整实现了 SQL 解析、SQL 改写、请求路由、结果归并的标准处理流程。

• 2016 年 3 月，1.1.0 版本发布，大幅提升了 Sharding-JDBC 配置的友好度，增加了 YAML、Spring 命名空间和行表达式的配置方式。

• 2016 年 5 月，1.2.0 版本发布，实现了最大努力送达型柔性事务，完成了对分布式事务的初步支持。

• 2016 年 6 月，1.3.0 版本发布，支持读写分离。

• 2016 年 11 月，1.4.0 版本发布，支持无中心化分布式自增主键。至此，数据分片功能已基本实现。

• 2017 年 7 月，1.5.0 版本发布，使用全新的自研 SQL 解析引擎替代了原有的 Druid 解析引擎，SQL 兼容性大幅提升。

• 017 年 12 月，2.0.0 版本发布，正式将 com.dangdang 的 Maven 坐标与包名改为 io.shardingjdbc，当当网将 Sharding-JDBC 正式交给社区运作和托管。2.x 版本主打数据库治理功能，同时与 Apache SkyWalking 达成合作，提供 SkyWalking 的自动探针，并加入 OpenTracing 组织。

• 2018 年 3 月，3.0.0.M1 版本发布。由于京东金融等公司加入开发，Sharding-JDBC 经过社区投票，正式更名为 ShardingSphere，将原 Sharding-JDBC 并入 ShardingSphere 生态圈，并且新开发了 Sharding-Proxy，以透明化数据库中间层的新形态提供多样化服务。同时，PMC（项目管理委员会）成立，向实现社区化迈出了重要的一步。

• 2018 年 6 月，ShardingSphere 与 Apache ServiceComb 达成合作共识，将采用 Apache ServiceComb-saga 作为 ShardingSphere 柔性事务的决策执行引擎。

• 2018 年 10 月末，ShardingSphere 的 3.0.0 稳定版本发布。

• 2018 年“双 11”的前一天，ShardingSphere 通过 Apache 软件基金会的投票，正式成为 Apache 孵化项目，软件更名为 Apache ShardingSphere。

2 核心功能

在经过了三个主版本的发布之后，它的稳定性已经过充分的验证，功能也愈加多样化。接下来我们将详细介绍 ShardingSphere 的三个主要核心功能模块——数据分片、分布式事务和数据库治理。

数据分片

数据分片是提升互联网应用性能的有效手段，但它也是一把双刃剑，在性能提升的同时，各种复杂度也随之而来。正因有数据分片，才会衍生出分布式事务和数据库治理等需求，它是所有数据类分布式场景的起源。ShardingSphere 的名字也起源于 Sharding（分片），这是 ShardingSphere 中最核心的部分。

ShardingSphere 同时提供分库与分表的能力，可以将分库与分表功能灵活混用，以解决各类场景下的不同问题。

ShardingSphere 对垂直分片、水平分片以及读写分离等几种场景的支持都很友好。合理混用分库、分表与读写分离可以最大限度地提升系统的性能。

无论数据分片的逻辑如何复杂，其真实的物理数据库散落在何方，ShardingSphere 始终秉承着向用户展现一个逻辑数据库与面向业务逻辑的若干逻辑数据表的理念。使用方工程师无须考虑数据分片的细节，只需面向自己的业务逻辑表编写 SQL 即可。

在 ShardingSphere 目前提供的两个产品中，对于数据分片的处理流程是完全一致的。流程包括 SQL 解析、SQL 路由、SQL 改写、SQL 执行、结果归并，如图 2 所示。

图 10-2 数据分片流程

分布式事务

ShardingSphere 同时支持本地事务、强一致性的 XA 事务和最终一致性的柔性事务，它允许每次访问数据库时自由选择事务类型。

分布式事务对业务操作完全透明，极大地降低了接入成本。分布式事务整合了现有的成熟事务方案，为本地事务、XA 事务和柔性事务提供了统一的分布式事务接口，弥补了当前方案的不足。因此，提供一站式的分布式事务解决方案是 ShardingSphere 分布式事务模块的主要设计目标。图 3 是 ShardingSphere 的分布式事务架构图。

图 3 ShardingSphere 的分布式事务架构图

数据库治理

ShardingSphere 提供了注册中心和应用性能监控这两个功能，其中数据库治理方面仍有大量未完成的功能，未来将会陆续开源。

注册中心用于实现配置集中化和配置动态化。借助注册中心，ShardingSphere 提供了熔断和禁用的能力，熔断是指控制和截流数据库访问程序对数据库的访问，禁用是指停止对读写分离中的某一从库进行访问。注册中心目前支持使用 ZooKeeper 和 etcd。

ShardingSphere 并不负责采集、存储和展示与应用性能监控相关的数据，而是将 SQL 解析与 SQL 执行这两部分数据分片的核心信息发送至应用性能监控系统，并交由其处理。换句话说，ShardingSphere 仅负责产生具有价值的数据，并通过标准协议将数据递交至相关系统。ShardingSphere 可以通过两种方式对接应用性能监控系统。

3 未来规划

ShardingSphere 目前仍在快速发展中，图 4 描述了 ShardingSphere 的详尽演进路线。

图 4 ShardingSphere 的详尽演进路线

ShardingSphere 1.X 版本的主要定位为面向 JDBC 驱动的数据分片框架，已经于 2016 年发布，经过了近三年的打磨，其功能已趋于完善。

ShardingSphere 的 2.X 版本是对治理的探索，集成了注册中心和 OpenTracing，于 2017 年发布，在微服务以及自治理方面进行了很大改进。

截止到本书写作之时，ShardingSphere 的 3.0.0 正式版已经发布，其中的主要功能组件是 Sharding-Proxy。Sharding-Proxy 经过了近十个月的开发，已经被京东内部的一级系统逐渐采用。相对于 JDBC 驱动，增加了 Proxy 的 ShardingSphere 生态更加趋于完善。

ShardingSphere 的 3.1.0 版本与 3.0.0 版本是同步开发的，主要是面向分布式事务的。在 3.0.0 版本发布后不久，3.1.0 版本就发布了。

ShardingSphere 的 4.X 版本仍处于规划中，预计将增加 Database Mesh 的基础组件 Sharding-Sidecar，并且完善多数据副本及弹性伸缩功能，为云原生和自动化数据库完成最后的闭环。

作者简介

张亮，京东数科数据研发负责人，Apache ShardingSphere 发起人 & PPMC

热爱开源，目前主导开源项目 ShardingSphere(原名 Sharding-JDBC)和 Elastic-Job。擅长以 Java 为主分布式架构以及以 Kubernetes 和 Mesos 为主的云平台方向，推崇优雅代码，对如何写出具有展现力的代码有较多研究。

目前主要精力投入在将 ShardingSphere 打造为业界一流的金融级数据解决方案之上。ShardingSphere 已经进入 Apache 孵化器，是京东集团首个进入 Apache 基金会的开源项目，也是 Apache 基金会首个分布式数据库中间件。

Apache ShardingSphere(Incubator) 项目地址：https://shardingsphere.apache.org

本文节选自新书《未来架构：从服务化到云原生》

互联网架构不断演化，经历了从集中式架构到分布式架构，再到云原生架构的过程。云原生因能解决传统应用升级缓慢、架构臃肿、无法快速迭代等问题而成了未来云端应用的目标。本书首先介绍架构演化过程及云原生的概念，让读者对基础概念有一个准确的了解，接着阐述分布式、服务化、可观察性、容器调度、Service Mesh、云数据库等技术体系及原理，并介绍相关的 SkyWalking、Dubbo、Spring Cloud、Kubernetes、Istio 等开源解决方案，最后深度揭秘开源分布式数据库生态圈 ShardingSphere 的设计、实现，以及进入 Apache 基金会的历程，非常适合架构师、云计算从业人员阅读、学习。

要想了解更多关于 Service Mesh 和未来机构趋势的精彩内容，请点击这里购买图书。