共计 4736 个字符，预计需要花费 12 分钟才能阅读完成。
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 的将来之路。
01 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 呢？》（https://www.infoq.cn/article/…）是这么描述 Database Mesh 的：
如此一来 Service Mesh 在 Kubernetes 上的 Sidecar 模型实现就变得十分有启发性：如果设计一种 ShardingSphere-Sidecar 模式，将 ShardingSphere 的外围分片能力等迁徙到其中，就能够无效的联合 JDBC 代理端与 Proxy 客户端的长处并屏蔽其毛病，达成“弹性伸缩 + 零侵入 + 去核心，实现了一个真正的云上基础设施”。这个阶段的 Database Mesh 为 1.0 阶段。
任何一个新技术概念在它落地的时候，都会因为不同的业务场景和模式、不同的架构设计模式、不同的基础设施成熟度、乃至差别的工程师文化而打上本人独特的烙印。这一点在 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 阶段。
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，提供多种数据库治理行为形象，实现自动化的数据库可靠性工程；
- 云原生：以凋谢的生态和实现机制适配不同的云环境，面向云原生构建和实现，而无需放心厂商锁定。
这套治理框架依赖于如下工作负载：
- 虚构数据库：开发人员视角里一个能够被拜访的数据库端点
- 流量策略：对数据库拜访流量的治理策略，如分库分表、负载平衡、限流、断路
- 访问控制：依据指定规定提供细粒度的访问控制，如表级别
- 平安申明：数据安全性申明，如数据加密等
- 审计申请：记录利用对数据库的操作行为，如接入风控系统
- 可观测性：数据库的拜访流量、运行状态、性能指标等可观测性的配置
- 事件总线：承受数据变更的事件总线
- QoS 申明：进步数据库整体 SLO 指标而设定的资源 QoS 指标
- 备份打算：按计划工作的形式执行数据库备份
- Schema 流水线：以代码形式治理数据库 schema 变更，进步数据库 DDL 和 DML 变更的成功率
基于这样的设计，能够让开发更集中更高效，让云计算更亲和。换句话说，Database Mesh 正在向着扩展性、易用性和标准化的方向大踏步地后退。
这个阶段的 Database Mesh 为 2.0 阶段。
03 Database Mesh 社区
目前 Database Mesh 官网已上线，相应的标准定义也开源在（https://github.com/database-mesh/database-mesh）仓库里。社区每两周都会进行线上探讨，信息如下：
欢送各位读者退出官网社区进行探讨，Database Mesh 社区欢送来自不同背景的爱好者们一起建设生态。
此外，Database Mesh 发起人张亮所在 SphereEx 公司将于下月推出面向数据库网格的开源解决方案 Pisanix，欢送各位关注！
作者介绍
苗立尧，SphereEx 云研发负责人，开源布道师，专一于 SaaS 和 Database Mesh。2015 年起开始接触 Kubernetes，是国内最早一批云原生实践者，2016 年开办“容器时代”公众号，原创和翻译引进 600 余篇技术文章。曾在株式会社ネットスターズ、北京穿杨科技、蚂蚁金服、易宝领取等负责基础设施架构师、云产品负责人、云原生研发工程师等相干职位。
GitHub：https://github.com/mlycore
张亮，SphereEx 创始人 & CEO，Apache Member，Apache ShardingSphere、ElasticJob PMC Chair，微软 MVP、腾讯云 TVP。
GitHub：https://github.com/terrymanu
欢送点击链接，理解更多内容：
Apache ShardingSphere 官网：https://shardingsphere.apache.org/
Apache ShardingSphere GitHub 地址：https://github.com/apache/shardingsphere
SphereEx 官网：https://www.sphere-ex.com
欢送增加社区经理微信（ss_assistant_1）退出交换群，与泛滥 ShardingSphere 爱好者一起交换。
