ShardingSphere-on-Cloud + Pisanix,打造符合未来云原生趋势

一直来，网上的许多文章、视频在介绍 ShardingSphere 时，都会提到『ShardingSphere 是由 ShardingSphere-JDBC、ShardingSphere-Proxy 和 ShardingSphere-Sidecar 这 3 款相互独立的产品组成』。随着 ShardingSphere 影响力的增加，JDBC 和 Proxy 被越来越多地应用到了各类生产场景当中，不过 Sidecar 却一直都处于『规划中』的状态。

在云原生已经成为确定趋势的今天，数据库上云/使用云原生数据库成为了许多企业的重要选项之一。对于定位为『Kubernetes 云原生数据库代理』的 ShardingSphere-Sidecar 而言，无疑是一次非常好的发展机会。

有细心的同学应该已经发现了，在 ShardingSphere 最新的官方文档中已没有关于 Sidecar 的介绍。那么 ShardingSphere-Sidecar 是已经被取消了吗？接下来 ShardingSphere 在云原生环境下是如何规划的？相信这会是许多 ShardingSphere 用户非常关心的重点所在。

ShardingSphere 的云上规划

一 ShardingSphere-Sidecar 不再研发

从 ShardingSphere 的用户视角来看，ShardingSphere-JDBC 与 ShardingSphere-Proxy 已经可以解决绝大部分的问题了，在相当大的程度上，ShardingSphere-Sidecar 与前两者只是部署形态层面的区别。JDBC 和 Proxy 功能同等，又各有所长。

ShardingSphere-JDBC 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供额外服务。使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架，主要面向开发者人群，具备更高的性能。

ShardingSphere-Proxy 定位为透明化的数据库代理端，通过实现数据库二进制协议，对异构语言提供支持。目前提供 MySQL 和 PostgreSQL 协议，透明化数据库操作，对 DBA 更加友好。但由于 Proxy 在数据库与前端应用层之间新增了一跳网关，对性能肯定会产生部分影响。

因此社区推荐用户采用混合部署模式，使 JDBC 与 Proxy 能够在同一体系下实现优势互补，最大化 ShardingSphere 本身在性能、可用性、异构支持等方面的特性优势。

参照上图，就会发现 ShardingSphere-Sidecar 的地位其实稍稍有些尴尬。不论是面向用户、环境，或是对业务所显现出来的突出作用，JDBC 与 Proxy 已经囊括了大部分场景，并且实现了很好的互补，对于 Sidecar 而言并没有太多可以创新的余地。对于社区以及用户而言，此前的 ShardingSphere-Sidecar 更多是 ShardingSphere 在部署模式的探索，无法像 JDBC 以及 Proxy 一样从整体上提升 ShardingSphere 的能力。

因此，在现有 JDBC 和 Proxy 的基础上为 ShardingSphere 提供在 Kubernetes 环境下运行且易用的工具『补丁』，既能够满足用户对于云原生环境下部署、使用 ShardingSphere 的需求，也极大节省了 ShardingSphere 社区的研发人力，无疑是最高效的一种选择。

二 ShardingSphere 云上解决方案：ShardingSphere On Cloud

ShardingSphere-on-Cloud 是对 ShardingSphere 更加全面的体系升级。

ShardingSphere-Sidecar 诞生于 Kubernetes 的爆发期，彼时越来越多的公司开始逐步尝试和接纳云原生的理念、工具，并演化为自己的最佳实践。ShardingSphere 社区也抱着同样的想法提出了 ShardingSphere-Sidecar，希望通过 Sidecar 的形式助力数据领域的云原生变革。不过，随着旗下的 JDBC 和 Proxy 已经相对成熟，可以应对很多场景中业务对数据治理的需要，将整个 ShardingSphere 全部云原生化，似乎并不必要。

归根结底，其实 Sidecar 模式可以在一定的场景中发挥重大作用，但并不代表所有的组件都必须实现一套 Sidecar 的版本。ShardingSphere 对云原生的支持应当是在充分适配云计算的理念后，以用户真实的云原生场景得出来的一整套解决方案，正是在这种思路的带领下社区推出了 ShardingSphere-on-Cloud 项目。

ShardingSphere-on-Cloud 的主要功能就是在 Kubernetes 环境下实现面向 ShardingSphere 的部署和迁移工作，借助 AWS CloudFormation、Helm、Operator 以及即将发布的 Terraform 等工具，为用户在云原生场景下提供『快速部署、可观测性提升、安全和迁移、高可用部署』等最佳实践。

具体可查看 ​​ShardingSphere-on-Cloud 发版文章。 ​​

通过 Pisanix 实现过去对于 ShardingSphere-Sidecar 的愿景

一 为什么要选择重新写一款面向云原生场景数据治理的开源项目？

应用场景处于不断变化的过程中，任何一个技术理念也不会是止步不前的，因此社区对于 ShardingSphere 的定位以及 Database Mesh 理念的思考也在产生变化。

