蚂蚁金服 DB Mesh 的探索与实践

蚂蚁金服数据访问层有三个核心组件：数据访问框架 ZDAL、数据访问代理 DBP 和 OceanBase 代理服务器 OBProxy。本篇主要涉及 ZDAL 和 OBProxy 两个组件。ZDAL 做为全站数据访问的标准组件，不只提供了分库分表、读写分离、分布式 Sequence等标准的应用能力，还提供了链路跟踪、影子压测、单元化、容灾切换等技术风险能力 。OBProxy 做为 OceanBase 的访问入口，提供了 OceanBase 路由寻址、读写分离等数据库能力，同时从执行效率和资源成本角度考虑，从 OBProxy 诞生那天咱们就采用了近应用的独立进程部署模式，目前生产环境上保持在几十万级别的进程数。

本篇文章经过介绍当前蚂蚁金服数据访问层遇到的问题，解决的思路，演进的方向三个方面，指望可以用阐述下 DB Mesh 发展的一些思考并让更多同窗认识到 DB Mesh。指望可以 DB Mesh 的方式将数据访问层下沉到统一的基础设施之上，让新业务快速使用上蚂蚁金服内部多年的技术风险能力，并可以持续享受到更多的性能、资源等技术红利。

背景
随着业务的快速发展，ZDAL 做为客户端模式的组件，一直存在业务耦合、版本迭代推动、多语言支持等问题。OBProxy 是为 OceanBase 数据库专门量身定制的代理服务器，自然就是业务无耦合、支持多语言。用户的数据在 OceanBase 上以多副本的形式存放在各个 OBServer 上，OBProxy 则负责接收用户发过来的 SQL 请求，解析 SQL 请求并计算分区信息后，将用户请求转发到最佳目标 OBServer 上，并将执行结果给用户。在蚂蚁金服内部也存在分库分表组件 ZDAL，用在多 OceanBase 集群以及单元化的场景。二者配合使用，分库分表组件 ZDAL 作业务层的流量调拨，OceanBase 分区功能支持数据库的水平扩容能力。

咱们进一步看 ZDAL 和 OBProxy 这两个组件的核心逻辑。

ZDAL 的核心逻辑：

SQL 解析器：得到表名及分库分表字段；
规则引擎：计算分库分表结果；
执行层：将 SQL 改写发给数据库，并作结果集合并用户；

OBProxy 的核心逻辑：

协议解析器：解析协议中的 SQL，Parse 后得到表名及分区字段；
路由器：计算分区表所在的 OBServer；
IO 层：将请求转发给 OBServer，将结果集返回给客户端；

能够看出，OBProxy 和 ZDAL 这两个组件的执行路径有必定的重复度，好比两个组件都作了 SQL 解析，并分析表名和字段。这对性能带来必定的损耗，并且这种重复给研发迭代带来更多的工做量。

基于前面的考虑将 ZDAL 和 OBProxy 二者合并成一个组件的是一个天然的方案，经过将 ZDAL 逻辑下沉到 OBProxy 中，让 OBProxy 提供了分库分表、读写分离、分布式序列等中间件能力，这个组件咱们命名为 ODP（Open Database Proxy）。

ODP 做为近业务端部署的进程，虽然逻辑独立出来，升级时可是依然须要去改动业务的容器，因此迭代过程当中的升级推动工做也是比较费时费力，并且 ODP 只是整个产品的冰山一角，须要大量的精力来构建冰山之下的基础设施，好比说如何解决 ODP 的运维问题、用户透明切换的方案、复杂配置的推送问题、金融级数据库密钥管理问题等。咱们发现这部分与蚂蚁金服内部大规模实践的 ServiceMesh 遇到的问题有比较大的重合度，因此与 ServiceMesh 一块儿共建底层基础设施，为这块的完整产品方案命名为 DBMesh。下文会简单介绍一下咱们的演进路线和发展方向。

解决思路
Sidecar 模式以解耦部署

