共计 8271 个字符，预计需要花费 21 分钟才能阅读完成。
背景
始终以来，大一统还是碎片化，是数据库发展趋势的两种最支流预测。随着数字化过程的推动，繁多场景无奈满足利用多样化的需要，数据库碎片化已呈不可逆的趋势。在以后，市场占有率最高的商用数据库—— Oracle 并没有显著短板的状况下，各种全新的数据库仍旧如雨后春笋般层出不穷。现在，DB-Engines 上已有超过 300 余种数据库参加排名。
利用场景的一直扩张，减速了数据库碎片化的过程，数据库的架构、协定、性能、实用场景也更加多样化。在数据库架构方面，基于单机零碎演进而来的集中式数据库与原生面向分布式的新一代数据库并存；在数据库协定方面，MySQL 和 PosrtgreSQL 这两大次要开源生态以及周边厂商所提供的服务生态也在寰球数据库体系中各自占有一席之地；每种数据库的独特性能和实用场景，也在相干的畛域大放异彩。
在企业的利用现状中，数据库的多元并存已是常态。在互联网行业中，以 MySQL + 数据分片中间件作为外围业务存储的架构模式为主，以 GreenPlum、HBase、Elasticsearch、Clickhouse 等其余大数据生态作为剖析型数据的计算引擎为辅助。与此同时，一些遗留零碎（如：通过 .NET 转型时遗留的 SQLServer、或通过外采而遗留的 Oracle）的数据库仍在运行；在金融行业中，外围交易系统依然大量应用 Oracle 或 DB2，新业务向 MySQL 或 PostgreSQL 迁徙，局部业务则逐步尝试应用自主研发的数据库。除了交易型数据库，剖析型数据库的品种则更加繁多。
因而，碎片化是数据库畛域的大势所趋，繁多品类的数据库无奈实用于所有场景，只能实用于某一种或某几种善于的场景。
数据库碎片化带来的问题
随着企业采纳的数据库品种一直减少，各种问题和痛点也随之呈现。
1. 架构选型艰难
当利用架构为了适应更加灵便多变的业务需要，将架构设计从单体式向服务化再到微服务进行转化之后，用于存储业务外围数据的数据库则成为分布式系统的下一个焦点。
绝对比无状态的利用，具备状态的数据库的设计难度则有过之而无不及。分而治之是分布式系统的最佳实际，显然，数据库体系也不能简略的用繁多产品以及一体化集群来响应所有的服务申请。
首先，繁多品类的数据库无奈满足业务利用的全副需要，在高吞吐量、低延时、分布式无感知、强一致性、运维友好度甚至稳定性等方面难以做到八面玲珑。 一个利用须要多种数据库共存的可能性尚且不高，但多个利用混用多种数据库的可能性则大大晋升。
其次，无论是单机数据库，还是 All in One 的分布式数据库集群，都难以成为泛滥微服务利用后端的惟一存储撑持。 单机数据库无奈承载越来越大的数据量和访问量，所以越来越多的利用抉择采纳分布式解决方案。然而，多利用应用对立的数据库集群，在 CPU、内存、磁盘、网络等方面的负载无奈做到齐全隔离。一个利用的超额资源应用，可能会导致泛滥毫不相干的利用服务质量降落。
现在，大部分分布式数据库的搭建老本相当高，在计算节点、存储节点和治理节点都须要备份和冗余的独立服务器。如果要为每一个微服务都搭建一套独立的分布式数据库，肯定会造成非必要的资源耗费，最终导致企业无奈接受。
最初，大量企业采纳单元化架构。 基于数据分片的解决方案，将数据库的拆分和单元化一并放到利用端解决。随着数据库数量的增多，架构设计的复杂度会呈指数级增长。长此以往，业务开发团队将无奈把精力集中在最善于的业务研发层面，反而须要破费大量精力投入到根底组件的保护。只管 Apache ShardingSphere 的数据分片性能能够较好解决相干问题，但面对更多元的数据库，仅反对繁多品类数据库的程度分片能力是远远不够的。
2. 技术挑战泛滥
当碎片化数据库共存成为常态时，研发人员的学习与开发成本将不可避免地持续增长。只管数据库大多反对 SQL 的操作形式，但各数据库间仍有大量 SQL 方言的差别。除此之外，各数据库间驱动程序的应用形式也或多或少存在不同。
因而如需精细化应用每一种数据库，必定会占用研发工程师大量的精力，且积淀下来的常识和教训不易传承；如果采纳粗粒度的规范模式对立应用异构数据库，将会埋没数据库本身的特点，而无奈施展其应有的作用。
3. 运维复杂度高
把握各种数据库特色，并结合实际场景制订卓有成效的运维标准，须要大量工夫和实践经验的积攒。除了最根本的运维工作，数据库周边配套工具的差异性也十分大。通过周边配套工具所组成的监控、备份及其他自动化运维等工作，随着数据库品种的减少将会产生微小的运维老本。
4. 数据库间不足合作和统管能力
站在数据库的角度，其首要指标是欠缺本身的能力，而非面向其余数据库的在线合作能力。逾越异构数据库的关联查问、分布式事务等性能，是无奈在数据库自身实现的。
与绝对规范的 SQL 不同，数据库本身的协定和周边生态工具不足对立的规范。对异构数据库的对立管控能力也受到越来越多的关注。但遗憾的是，数据库下层规范的缺失，使得数据库间的合作和统管能力难以获得无效的推动。
Database Plus 是什么？
Database Plus 是一种分布式数据库系统的设计理念。旨在碎片化的异构数据库下层构建生态，在最大限度复用数据库原生存算能力的前提下，进一步提供面向全局的扩大和叠加计算能力。使利用与数据库间的交互面向 Database Plus 构建的规范，从而屏蔽数据库碎片化对下层业务带来的差异化影响。
『连贯、加强、可插拔』 是定义 Database Plus 外围价值的三个关键词。
1. 连贯：打造数据库下层规范
绝对于提供一个全新的规范，Database Plus 更偏向于提供一个能够适配于各种数据库 SQL 方言和拜访协定的中间层，提供凋谢的接口用于对接各种数据库。
因为数据库拜访协定的实现，Database Plus 和数据库在应用体验上并无二致，能够反对任意的开发语言和数据库拜访客户端。
除此之外，Database Plus 可能最大限度反对 SQL 方言间的互相转换。能够将 SQL 解析而成的 AST（形象语法树）依据其余数据库方言的规定从新生成 SQL。SQL 方言转换的能力，买通了连贯异构数据库之间互相拜访的通道，用户能够应用任意一种 SQL 方言拜访异构的底层数据库。
『数据库网关』是对连贯的最佳诠释。 在数据库下层打造凋谢对接的通用层，将碎片化数据库的全副拜访流量会集于此，是 Database Plus 为数据库碎片化提供解决方案的前提条件。
2. 加强：数据库计算加强引擎
数据库经验了数十年的倒退，其本身具备了查问优化器、事务引擎、存储引擎等久经考验的存算能力和设计模型。在 IT 畛域，数据库的设计和应用形式已深入人心，不可动摇。随着分布式和云原生时代的到来，将数据库原有的计算和存储能力全副打散，并织入分布式和云原生级别的全新能力，会不可避免的反复造轮子。
因而，Database Plus 采纳了既器重传统数据库的实践经验，又适配于新一代分布式数据库的设计理念。无论是集中式还是分布式的数据库，Database Plus 都能复用数据库的存储和原生计算能力，并在其根底之上提供全局化的能力加强。
全局化的能力加强次要在分布式、数据管制和流量管制三个方面。
无论是原生面向分布式的数据库，还是基于集中式数据库作为基石的分布式扩大计划，都离不开分而治之这个分布式系统永恒不变的设计原理。 数据分片、弹性伸缩、高可用、读写拆散、分布式事务、以及基于垂直拆分的异构数据库联邦查问等性能，都是 Database Plus 在分布式的异构数据库全局层面下所可能提供的能力。 它的关注点不在于数据库本身，而是站在碎片化的数据库下层，关注于多个数据库之间的全局合作能力。
除了分布式加强之外，数据管制和流量管制的加强能力均处于竖井化领域。面向数据管制的增量能力包含：数据加密、数据脱敏、数据水印、数据溯源、SQL 审计等；面向流量管制的增量能力包含：影子库、灰度公布、SQL 防火墙、黑白名单、熔断限流等。这些均属于数据库生态层所提供的能力，然而在数据库碎片化的态势下，为每一种数据库提供全量的加强能力的工作量非常微小，且缺失对立的实现规范。Database Plus 通过提供支点，将反对的数据库品种和加强性能相叠加，以排列组合的形式提供给用户应用。
3. 可插拔：构建数据库性能生态
一直减少的数据库类型对接和加强性能织入，会使 Database Plus 通用层逐步趋于臃肿。 连贯和加强的可插拔化，既是 Database Plus 通用层维持小而美的基石，也是扩大生态有限化的无效保障。 可插拔的体系，为 Database Plus 通用层提供了插件生态有限扩张的可能，使用者只需依据本身需要裁减插件即可。
通过可插拔体系，Database Plus 将可能真正的构建面向数据库的性能生态，将异构数据库的全局能力对立纳管。它不仅面向集中式数据库的分布式化，也同时面向分布式数据库的竖井性能一体化。
微内核设计和可插拔架构是 Database Plus 理念的外围价值，它面向通用的平台层，而非某项具体性能。
ShardingSphere 在 Database Plus 方向的摸索
Apache ShardingSphere 我的项目历史悠久，从开源伊始的数据库分片中间件，到现在 Database Plus 理念的奠基者和实践者，它的后退步调从未放缓。目前，Apache ShardingSphere 遵循 Database Plus 理念，已实现了 Database Plus 三大外围价值下的大部分基础设施建设。
1. 连贯层
ShardingSphere 已反对 MySQL、PostgreSQL、openGauss 等数据库协定，以及 MySQL、PostgreSQL、openGauss、SQL Server、Oracle 和所有反对 SQL92 规范的 SQL 方言。
连贯层形象的顶层接口可供其余数据库凋谢对接，包含：数据库协定、SQL 解析和数据库拜访等。
2. 加强层
ShardingSphere 的性能加强划分为内核层和可选性能层。
内核层蕴含查问优化器、分布式事务、执行引擎、权限引擎等与数据库内核强相干的性能，以及调度引擎、分布式治理等与分布式强相干的性能。内核性能的每个模块都必须存在，但能够切换至不同的实现类型。以查问优化器为例，如果待执行 SQL 能够完满下推至后端数据库，则采纳基于原始 SQL 与数据库交互的计算下推引擎；如果待执行 SQL 须要逾越多数据源进行关联查问，则采纳基于查问打算树与数据库交互的联邦查问引擎。
可选性能层的功能模块由开源社区积淀而造成。除了最具代表性的数据分片和读写拆散之外，高可用、弹性伸缩、数据加密、影子库等功能模块，都在逐渐的欠缺之中。
3. 可插拔层
从最后的 MySQL + 数据分片为外围的架构模型，到现在的微内核 + 可插拔架构，我的项目进行了彻底的革新。从提供连贯的数据库品种和加强性能到内核能力，ShardingSphere 全副面向可插拔。
ShardingSphere 的架构外围外围，由微内核、可插拔接口、插件实现这三层模型组成，档次之间单项依赖，微内核对插件性能齐全无需感知，插件之间也无需相互依赖。对于一个领有 200+ 模块的大型项目来说，架构的解耦和隔离，是社区凋谢合作、将谬误影响范畴升高至最小的无效保障。
小结
Database Plus 是 ShardingSphere 的实践撑持，ShardingSphere 是 Database Plus 理念的最佳实际。随着 ShardingSphere 的越来越成熟，Database Plus 的拼图也会越来越饱满。
Database Plus 带来的劣势
Database Plus 带来泛滥的劣势，受限于篇幅，无奈在文中一一列举。上面仅从影响零碎架构设计和技术选型方面进行论述。
1. 精细化适配灵便多变的利用场景
用户能够依据本身需要定制化应用相应性能，数据分片不再是应用 ShardingSphere 的必要条件，独立应用数据加密性能的用户已不在少数。ShardingSphere 的可插拔能力不仅限于数据库接入层和性能加强模块自身，每个功能模块的外部也可能基于可插拔架构灵便配置。
以数据分片为例，作为数据分片模块的可插拔局部，分片算法能够由用户自定义配置，无论是规范的哈希、范畴、工夫等分片算法，还是自定义分片算法，使用者都能够依据业务场景须要自在灵便配置，最大限度切合业务场景。
2. 面向架构师的微服务后端撑持能力
Apache ShardingSphere 是微服务后端的数据库单元化最佳计划。正如前文所述，不同的微服务共享一套分布式数据库集群，无论从架构设计的不对称性，还是资源隔离的不可控性，都不能称之为欠缺和优雅的解决方案。为每一组微服务搭建一套分布式数据库集群，则又会造成非必要的资源节约。
绝对于重量级的分布式数据库集群，ShardingSphere-Proxy 所占用的资源节俭很多，为每个微服务集群独享一套数据库集群奠定良好基础。但如果微服务拆分足够精密，为每一组微服务搭建一套 ShardingSphere-Proxy 的额定资源占用仍旧不可小觑。在这种状况下，能够思考应用占用资源更少的 ShardingSphere-JDBC，它作为类库与利用代码部署在一起，无需额定占用资源。
ShardingSphere-Proxy 和 ShardingSphere-JDBC 不仅能够通过混合应用的形式，来满足用户的应用友好度、跨语言适配、高性能、资源节俭等各方面需要；还能够通过 Traffic Rule 让 ShardingSphere-Proxy 和 ShardingSphere-JDBC 在不同特色的 SQL 申请中互相路由，以最小化利用资源占用所带来的影响。
Traffic Rule 能够依据用户自定义的 SQL 特色（如：聚合计算、无分片键的全路由查问等），将占用更多计算资源的申请发送至独占资源的 ShardingSphere-Proxy，而将交易型的轻量级操作保留在微服务利用端。这与边缘计算的理念不约而同，ShardingSphere-JDBC 在微服务利用端的算力和边缘计算节点有殊途同归之妙。用于核心计算的 ShardingSphere-Proxy 能够依据业务本身须要，部署独立的集群服务于多组微服务。
通过灵便应用 ShardingSphere-Proxy、ShardingSphere-JDBC 和 Traffic Rule，这套组合将可能一直激发着架构师的设计灵感和创造力。开句玩笑，正确应用 ShardingSphere 进行优雅的零碎设计，能够被当作优良架构师的准入线。
3. DistSQL 为 DBA 带来数据库原生操作体验
面对数据分片、数据加密等加强性能，Apache ShardingSphere 之前版本次要采纳 YAML 的形式进行配置。对于开发工程师来说，灵便的 YAML 配置应用起来得心应手，但对于 DBA 而言，YAML 的配置形式却存在诸多不便。除了扭转了 DBA 的日常 SQL 操作习惯之外，无奈对接诸如权限、平安、工单、监控、审计等第三方零碎，也让此前的 ShardingSphere 难以实用于生产环境的运维管控。
全新版本的 Apache ShardingSphere 减少了 DistSQL 的操作形式。使用者能够齐全通过 SQL 在任意的数据库终端（如：MySQL Cli、Navicat 等）操作加强性能。数据分片、数据加密、读写拆散等所有的强性能都领有与之相匹配的 DistSQL，应用 DBA 所相熟的 CREATE/ALTER/DROP/SHOW 等 SQL 语法即可实现全副性能的配置。DistSQL 同样反对受权语句的管控，也能够通过对接 SQL 审计平台记录所有使用者的操作记录。
数据库表构造是 Database 的元数据，加强性能配置是 Database Plus 的元数据。DistSQL 的呈现，不仅晋升了用户友好度，也补全了 Apache ShardingSphere 上线和运维的最终拼图。
4. Proxyless 模式晋升性能至极致
在 Service Mesh 畛域，最为经典就是 Istio + Envoy 架构搭配模式。它通过 Sidecar 的部署形式治理 Envoy，做到对利用的无侵入，称之为 Proxy Service Mesh，升高了开发、应用和降级的老本，但因为在拜访链路中减少了 Proxy/Sidecar 这一层，使得性能有所降落。
而 Proxyless Service Mesh 则采纳另一种设计模式，它始于 gRPC 对 xDS 协定的实现，Istio 新版本通过 gRPC + xDS 的形式，容许利用代码间接通过 Istio Agent 提供的 SDK 编程，无效晋升了通信性能。
在分布式数据库畛域，存算拆散的架构设计模式曾经深入人心。计算节点和存储节点拆散的设计，与 Proxy Service Mesh 的架构模型有些相似。ShardingSphere-Proxy 的设计齐全符合了存算拆散的架构模型，它无效升高了用户的开发、应用和降级老本，却不可避免带来了肯定的性能损耗。
对于性能延时敏感的利用而言，与 Proxyless Service Mesh 设计理念不约而同的 ShardingSphere-JDBC 无疑更加适合，其可能将零碎的性能施展至极致。在近期应用 ShardingSphere + openGauss 测试 TPC-C 模型的后果中，失去了惊人的 16 台服务器超过 1000w tpmC 的测试后果，行业等同规模下性能最佳。
* 文章参考：16 台服务器达成 1000 万 tpmC！挑战分布式数据库性能极限
小结
始终以来，先进的设计理念和翻新均源于东方。但 gRPC 的 Proxyless 设计理念是近期才呈现的，而 ShardingSphere-JDBC 则是我的项目在 2016 年开源伊始时就曾经存在。 因而，ShardingSphere-JDBC 并未参考 Proxyless 的设计理念，它是基于过后国内互联网业务对高并发和低延时的极致性能要求而诞生的。
至于 Database Plus 理念的设计，又何尝不是如此。随同着互联网的长期疾速倒退，业务的变动间接推动了技术的积攒和成长，ShardingSphere 就是这一过程的最好例证，它的设计方案全副源自于实在业务场景。中国互联网无疑是寰球最全面的场景之一，在此类场景下诞生的设计理念，在寰球范畴内也肯定领有非常广大的成长空间。
将来布局
只管在 Database Plus 理念的实际路线上越走越远，但 Apache ShardingSphere 依然有大量的工作期待实现。数据库网关和异构联邦查问，是欠缺 Database Plus 理念的重要性能拼图。
1. 数据库网关
Apache ShardingSphere 尽管反对异构数据库的对接，但无奈做到数据库之间方言的互相转换。在 ShardingSphere 的线路布局中，SQL 方言转换是实现数据库网关的重要性能，用户通过 PostgreSQL 的数据库协定用 MySQL 方言拜访 MongoDB 将不再是难以实现的工作。
2. 异构联邦查问
Apache ShardingSphere 目前仅反对同构数据库间的联邦查问。在 ShardingSphere 的线路布局中，异构数据库间的联邦查问也将被提上日程。用户通过一条 SQL 关联查问 MySQL 和 HBase 的场景将不再边远。
写在最初
Apache ShardingSphere 社区已在开源畛域耕耘了 7 年的工夫。短暂的保持，使社区更加成熟，已呈凋谢和多元化的势态。咱们披肝沥胆地欢送有开源情怀和编码激情的敌人一起参加社区共建。
Apache ShardingSphere 的可插拔架构和数据分片哲学已在学术界取得宽泛认可。在往年的数据库畛域顶级的会议 ICDE 中，已胜利发表论文“Apache ShardingSphere：A Holistic and Pluggable Platform for Data Sharding”。
- 链接：ICDE 2022|Apache ShardingSphere：一个性能全面和可插拔的数据分片平台
- 我的项目地址：https://github.com/apache/shardingsphere
欢送点击链接，理解更多内容：
Apache ShardingSphere 官网：https://shardingsphere.apache.org/
Apache ShardingSphere GitHub 地址：https://github.com/apache/shardingsphere
SphereEx 官网：https://www.sphere-ex.com
欢送增加社区经理微信（ss_assistant_1）退出交换群，与泛滥 ShardingSphere 爱好者一起交换。
