数据库网格Database Mesh概要介绍.docx

数据库网格Database Mesh概要介绍在微服务和云原生大潮的卷席之下，服务化一直以来是人们关注的重点。但服务化之后，真正绕不开的数据访问却鲜有论道。尽管目前的关系型数据库远达不到云原生的要求，并且对分布式的不友好在长期以来也饱受诟病，但不可否置的是，关系型数据库至今依然扮演着极其重要的角色。从其本身以及周边生态圈的成熟度、数据查询的灵活度、开发工程师以及 DBA 对其的掌控程度以及招聘到适合人员的难易度等方面来看，无论是 NoSQL 还是 NewSQL，实难于在近期完全取而代之。那么，对于微服务架构中越来越多的数据库垂直拆分，以及数据量急剧膨胀后的数据库水平拆分，是否存在行之有效的方案来管理呢？当今大为流行的 Service Mesh 理念又能否对数据库的治理带来一些启示呢？Database Mesh Database Mesh，一个搭乘 Service Mesh 浪潮衍生出来的新兴词汇。顾名思义，Database Mesh 使用一个啮合层，将散落在系统各个角落中的数据库统一治理起来。通过啮合层集中在一起的应用与数据库之间的交互网络，就像蜘蛛网一样复杂而有序。从这一点来看，Database Mesh 的概念与 Service Mesh 如出一辙。之所以称其为 Database Mesh，而非 Data Mesh，是因为它的首要目标并非啮合存储于数据库中的数据，而是啮合应用与数据库间的交互。Database Mesh 的关注重点在于如何将分布式的数据访问应用与数据库有机串联起来，它更加关注的是交互，是将杂乱无章的应用与数据库之间的交互有效的梳理。使用 Database Mesh，访问数据库的应用和数据库终将形成一个巨大的网格体系，应用和数据库只需在网格体系中对号入座即可，它们都是被啮合层所治理的对象。Service Mesh 回顾 服务治理主要关注服务发现、负载均衡、动态路由、降级熔断、调用链路以及 SLA 采集等非功能性需求。通常来说，可以通过代理端和客户端这两种架构方案实现。代理端的方案是基于网关的。提供服务的应用服务器被隐藏在网关之后，访问请求必须经由网关，由网关进行相应的服务治理动作后，再将流量路由至后端应用。Nginx、Kong、Kubernetes Ingress 等采用此类方案。客户端的方案则是由部署在应用端的类库进行相应的服务治理动作，并以点对点的方式访问服务提供者。Dubbo、Spring Cloud 等采用此种方案。无论使用代理端还是客户端进行服务治理，都有其各自的优缺点。在代理端进行服务治理的优点是应用只需获取网关地址即可，后端的复杂部署结构被完全屏蔽。缺点则是代理端自身的性能和可用性是整个系统的瓶颈，一旦宕机后果较为严重。其中心化架构理念，与云原生背道而驰。在客户端进行服务治理的优点是使用无中心化架构，无需担心某个节点成为系统瓶颈。缺点则是服务治理对业务代码的侵入。对于云原生所看重的零侵入来说，使用客户端进行服务治理的方式显然是不可行的。客户端治理的方案更无法做到对异构语言的支持。在既希望零入侵、又需要无中心的云原生架构下，第三种架构模型——Sidecar 则显得更加契合。Sidecar 以一个独立的进程启动，可以每台宿主机共用同一个 Sidecar 进程，也可以每个应用独占一个 Sidecar 进程。所有的服务治理功能，都由 Sidecar 接管，应用的对外访问仅需要访问 Sidecar 即可。显而易见，基于 Sidecar 模式的 Service Mesh 才是云原生架构的更好的实现方式，零侵入和无中心化使得 Service Mesh 倍受推崇。尤其是配合 Mesos 或 Kubernetes 一起使用时，通过 Marathon 或 DeamonSet 确保 Sidecar 在每个宿主机都能够启动，再配合其对容器的动态调度能力，能发挥更大的威力。Kubernetes（Mesos） + Service Mesh = 弹性伸缩 + 零侵入 + 无中心，它们合力完成了一个云端所需的基础设施。Database Mesh 与 Service Mesh 的异同 数据库应用治理与服务治理的目标既有重叠，又有所不同。相比于服务，数据库是有状态的，无法像服务一样随意路由到对等节点，因此数据分片是一个重要的能力。相对来说，数据库实例的自动发现能力则不那么重要，原因也是数据库的有状态性，启动或停止一个新的数据库实例，往往意味着数据迁移。当然也可以采用多数据副本、读写分离、主库多写等方式进行进一步的处理。其他功能诸如对多从库的负载均衡、熔断、链路采集等，在数据库治理中也同样适用。与服务治理一样，对数据库应用的治理同样可以套用这三种架构方案。基于代理端的解决方案是使用一个实现相应数据库通信协议（如 MySQL）的代理服务