Kubernetes 环境下的数据库新命题( 三 ) _Kubernetes

4 命题二：如何让分布式数据库系统变得无状态，真正实现分布式 + 云原生？
如上所述，数据库系统一般由计算节点和存储节点组成。当用户使用现有的生产环境的数据库作为新分布式数据库系统的存储节点时，ShardingSphere 则可以作为全局的计算节点，提供分布式数据库计算服务，即经典的计算存储分离的架构。这种架构在 Cloud native 场景下，特别是 Kubernates 上有了重新的解读和应用。将计算节点作为无状态的应用部署在 Kubernates 上，并利用 Kubernetes 天然的平台能力来解决传统单点数据库分布式改造的课题。而存储节点可以部署在任意位置，可以是 Kubernetes 集群内、云的 RDS、私有环境等，真正实现分布式数据库存算架构的解耦和云化问题。
用户可以使用 ShardingSphere-Chart 以及 ShardingSphere-Operator-Chart 这两款工具轻松地部署和管理 ShardingSphere 集群，并在 Kubernetes 上创建自己的分布式数据库系统，无需关注单体数据库的位置，利用 Kubernetes 管理无状态计算节点，用户所创建的数据库可在任何公有云或私有云上，通过让 Kubernetes 上的 ShardingSphere (全局计算节点) 访问任意位置的单机数据库，从而对最终用户提供透明化的、完整的分布式数据库的解决方案，大幅降低升级改造成本，并提升整体的性能和存储能力。
在这类体系中 ShardingSphere-Proxy 将作为全局计算节点处理用户请求，从分片存储节点中获取本地结果集并进行计算。这意味着无需对生产环境的现有数据库集群进行危险操作，只需要将 ShardingSphere 导入到现有的数据库基础设施层，就可以将单机数据库存储节点与 ShardingSphere 全局计算服务器连接起来，形成一套完整的分布式数据库系统解决方案。
另一方面，为了提升该集群的可用性和自动扩缩容等特性，用户可使用 ShardingSphere-Operator 按业务需求量对 ShardingSphere-Proxy（计算节点）和数据库（存储节点）进行分别的扩缩容，真正实现按需分配、一键弹性。例如，有些用户只需要增强计算能力，ShardingSphere-Operator 将在几秒钟内自动扩容 ShardingSphere-Proxy，而不会对存储能力做任何改变，无危险操作、无付费成本。也有一些用户只关注存储容量，而对计算能力无过多期望，这时他们只需要快速启动更多的空数据库实例并执行 DistSQL 命令，ShardingSphere-Proxy 将对新旧数据库重新进行数据分片，以提高容量和性能。
采用 ShardingSphere 对现有数据库集群进行平滑分片，并以更为云原生的方式将其部署于 Kubernetes 上。与其关注如何从根本上打破当前的数据库基础设施，忙于重新寻找一个可以在 Kubernetes 上作为有状态应用进行有效管理的分布式数据库，我们不如从另一个角度思考这个问题：
『如何让分布式数据库系统变得“无状态”、充分利用现有的数据库集群、真正实现分布式 + 云原生？』
下面将展示两个真实场景案例：
Kubernetes 上的数据库
首先使用 Helm charts 等方法将数据库（如 MySQL 和 PostgreSQL）部署到 Kubernetes 环境中，然后使用 ShardingSphere charts 成功部署了 ShardingSphere-Proxy 和 ShardingSphere-Operator 集群。完成部署后，用户可以使用原生的驱动访问方式连接 ShardingSphere-Proxy，使用 DistSQL 让 ShardingSphere-Proxy 感知到单机数据库，即分布式计算节点连接到存储节点，形成最终的分布式数据库解决方案。

文章插图
云端或本地数据库
下图为云端、本地的数据库两种形态的部署架构。下图右半部分体现云上计算 + 云下存储的分布式数据库架构，即计算节点 ShardingSphere-Proxy 及 “云上 DBA” ShardingSphere-Operator 在 Kubernetes 上运行，但是数据库（存储节点）位于 Kubernetes 之外。