数据库治理的云原生之道——Database Mesh 2.0

数据库治理的云原生之道——Database Mesh 2.0

2018年3月，一篇《​​Service Mesh是大方向，那Database Mesh呢？​​》 迅速火爆技术圈。在这篇文章中，Apache ShardingSphere 创始人张亮沿着 Service Mesh 的思路，对 Database Mesh 进行了畅想。

四年过去了，当年的 Database Mesh 理念已经在一些公司开花结果，配合各自的工具和生态进行了实践。今天再看，除了 Service Mesh 以外，“X Mesh” 的理念已经深入人心，ChaosMesh、EventMesh、IOMesh 等各种类型的 Mesh 如雨后春笋般涌出，而 Database Mesh 经过四年的沉淀也迎来了属于它的新一页：Database Mesh 2.0。

本文将带领各位读者回顾 Database Mesh 诞生的背景，重新审视 Database Mesh 1.0 的价值，并为大家介绍 Database Mesh 2.0 的新概念、新思路和新特性，共同探讨 Database Mesh 的未来之路。

Database Mesh 1.0 回顾

2016年，第一代 Service Mesh 由 Linkerd 带入大众视野，紧接着2017年就诞生了以 Istio 为代表的第二代 Service Mesh，采用了控制面和数据面分离的设计模式，将服务治理中如流量治理、访问控制、可观测性等关键行为要素进行了抽象和标准化，然后借助 Kubernetes 的 Sidecar 模式解耦了应用容器和治理容器。至此，Service Mesh 的形态已经基本确定。

几乎是同样的时间点，由张亮主导的 ShardingSphere 从原来的 ShardingSphere-JDBC 演化出来了可以独立部署的 ShardingSphere-Proxy。它们都采用 Java 构建实现，分别代表了 SDK 模式和 Proxy 模式，提供了相同的标准化数据分片、分布式事务等功能。但无论使用哪种方式，都有其各自的优缺点。在2018年这篇《​​Service Mesh是大方向，那Database Mesh呢？​​》 中是这么描绘 Database Mesh 的：

如此一来 Service Mesh 在 Kubernetes 上的 Sidecar 模型实现就变得非常有启发性：采用 ShardingSphere-Sidecar 模式，可以有效的结合 JDBC 代理端与 Proxy 客户端的优点并屏蔽其缺点，借助“弹性伸缩 + 零侵入 + 去中心，实现了一个真正的云上基础设施“。

任何一个新技术概念在它落地的时候，都会因为不同的业务场景和模式、不同的架构设计模式、不同的基础设施成熟度、乃至差异的工程师文化而打上自己独特的烙印。这一点在 Kubernetes 落地历程中已经得到了充分验证， 而 Service Mesh 落地又再次加深了这个观点。那么对于 Database Mesh 呢？

ShardingSphere-Sidecar 试图将 ShardingSphere 的核心分片能力等迁移到其中，而一些公司在 Database Mesh 基础上丰富了更多观点，比如在 Service Mesh 的框架中，通过二次开发的方式增加了对 SQL 协议的解析和支持，增强了数据库流量治理能力，兼容了统一的服务治理配置；比如将 Database Mesh 的理念集成到一套完整的中间件服务框架中，以 SDK 或者 Sidecar 的方式给业务应用暴露统一的访问方式，简化开发者的使用；还比如将分布式事务能力集成到 Database Mesh Sidecar 中的项目，以云原生分布式数据库的方式为业务应用进行呈现。

不管是哪种方式，都可以看出来 Database Mesh 理念正在不断深入人心，逐步成长为一个繁荣的生态。

注：从左往右分别为“ShardingSphere-Sidecar、统一 Mesh 管控、分布式数据库”三种 Database Mesh 1.0 的实现。

这个阶段的 Database Mesh 为1.0阶段。

Database Mesh 2.0 介绍

在计算机科学的世界里，操作系统和数据库可谓是两大最重要的基础软件。就拿 SQL 这门语言来说，它的半衰期之长令人记忆深刻。SQL 不仅在早期的 DBMS 系统中扮演了相当重要的角色，近些年在数据科学领域和 Python 一同成为从业人员的必备技能。SQL 的生命力真可谓是“历久弥新”，以至于有论文直言希望“One SQL to rule all”。这也从侧面反映了数据库领域历史之久，地位之重，具备浓重的领域特色。

如果将数据库视为调用链上一个服务节点，那么同样可以采用 Service Mesh 的框架进行治理。而如果将数据库视作一个有状态的业务应用，它独特的领域性带来了治理的特殊性：比如，数据库请求无法像服务一样可以被随意路由到任何对等节点。而对数据库协议的感知和理解、数据分片和路由、数据库部署的多副本、读写分离、主库多写等模式，也带来了更多的挑战。

更近一步地，当业务应用开始以容器的方式进行打包交付、利用 CICD 流水线每天发布成百上千次到各个数据中心的 Kubernetes 基础设施的时候，必然会引发对应用上层服务治理和对数据库治理的思考，Database Mesh 就是这种思考之下的产物。如果没有 Database Mesh，不管是 SDK 还是 Proxy，同样可以支持对数据库的访问治理，Sidecar 本身并非 Database Mesh 的内核，实际上是基础架构全面云原生化的浪潮，在不断推着 Database Mesh 前进。

Database Mesh 不是静态的定义，而是一个在不断进化的动态概念。

Database Mesh 2.0 的目标

Database Mesh 2.0 关注在云原生环境下，如何实现以下几个目标：

进一步减轻开发人员的心智负担，提高开发效率，提供透明和无感的数据库基础设施使用体验以可配置、可插拔、可编程的方式，实现一个覆盖数据库流量、运行时资源和稳定性保障等方面的治理框架为异构数据源、云原生数据库、分布式数据库等多个数据库领域的典型场景提供标准的使用界面

开发者体验

如前所述，业务开发人员主要关注业务逻辑和实现，无需关心基础设施和其运维特征，而开发的体验会逐步向 Serverless 的方向前进，对数据库的访问也就必然会变得越来越透明和无感。开发人员只需要了解自己业务所需要的数据存储类型，然后使用预置的或者动态的身份机密信息，即可访问相应的数据库服务。

可编程

对于数据库流量来说，不同的场景会有不同的负载均衡策略和防火墙规则，这些都可以以配置的形式提供给用户。更进一步地，对于流量带宽等运行时资源，可以通过加载可编程插件的方式对其进行限制。无论是配置还是插件，都希望给用户提供框架之内最大的灵活度，践行 Unix “机制和策略分离”的设计哲学。

标准界面

在数据库上云的过程中，因为部署模式、数据迁移、数据容量等诸多问题，增加了上云的复杂度。而标准化的操作可以极大地帮助上云过程。如果可以有一套完整的操作界面，就可以在不同的数据库环境里实现统一的治理行为，从而让未来上云的过程变得更加顺滑。

Database Mesh 2.0 治理框架

为实现上面的三个目标，Database Mesh 2.0 提供了一种以数据库为中心的治理框架：

这套治理框架依赖于如下工作负载：

基于这样的设计，可以让开发更集中更高效，让云计算更亲和。换句话说，Database Mesh 正在向着扩展性、易用性和标准化的方向大踏步地前进。

这个阶段的 Database Mesh 为 2.0 阶段。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。