不同时期的 ShardingSphere 社区，对于 Sidecar 的理解也不同。最开始 ShardingSphere 社区希望通过 Sidecar 来统一治理云上的数据问题，不过后续随着社区对于云原生以及云上数据治理流程的理解，逐渐发现此前所规划的 ShardingSphere-Sidecar 的局限性。

由于只是一种 ShardingSphere 在云原生环境中的部署形式，ShardingSphere-Sidecar 只能解决应用在云原生环境下的一个『问题点』，在应用场景更加多变、数据使用更加复杂的云上，虽然云生态更加开放，但 ShardingSphere 在过去研发时不可避免带来的局限性还是阻碍了 ShardingSphere 在云上的发挥，因此无法形成一套成熟的面向企业在云原生环境中的整体解决方案。

出于以上考虑，我们需要在云原生场景中重新设计一款，能够在云原生体系下具有更强的适配性、更高的可用性、更快的敏捷性的开源产品，以弥补 ShardingSphere 在云上数据治理所产生的局限性问题。

因此，SphereEx 团队以 Database Mesh 理念为基础，​​研发并开源了云原生数据治理工具 Pisanix，​​为用户提供 SQL 感知的流量治理、面向运行时的资源管理、数据库可靠性工程等能力。

二 现在的 Pisanix，和当初设想的 ShardingSphere-Sidecar 相同吗？

ShardingSphere-Sidecar 和 Pisanix 分别代表了社区在不同阶段对 Database Mesh 的理解，因此两者之间自然也存在一些不同：

• 设计理念不同：JDBC & Proxy 的设计哲学是 Database Plus，是在多种数据源之上添加一层统一治理和增强的平面；Pisanix 是 Database Mesh 设计理念的具体实践，希望通过云原生的方式，让云原生场景中的应用以更加高效和流畅的方式来使用数据库及运维数据库；
• 语言生态不同：JDBC 是 Java 语言生态，虽然语言生态单一，但 Java 具有很广阔的企业级社区用户和开发者基础，能够被 Java 应用更方便地引用；Pisanix 是 Rust 生态，基于 Rust 语言的特性来提高接入层的可靠性和效率。

虽然这两种框架呈现的形式有所差异，但其核心都指向了云原生的数据基础设施，这也正是 Database Mesh 希望通过实现云原生的数据库可靠性工程所实现的远景目标。

在部署形态层面，Pisanix 同 ShardingSphere-Sidecar 一样，都能够以 Sidecar 的形式同业务应用部署在一起，为开发者提供标准的协议接入。在面对 ShardingSphere 生态的时候，Pisanix 同样可以基于自身对于 ShardingSphere 生态的高兼容性，用户可以使用与 ShardingSphere-Proxy 连接 MySQL 同样的方式来使用 Pisanix 连接 ShardingSphere-Proxy。

简而言之，ShardingSphere 在 Database Plus 的理念下，为开发者和应用暴露出一个完全的数据库形态。Pisanix 的目的也是如此，用户可以通过 Pisanix 将 ShardingSphere-Proxy 作为数据库来使用，通过 Pisanix 这个云上的数据流量入口，逐步探索云原生环境下的协作模式。

不过两者又分别是独立的产品线，Pisanix 从设计之初就吸收了 Database Mesh 的核心思想，通过『本地即数据库、统一配置管理、多协议支持、云原生架构』这四个层面实现高性能扩展。

作为 Database Mesh 理念的工程化实现，Pisanix 所实现的只是『将云上数据库个类型为统一治理起来』这个目标的第一步，因此对于 Pisanix 而言，Sidecar 只是它的一种部署形式，有可能在未来 Pisanix 会演化为其它形态，届时 Sidecar 可能就会成为 Pisanix 其中非常小的一部分。

不同数据库的协议和运维特性是千差万别的，困难就在于能否抽象出标准的治理行为。

不同于 Pisanix 的是，ShardingSphere 生态并非只能通过协议接入，ShardingSphere-JDBC 可以被 Java 应用更加方便地引用和使用，这种天然的亲和性不仅保持了功能的完整性，还大大优化了资源使用，提供极致的性能，开发者可以最大化利用这种适配能力，从业务角度自由地配置数据的治理。同时用户通过 ShardingSphere 与底层数据库结合，将较强的计算能力以某种方式部署在应用端，进而将原有的单体数据库变成一个高性能的分布式数据库，避免资源浪费，提供相较于其它分布式数据库更加高性价比的解决方案。

因此，实际上 ShardingSphere 与 Pisanix 共同为社区用户提供了两种解决方案：对于需要将 ShardingSphere 部署在 Kubernetes 环境中的用户来说，ShardingSphere-on-Cloud 已经完全能够满足其需求，至于 ShardingSphere 中的其它功能，与在本地使用时的方式、效果都并无二致；同样，如果用户需要在云原生场景中进一步对上层数据库实现统一的流量治理，Pisanix 会更加有效。

对于 ShardingSphere-Sidecar 来说，相较于长期处于『规划中』的状态，ShardingSphere-on-Cloud 与 Pisanix 的模式更加有效，也更加直接。用户可以根据自己的需要，合理选择更加精准的服务，从容应对不同场景下的数据治理需求。

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