ShardingSphere-on-Cloud + Pisanix，打造符合未来云原生趋势的 Sidecar 服务

一直来，网上的许多文章、视频在介绍 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 在数据库与前端应用层之间新增了一跳网关，对性能肯定会产生部分影响。