背景
前段时间，以 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 在云原生场景下的机会与能力 。
作为两款齐全独立的设计哲学，Database Plus 与 Database Mesh 之间并不是竞争关系。相同，Database Mesh 与 Database Plus 之间能够产生很好的化学反应。这两者都是基于数据库现有的碎片化生态、用户所面临的痛点来提供解决方案。只管方向不同，但均代表了时下对于解决不同场景下数据治理难题的最佳思路。
目前 Database Mesh 官网 已上线，相应的标准定义也开源在（https://github.com/database-mesh/database-mesh）仓库里。同时 Database Mesh 的具体实际 Pisanix 也已开源，欢送大家的关注。
我的项目地址：https://github.com/database-mesh/pisanix
官网地址：https://www.pisanix.io/
Database Mesh：https://www.database-mesh.io/
SphereEx 官网：https://www.sphere-ex.com