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

alan_ham
发布于 2022-10-14 16:25
浏览
0收藏

2018 年 3 月,彼时的 ShardingSphere 刚从原来的 ShardingSphere-JDBC 演化出来可以独立部署的 ShardingSphere-Proxy,它们都采用 Java 构建实现,分别代表了 SDK 模式和 Proxy 模式,提供了相同的标准化数据分片、分布式事务等功能。但无论使用哪种方式,都有其各自的优缺点。项目创始人张亮就在设想是否有一种模式可以有效地结合 JDBC 代理端与 Proxy 客户端的优点并屏蔽其缺点,借助“弹性伸缩 + 零侵入 + 去中心,实现了一个真正的云上基础设施”呢?于是就有了这篇文章:《Service Mesh 是大方向,那 Database Mesh 呢?》(https://www.infoq.cn/article/database-mesh-sharding-jdbc) 。文中是这么描绘 Database Mesh 的:

数据库治理的云原生之道 —— Database Mesh 2.0-鸿蒙开发者社区

01  Database Mesh 1.0 的诞生

 

ervice Mesh 的形态已经基本确定

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

数据库治理的云原生之道 —— Database Mesh 2.0-鸿蒙开发者社区

如此一来 Service Mesh 在 Kubernetes 上的 Sidecar 模型实现就变得非常有启发性:如果设计一种 ShardingSphere-Sidecar 模式,将 ShardingSphere 的核心分片能力等迁移到其中,就可以有效的结合 JDBC 代理端与 Proxy 客户端的优点并屏蔽其缺点,达成“弹性伸缩 + 零侵入 + 去中心,实现了一个真正的云上基础设施”。这个阶段的 Database Mesh 为 1.0 阶段。

 

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

 

在 Database Mesh 1.0 诞生的这些年里,一些公司在原有基础上丰富了更多观点,比如在 Service Mesh 的框架中,通过二次开发的方式增加了对 SQL 协议的解析和支持,增强了数据库流量治理能力,兼容了统一的服务治理配置;比如将 Database Mesh 的理念集成到一套完整的中间件服务框架中,以 SDK 或者 Sidecar 的方式给业务应用暴露统一的访问方式,简化开发者的使用;还比如将分布式事务能力集成到 Database Mesh Sidecar 中的项目,以云原生分布式数据库的方式为业务应用进行呈现。不管是哪种方式,都可以看出来 Database Mesh 理念正在不断深入人心,逐步成长为一个繁荣的生态。

数据库治理的云原生之道 —— Database Mesh 2.0-鸿蒙开发者社区

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

 

02  Database Mesh 2.0 介绍

 

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

 

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

 

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

 

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

 

Database Mesh 从 1.0 开始,始终关注对数据库流量的治理,基于数据库协议感知能力,提供数据分片、负载均衡、可观测性、审计等能力。这些能力已经解决了数据库治理中属于流量治理的部分问题。但对运维人员和数据库管理人员来说,还有很多可以持续建设的方面。比如是否可以通过统一的配置声明数据库接入?是否可以通过可编程的方式,实现对数据库访问的资源限制?是否可以通过标准的界面自动化数据库维护体验?

 

在不同的用户视角里,开发人员更关注运行效率、成本开销,以及数据库协议类型和访问信息,不关心数据存储的位置。运维和 DBA 更关注数据库服务的自动化、稳定性、安全性、监控报警等,此外 DBA 还会关心数据的变更、容量、安全访问、备份、迁移等等。这些问题都属于数据库可靠性工程的范畴。

 

正是随着对数据库治理场景的深入理解和对用户体验的极致追求,共同催生了 Database Mesh 2.0:通过可编程实现高性能扩展,应对云上数据库治理挑战。

 

Database Mesh 2.0 的目标

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

 

●  进一步减轻开发人员的心智负担,提高开发效率,提供透明和无感的数据库基础设施使用体验;

●  以可配置、可插拔、可编程的方式,实现一个覆盖数据库流量、运行时资源和稳定性保障等方面的治理框架;

●  为异构数据源、云原生数据库、分布式数据库等多个数据库领域的典型场景提供标准的使用界面。

开发者体验

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

 

可编程

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

 

标准界面

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

 

Database Mesh 2.0 治理框架

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

 

●  数据库是一等公民:一切抽象都围绕数据库治理行为进行,比如访问控制、流量治理、可观测性等;

●  面向工程师体验:对于开发人员,通过便捷易用的数据库声明和定义,即可继续进行开发,无需关心数据库的位置;对于运维和 DBA,提供多种数据库治理行为抽象,实现自动化的数据库可靠性工程;

●  云原生:以开放的生态和实现机制适配不同的云环境,面向云原生构建和实现,而无需担心厂商锁定。

数据库治理的云原生之道 —— Database Mesh 2.0-鸿蒙开发者社区

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

 

●  虚拟数据库:开发人员视角里一个可以被访问的数据库端点

●  流量策略:对数据库访问流量的治理策略,如分库分表、负载均衡、限流、断路

●  访问控制:根据指定规则提供细粒度的访问控制,如表级别

●  安全声明:数据安全性声明,如数据加密等

●  审计申请:记录应用对数据库的操作行为,如接入风控系统

●  可观测性:数据库的访问流量、运行状态、性能指标等可观测性的配置

●  事件总线:接受数据变更的事件总线

●  QoS 声明:提高数据库整体 SLO 指标而设定的资源 QoS 指标

●  备份计划:按计划任务的方式执行数据库备份

●  Schema 流水线:以代码方式管理数据库 schema 变更,提高数据库 DDL 和 DML 变更的成功率

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

 

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

 

03  ShardingSphere 的新思路

 

ShardingSphere 遵循着 Database Plus 的科学设计,追求在碎片化的异构数据库上层构建生态,在最大限度复用数据库原生存算能力的前提下,进一步提供面向全局的扩展和叠加计算能力。

而在 Database Mesh 的视角里,ShardingSphere 和一款高性能的分布式数据库并无二致,可以同样被纳入到 Database Mesh 的治理框架中,进一步减轻开发人员和 DBA 的负担。

 

在这个场景里,Database Plus 关注后端数据侧,Database Mesh 面向前端的流量侧,二者结合刚好构成一个完整的数据库治理矩阵,让整个基础架构变得更加统一和标准化,更加易于管理,从底座自下而上赋能,最大化助力业务发展。

 

04  Database Mesh 社区

 

目前 Database Mesh 官网(https://www.database-mesh.io)已上线,相应的规范定义也开源在(https://github.com/database-mesh/database-mesh)仓库里。社区每两周都会进行线上讨论,信息如下:

数据库治理的云原生之道 —— Database Mesh 2.0-鸿蒙开发者社区

欢迎各位读者加入官方社区进行讨论,Database Mesh 社区欢迎来自不同背景的爱好者们一起建设生态。

 

此外,Database Mesh 发起人张亮所在 SphereEx 公司将于下月推出面向数据库网格的开源解决方案 Pisanix(https://www.pisanix.io),欢迎各位关注!

 

文章转载自公众号:ShardingSphere官微

分类
已于2022-10-14 16:47:38修改
收藏
回复
举报
回复
    相关推荐