从执行效率和资源成本角度考虑，OBProxy 在蚂蚁金服一直都在采用近业务端部署的方式，平常保有的服务数在数十万的级别。近业务端部署虽然提供了高效率，可是也带来了运维上的复杂度，同时须要升级版本时，也须要和通知业务一块儿来作发布和升级。要让单个应用升级，基本都是按月计，若是涉及到全站层面的升级，时间基本不太好估算。

可是随着云原生以及 Kubernetes 的发展，让 Sidecar 模式更为成熟，即在业务的容器旁边再运行一个容器，这个很是贴合咱们近业务端部署的 OBProxy 进程，只须要将 OBProxy 进程改形成 OBProxy Sidecar，便可进行独立升级、发布、运维等。同时蚂蚁金服在云原生领域有很是深的实践，有着世界上最大规模的 Kubernetes 集群和 ServiceMesh 集群，将 OBProxy 变成 Sidecar 也是比较合理和方便实施的了。

今年双十一切了约 10% 的数万个的 PODs 到 ODP Sidecar 模式，经过 Sidecar 的方式可以让业务快速享受到基础软件迭代的好处，本次双十一 ODP 修复了一个非预期日志打印致使某个机房出现慢 SQL 问题，在传统的本地进程方式，须要推进全部的业务进行拉迭代、发布、打包时间周期基本不太可控。而今年让全部涉及应用独立的灰度、升级仅花费两天时间。

合并重复逻辑拿技术红利

解决了部署模式的问题，经过快速迭代而且独立升级的方式，才能让功能下沉的落地成为可能。咱们将分库分表组件的大多数功能都下沉到了 ODP 上，好比：分库分表功能、读写分离功能、分布式 Sequence 功能、全链路跟踪等。以下图：

整个分库分表组件功能下沉以后，在今年双十一咱们在核心系统上线，拿到了一些很是可观的技术红利：

性能提高：经过功能的合并能够省去额外的 SQL 解析和路由计算过程，双十一上线的系统 SQL 平均响应时间能够降低上百微秒；
启动速度：应用只须要和 ODP 创建链接便可，无需初始化多个分库的数据源，初始化时间从数十秒降到数十毫秒；
内存降低：和启动速度同样，因为应用和 ODP 的链接数减小了，一样也能够节省应用端的内存使用，生产上可以降低上百 MB；

共建 Mesh 基础设施完善技术风险

研发同窗会将更多的关注点放在 ODP 数据链路上，如何提升数据平面的性能，如何增长更多的 SQL 特性，而会忽略非 SQL 执行链路上的诉求。DBMesh 做为应用侧的基础设施，更多的要考虑如何更好的管理 Sidecar、数据访问高安全防控、知足配置变动的三板斧要求、最大程度的节省资源成本等。

咱们在与蚂蚁金服 ServiceMesh 团队共建整个云原生下 Mesh 的技术风险能力，优先完善 Sidecar 的运维能力和变动三板斧能力，后续会将 ODP Sidecar 部署到宿主机上以最大程度优化 ODP 的资源占用，也会逐步下沉更多如影子压测、灰度机房、流量镜像等的技术风险能力。

总结
DBMesh 让数据访问从客户端模式切换到代理模式，给应用带来了启动速度的极大优化。Sidecar 的部署模式则是 SQL 平均响应时间、资源利用的最优模式。将更多的技术风险能力沉淀进来，让新应用快速享受到金融级的技术风险能力，存量应用的技术风险指标更完善。咱们指望经过统一的数据访问基础设施，让业务都使用标准的技术组件，下降学习以及维护成本，仅专一在业务开发和创新上。

做者介绍

易鸿伟（花名：改之），蚂蚁金服高级技术专家，负责数据中间件及 OceanBase 链路层方向的研发工做。主要技术关注在分布式数据库、高性能服务器、数据库高可用、分布式事务、单元化架构等，并对微服务、云原生、Mesh 等技术有必定的理解。

相关阅读

蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题