ShardingSphere 与 Database Mesh 之间不得不说的那些事

背景

前段时间，以 Apache ShardingSphere 核心团队组建的创业公司 SphereEx，正式对外推出了 Database Mesh 2.0 概念以及与之相配套的开源产品 Pisanix，这引发了社区间对于 ShardingSphere 和 Database Mesh 的不少争论与思考。许多用户都很清楚，SphereEx 是由 Apache ShardingSphere 核心团队创立的。

那么有部分用户就提出了疑问，既然已经有了 Apache ShardingSphere 这样一个如此成功的开源项目，为何还要大费周章选择在一个全新的领域从头开始？在云原生趋势的影响下，未来 ShardingSphere 会不会逐渐被并入到 Database Mesh 的理念体系中？

随着 SphereEx 推出 Database Mesh 2.0 概念，并开辟了另一条开源发展路线，看似与此前已经大获成功的 ShardingSphere 产生了冲突，但实际上，两者是“同气连枝、相辅相成”的关系。本篇将主要针对 ShardingSphere 社区用户对于 Database Mesh 概念以及未来发展方向做出整体阐述，带领大家从头梳理 Apache ShardingSphere 的指导理念 Database Plus，以及与 Database Mesh 理念之间的脉络联系。

一、从微服务治理到云原生数据库服务治理，变在了哪？

相比于微服务，云原生下的数据库治理在功能选择上会有不同的侧重。

首先，数据库是有状态的，请求无法像服务一样被随意路由到对等节点，因此对于数据库而言，数据分片是一个重要的能力；另外，由于数据库连接本身具有状态性，启动或停止一个新的数据库实例，往往意味着数据同步和复制，因此相较于微服务，实例自动发现能力的重要性就会降低。

如果将数据库看作为一个微服务，虽然可以通过 Service Mesh 对数据库访问进行治理，但却会受到许多限制。同时，数据库拥有一些特殊治理属性，比如通信协议、资源管理、基于数据请求的负载均衡、分库分表、还有可观测性、访问控制等。这些都不能简单地以服务的概念来理解和解决，而是属于数据库可靠性工程领域的问题。

这就为 Database Mesh 的发展提供了空间。SphereEx 提出的 Database Mesh 2.0 概念更关注在云原生环境下，如何实现以下几个目标：

●  进一步减轻开发人员的心智负担，提高开发效率，提供透明和无感的数据库基础设施使用体验；

●  以可配置、可插拔、可编程的方式，实现一个覆盖数据库流量、运行时资源和稳定性保障等方面的治理框架；

●  为异构数据源、云原生数据库、分布式数据库等多个数据库领域的典型场景提供标准的使用界面。

提供数据分片、负载均衡、可观测性、审计等能力，这些能力已经解决了数据库治理中属于流量治理的部分问题。更近一步地，当业务应用开始以容器的方式进行打包交付、利用 CI/CD 流水线每天发布成百上千次到各个数据中心的 Kubernetes 基础设施的时候，引发了对云环境下如何实现数据库可靠性工程的思考，Database Mesh 2.0 就是在这种思考之下的产物。

二、ShardingSphere 的指导理念 Database Plus，与 Database Mesh 之间的不同

首先，理念不同

其实，只看理论和概念，Database Mesh 与 Database Plus 之间还是有相当大差异的。

●  关于 Database Mesh，SphereEx 认为云上数据库治理有共性也有其独特性。对于共性问题可以通过标准化和自动化的方式加以解决，独特性的可以通过提供一种灵活的扩展机制，让工程师可以按需配置和实现因此需要通过可编程实现高性能扩展，应对云上数据库治理挑战；

●  而关于 Database Plus，Apache ShardingSphere 社区则认为这是一种分布式数据库系统的设计理念，旨在碎片化的异构数据库上层构建生态，在最大限度地复用数据库原生存算能力的前提下，进一步提供面向全局的扩展和叠加计算能力。使应用和数据库间的交互面向 Database Plus 构建的标准，从而屏蔽数据库碎片化对上层业务带来的差异化影响。

