蚂蚁金服 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 平均响应时间、资源利用的最优模式。将更多的技术风险能力沉淀进来，让新应用快速享受到金融级的技术风险能力，存量应用的技术风险指标更完善。我们期望通过统一的数据访问基础设施，让业务都使用标准的技术组件，降低学习以及维护成本，仅专注在业务开发和创新上。