Chinaunix首页 | 论坛 | 博客
  • 博客访问: 433509
  • 博文数量: 115
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1839
  • 用 户 组: 普通用户
  • 注册时间: 2019-01-07 13:17
个人简介

蚂蚁金服技术团队

文章分类

全部博文(115)

文章存档

2020年(9)

2019年(106)

我的朋友

分类: IT职场

2019-12-18 09:36:35

蚂蚁金服数据访问层有三个核心组件:数据访问框架 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 等技术有一定的理解。

相关阅读


阅读(4794) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册