不过随着数据库上云的趋势不可避免，Database Mesh 与 Database Plus 这两者之间难免会产生交集。在云原生以及分布式数据库的场景下，ShardingSphere 与 Database Mesh 之间将会产生更多的火花。

其次，应用场景不同

在 Database Plus 理念指导下的 ShardingSphere，主要被应用于分布式数据库场景之中，Database Mesh 主要被用来指导云原生场景下数据库可靠性的具体实践。作为两个不同领域的不同设计哲学，Database Plus 和 Database Mesh 均代表了在各自数据治理场景中的科学理念，并且在科学理念的指导下，诞生了 ShardingSphere 和 Pisanix 这两款开源实践产品。

Database Mesh 2.0 希望提供一种以数据库为中心的治理框架：

●  数据库是一等公民：一切抽象围绕数据库治理行为进行，比如访问控制、流量治理、可观测性等；

●  面向工程师体验：对于开发人员，通过便捷易用的数据库声明和定义，即可进行开发，无需关心数据库的位置；对于运维和 DBA，提供多种数据库治理行为抽象，实现自动化的数据库可靠性工程；

●  云原生：以开放的生态和实现机制适配不同的云环境，面向云原生构建和实现，而无需担心厂商锁定。

而 Database Plus 则希望以『连接、增强、可插拔』为核心，在碎片化的异构数据库上层构建计算生态。以解决本地架构选型困难、技术及运维复杂度高、数据库上层标准缺失、数据库间缺乏协作和统管能力等问题。

总而言之，Database Plus 理念下的实践 Apache ShardingSphere，是面向于分布式数据库场景下的具体实践。而 Database Mesh 则是在云原生场景下的，面向云原生场景下数据库治理难点的解决方案。

最后，业务场景与诉求所引发的转型契机不同

从关系型数据库到分布式数据库，应用场景的不断扩张，数据库在不同场景下的优劣表现，均决定了企业应用数据库的多元并存常态。碎片化是数据库领域的大势所趋，单一品类的数据库无法适用于所有场景，只能适用于某一种或某几种擅长的场景。而在业务场景的驱动下，采用分布式数据库解决方案，已经成为应对大流量、高并发、缓解数据库压力的行业共识。

同样由于场景驱动，在分布式数据库风靡全球的这几年中，云计算也在充分发挥着自身的优势与特性。虽然不能预测未来的发展和变化，但对于云计算来说，随着云原生环境的成熟，天然产生于云环境下的数据库（即云原生数据库）越来越多，其不仅集中在各家云厂商手中，市面上更是有越来越多产品涌现出来。

加之使用场景以及在不同的用户视角里，开发人员更关注运行效率、成本开销，以及数据库协议类型和访问信息，不关心数据存储的位置。运维和 DBA 更关注数据库服务的自动化、稳定性、安全性、监控报警等，此外 DBA 还会关心数据的变更、容量、安全访问、备份、迁移等等。正是随着对数据库治理场景的深入理解和对用户体验的极致追求，共同催生了 Database Mesh 2.0 的核心思想：通过可编程实现高性能扩展，应对云上数据库治理挑战。

三、当分布式成为共识、云原生趋于繁荣：ShardingSphere 与云之间会冲突吗？

早在 Service Mesh 大行其道的 2018 年，Apache ShardingSphere PMC Chair 张亮就曾借着 Service Mesh 的东风，创造性地提出了 Database Mesh 概念，设想是否有一种模式可以有效的结合 JDBC 代理端与 Proxy 客户端的优点并屏蔽其缺点，借助“弹性伸缩 + 零侵入 + 去中心，实现了一个真正的云上基础设施”，而当时设想中的 ShardingSphere Sidecar，正是 Database Mesh 1.0 阶段的产物。

随着迎来『分布式成为共识、云原生趋于繁荣』的阶段，作为一款由社区主导的开源项目，自然需要跟着业务、场景的变化而变化。ShardingSphere 也在这一条件下经历了从 Sharding-JDBC 到 ShardingSphere 的转变，不只是名称的变化，更是 ShardingSphere 产品本身定位和技术生态领域的变化。

Pisanix 是用 Rust 和 Go 重写的上云版 ShardingSphere？

