浅谈Database Mesh及未来

Database Mesh，这一概念是由开源软件shardingsphere的作者张亮，最早于2018年提出的。其含义是Database Mesh 使用一个啮合层，将散落在系统各个角落中的数据库统一治理起来。通过啮合层集中在一起的应用与数据库之间的交互网络，就像蜘蛛网一样复杂而有序。这一技术关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。目前这一技术还处于相对早期阶段，只有个别企业有所实践。本文后面将谈谈我对这一技术问题的理解。

1. 服务网格：Service Mesh

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

在我们开始讨论Database Mesh之前，让我们先来看看更为大家所熟知的Service Mesh。前者也正是从这一概念衍生而的。所谓Service Mesh，即服务网格，它是一个专有的基础设施层。其基本的理念是在服务间插入一个代理组成的网络来实现对网络层的抽象。进而可以使得微服务架构内部的服务间通信更加可靠、快捷和安全；帮助开发者解决微服务间的交互挑战。

下面以一个比较火的服务网格的开源项目-Istio，看看Service Mesh的实现机理。Istio是一个由谷歌、IBM与Lyft共同开发的开源项目，旨在提供一种统一的、安全的、可管理、可监控的微服务连接方式。下图是Istio的架构图：

从大的方面来看，整个架构分为两个平面：数据平面、控制平面。其中上半部分的数据平台，主要由Proxy组件构成；下半部分为控制平面，主要由Mixer、Pilot、Galley、Citadel组件组成。前者可高效转发流量，实现服务发现、负载均衡、安全传输、多协议支持、断路器、健康检查、分流路由、故障注入、系统度量等能力，后者则提供数据全局视角的配置管理能力。将上述组件抽象，可得到Service Mesh的典型结构：

上面的核心为由Sidecar代理（后面会谈到）形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。数据平面扮演了一个用来建立、保护和控制通过网格的流量的角色。而对应的负责数据平面如何执行的管理组件称为控制平面。控制平面是服务网格的大脑，并为网格使用人员提供公开API，以便较容易地操纵网络行为。业务应用系统，只需要跟部署在同一机器或Pod内的SideCar代理互相访问，即可实现上面微服务环境所依赖的诸多治理服务。

❖ 服务网格优势

那么为什么服务网格技术有利于解决微服务治理上面的多种问题呢？

之前对于微服务的治理能力往往都是构建在应用程序本身内（如左图），这里面包含了流量管理、熔断、重试、客户端负载均衡、安全以及可观测性等等。随着我们对治理功能的要求不断提高，相应这部分代码逻辑也需要不断增强。但这里就面临一个问题，即即使我的应用逻辑没有任何改变，为了配合服务治理能力的需求还是需要不断改变整个应用。伴随着应用的增长、业务的复杂，上述服务治理功能也将变得很复杂。这是一个朴素的想法就是解耦，即将服务治理能力与应用程序间解耦合。通过上图右侧的方式，将服务治理能力SideCar化。这些SideCar能力不需要依赖于某种特定技术框架，可支持多种编程语言。原本需要在代码库中实现的服务治理功能被抽象化为一个个通用组件,并被逐渐地下沉到代理中。这些服务治理能力的标准化、统一化，可以解决复杂系统微服务实现中面临的差异大、缺少共性的问题，可以很好地支持不同的编程语言、不同的框架。通过把应用服务通信能力抽象下沉到基础设施, 使得开发人员可以更加聚焦于业务应用本身开发,而让基础设施来提供这些通用的能力。

2. 数据库服务网格：Database Mesh

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

与Service Mesh类似，微服务需要治理，数据库应用同样需要。其基本治理能力所包含的数据库发现、访问路由、数据分片、读写分离、负载均衡、熔断、链路采集、可观测性等等。为达到上述能力，一般都是通过何种方式实现的？常见的有两种：Client模式和Proxy模式。前者是一种客户端模式，其优点是无中心化架构，缺点是无法支持异构语言。后者是一种能代理端模式，优点是异构语言的支持，缺点依然是中心化架构。显然上述两种模式，都存在一定的问题，进而对应的SideCar模式也就顺理成章。下图是摘自ShardingSphere对database Mesh实现的一个构想。

业务代码通过Service Mesh的SideCar访问Database Mesh的SideCar，进而访问数据库集群。而对于管理端，则仍可以使用Proxy模式，通过伪装数据库的方式直接通过访问。那么针对这三种模式，ShardingSphere也做了对比，由下图可见SideCar方式在多方面占优。

此外，作为云原生部署实践，Sidecar 是随着宿主机的生命周期创建和消亡的，是完全动态和弹性的存在。伴随着应用的弹性能力同步提供对应的弹性能力。相信随着云原生以及 Kubernetes 的发展，让 Sidecar 模式更为成熟。其带来的收益，从执行效率、资源成本、管理易用、性能提升等方面均能获益。也期望通过统一的数据库服务网格，让业务都使用标准的技术组件，降低学习以及维护成本，仅专注在业务开发及创新。

3. 数据服务网格：Data Mesh

人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。

同样的道理，如果在对数据库服务治理能力上，可通过SideCar方式来满足未来需求。那推而广之，是否可将对数据服务治理能力，也通过同样的方式解决呢？从基本的元数据获取、数据质量保证、数据存储与加工、基础架构与建模等等。下图是摘自国际数据管理协会DAMA2最新数据管理总结。下述所列功能域，都是可能潜在的治理方向。如果说Service Mesh的核心是”流量”、Database Mesh的核心是”连接”，那么如果说Data Mesh可抽象出数据服务的基本要素是否也可行呢？例如统一的数据访问语言SQL…