版本：5.0.0-beta
内容
本文先整体介绍 Apache ShardingSphere 的概览，再逐级讲解三大接入端、概念与功能
Apache ShardingSphere 概览
生态圈
- Apache ShardingSphere 是一套由 JDBC、Proxy 和 Sidecar 组成的开源的分布式数据库解决方案组成的生态圈
- JDBC、Proxy 和 Sidecar 能独立部署，也支持混合部署
- JDBC、Proxy 和 Sidecar 均提供标准化的数据水平扩展、分布式事务和分布式治理等功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景
宗旨
增强而非颠覆关系型数据库
5.x 版本的可插拔架构
- 5.x 版本开始致力于可插拔架构，项目的功能组件能够灵活的以可插拔的方式进行扩展
- 目前，数据分片、读写分离、数据加密、影子库压测等功能，以及对 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 与协议的支持，均通过插件的方式织入项目
纵览
接入端
ShardingSphere-JDBC
定位
定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架
特性
- 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC
- 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等
- 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库
架构
ShardingSphere-Proxy
定位
定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端(如：MySQL Command Client, MySQL Workbench, Navicat 等)操作数据，对 DBA 更加友好
特性
- 向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用
- 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端
架构
ShardingSphere-Sidecar
定位
定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问。 通过无中心、零侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格
特性
- 更加关注的是杂乱无章的应用与数据库之间进行有效的交互
- 数据库的应用和数据库将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象
架构
三者指标对比
| ShardingSphere-JDBC | ShardingSphere-Proxy | ShardingSphere-Sidecar | |
|---|---|---|---|
| 数据库 | 任意 | MySQL/PostgreSQL | MySQL/PostgreSQL |
| 连接消耗数 | 高 | 低 | 高 |
| 异构语言 | 仅 Java | 任意 | 任意 |
| 性能 | 损耗低 | 损耗略高 | 损耗低 |
| 无中心化 | 是 | 否 | 是 |
| 静态入口 | 无 | 有 | 无 |
功能
数据分片
- 分库 & 分表
- 读写分离
- 分片策略定制化
- 无中心化分布式主键
分布式事务
- 标准化事务接口
- XA 强一致事务
- 柔性事务
数据库治理
- 分布式治理
- 弹性伸缩
- 可视化链路追踪
- 数据加密
概念
数据分片
数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果
分片手段
分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈
分库
- 有效的分散对数据库单点的访问量
分表
- 无法缓解数据库压力，却能够提供尽量将分布式事务转化为本地事务（跨库的分布式事务复杂）
分片方式
垂直分片
- 按照业务拆分的方式拆分，核心理念是专库专用
- 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库
- 优势：缓解数据量和访问量带来的问题，但无法根治
- 缺陷：
- 垂直分片往往需要对架构和设计进行调整
- 无法真正的解决单点瓶颈
水平分片
- 通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分
- 优势：突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案
分布式事务
数据库在分布式场景下满足 ACID（如下所示） 的特性
- 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行
- 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态
- 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行
- 持久性（Durability）指已提交的事务修改数据会被持久保存
本地事务
- 每个数据节点独自管理自己的事务
- 性能方面无任何损耗，无法做到强一致性以及最终一致性
两阶段提交
- XA 协议（
X/Open国际联盟提出的X/Open Distributed Transaction Processing (DTP)模型） - 优势：
- 对业务侵入很小
- 对使用方透明
- 严格保障事务
ACID特性
- 缺陷：
- 事务执行在过程中需要将所需资源全部锁定，更适用于执行时间确定的短事务
- 长事务下，整个事务进行期间对数据的独占，将导致对热点数据依赖的业务系统并发性能衰退明显
- 不适合高并发的性能至上场景
柔性事务
BASE 是基本可用、柔性状态和最终一致性这三个要素的缩写：
- 基本可用（Basically Available）保证分布式事务参与方不一定同时在线
- 柔性状态（Soft state）允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉
- 最终一致性（Eventually consistent）是通过消息传递的方式保证系统的最终一致性
三者指标对比
| 本地事务 | 两（三）阶段事务 | 柔性事务 | |
|---|---|---|---|
| 业务改造 | 无 | 无 | 实现相关接口 |
| 一致性 | 不支持 | 支持 | 最终一致 |
| 隔离性 | 不支持 | 支持 | 业务方保证 |
| 并发性能 | 无影响 | 严重衰退 | 略微衰退 |
| 适合场景 | 业务方处理不一致 | 短事务 & 低并发 | 长事务 & 高并发 |
读写分离
将数据库拆分为主库和从库，主库负责处理事务性的增删改操作，从库负责处理查询操作
挑战
- 多个主库、主库与从库之间的数据一致性的问题
- 应用开发和运维人员对数据库的操作和运维变得更加复杂
分布式治理
高效、自动化管理集群节点，实现不同节点的协同工作，实现配置一致性、状态一致性、高可用性和可观测性
挑战
- 集成管理复杂：
- 对所有的节点（底层数据库节点、中间件、业务系统节点的状态）统一管理并实时探测最新变化
- 使用集群拓扑状态图来管理集群状态，同时使用心跳检测机制实现状态检测与更新
- 对不同节点节点之间的统一协调，策略与规则的同步做到全局事件通知机制和独占性操作的分布式协调锁机制
- 统一各种不同的组件的标准调用API，对接到治理功能模块
- 实现UI查询、操作和控制系统的功能，支持 tracing 和 APM
弹性扩容
对现有的分片集群进行弹性扩容或缩容
挑战
- 分片策略和算法自由化
- 弹性伸缩，业务无感知
- 弹性伸缩保证数据的可用性和正确性
数据加密
对某些敏感信息通过加密规则进行数据的变形，实现敏感隐私数据的可靠保护
挑战
业务变化下的透明化、安全低风险地实现无缝进行加密改造
影子库压测
以全链路压测的方式在生产环境进行压测
挑战
- 在数据库层面做好数据隔离保证生产数据的可靠性与完整性
- 业务应用在执行 SQL 前，能够根据透传的压测标识，做好数据分类，将相应的 SQL 路由到与之对应的数据源
Dist SQL
Apache ShardingSphere 特有的内置 SQL 语言，提供了标准 SQL 之外的增量功能操作能力
可插拔架构
可插拔架构将各个模块相互独立，互不感知，并通过一个可插拔内核，以叠加的方式将各种功能组合使用
测试引擎
- 提供完善的测试引擎，以 XML 方式定义 SQL，每个引擎分别为 MySQL、PostgreSQL、SQLServer 和 Oracle 数据库运行测试用例
- 无需修改任何 Java 代码，只需修改相应的配置文件即可运行断言