近期，SphereEx 对外开源了面向 Database Mesh 的解决方案 Pisanix。对于 Pisanix 面向数据库流量的核心组件 Pisa-Proxy 而言，其与 ShardingSphere-Proxy 两者的架构非常相似，粗略一看很容易将这两者联系为重构的关系。

当然也不只是 Pisanix 与 ShardingSphere-Proxy，所有面向 MySQL 数据库的代理的架构设计都大同小异。尤其是数据库领域，存在着一定的同质化问题。不过对于产品而言，关键就是在其间寻找差异。对于 Pisanix 与 ShardingSphere-Proxy 而言，这两者的区别在于在拿到数据后要实现怎样的效果，解决用户怎样的问题。

因此，Pisanix 不能简单的被认为是用 Rust 重写的 ShardingSphere，两者完全不同，只是在入口处比较像。对于数据库领域而言，总归是有相似点的。

另一方面，许多用户会非常自然地将 Database Mesh 与 ShardingSphere-Sidecar 划作等号。但其实这两者在内核层面有很大不同，这也是区别两者的最关键因素。目前，作为 Database Mesh 理念的实践，Pisanix 已能够承担一部分原有 ShardingSphere-Sidecar 在云原生环境下的数据治理能力，方便用户在云上环境中使用 ShardingSphere。

Pisanix 项目地址：https://github.com/database-mesh/pisanix

对于 Database Mesh 而言，Sidecar 并不是它的内核。Database Mesh 的内核一定是面向某个具体的、工程化的问题，Sidecar 只是 Database Mesh 概念其中的一种部署形式。有可能未来有一天 Pisanix-Proxy 就不是 Sidecar 的形式了，也有可能会演化成一个很薄的中间层。总而言之，Sidecar 只是实现治理能力的一个手段。

Database Mesh 真正的内核在于对用户体验、数据库服务治理等层面的拓展。如果未来有更多数据库类型的出现，有更多云上云下的场景出现，Database Mesh 的概念也会进一步实现扩展，这才是 Database Mesh 正在追求的方向。

Database Mesh 想做的是把各种云上的因素屏蔽掉，统一将上层数据库的各类行为治理起来。但不同数据库的协议和运维特性是千差万别的，困难就在于能否抽象出标准的治理行为。技术方案本身是多种选择中的一种，最核心的部分是用户体验。至于选择 Java 还是 Rust 或是 Python，都只是技术方案中的一部分，通过选择合适的语言的来保持项目的生命力以及生态，这些都是必须要考虑的部分。

四、数据库未来全景图：ShardingSphere + Database Mesh +....

Database Mesh 可以治理 ShardingSphere 吗？

如果把 ShardingSphere 看作为一个高性能的分布式数据库，对于 Database Mesh 而言，治理 ShardingSphere 与治理 MySQL、TiDB 等数据库都是一样的。

因此尽管可以治理，但 ShardingSphere 本身并不额外需要其它理念的影响，因为对  ShardingSphere 的设计哲学 Database Plus 而言，是通过连接、增强、可插拔的特性将 MySQL 本身不具备的能力增强出来。这种增强是原生数据库不具备的能力，而通过 ShardingSphere 则能够与底层数据库结合，将较强的计算能力以某种方式部署在应用端，变成一个高性能的分布式数据库，避免资源浪费，提供相较于其它分布式数据库更加高性价比的解决方案。

云原生的场景下的机遇

接下来，让我们把眼光着眼于行业。众所众知，云是代表着未来，代表着不可逆的方向。因此，一个项目、一款产品、一个理念，能否服务于这个『不可逆』的未来，将直接影响到自己的生命周期与影响力。这也是 ShardingSphere 规划上云、也一定会上云的根本原因。

在 Database Plus 理念的指导下，Apache ShardingSphere 可以在云数据库现有基础上拓展更多功能，为企业、云计算平台提供更加强大的跨不同数据库产品本身的能力，底层兼容多个数据库，兼容云端各类数据库产品，研发侧无需感知；另外，以保持云中立的身份，确保云端体验与本地体验相同，支持多云架构，在不同云的基础设施下提供同样的体验，这正是 ShardingSphere 在云原生场景下的机会与能力。

文章转载自公众号：ShardingSphere官微