口述 | 天街

责编 | Rainie Liu

为了与金融从业者、科技从业者共同探讨金融 + 业务的深层次问题，蚂蚁金服联手 TGO 鲲鹏会，在 12 月 8 日举办了「走进蚂蚁金服：双十一背后的蚂蚁金服技术支持」活动。蚂蚁金服高级技术专家天街为大家分享了《蚂蚁双 11 大促 OceanBase 核心技术全解析》。本文根据当天演讲整理，有部分不改变原意的删减。

天街现场演讲照片

今天给大家介绍一下 OceanBase 在大促 5 年来的技术演进，主要内容是 OceanBase 大促体系，下文简称 OB。今年 OB 大促上有三个核心技术：百万支付、容器化和平台智能化。

OB 大促主要做什么事情？大促就是把平常的能力在双 11 舞台上做最大的展示。大促的内容很多，落到技术层面就是整个体系的分析，我们可以把它抽象出六个能力：

上图是 OB 这几年在大促上的弹性化体系，分为四层：

1、基础设施。今年大促的基础设施是网络、存储计算的介质、底层与内核的交互、网络互联。

2、基础架构。这是底层对业务可见的基础部署，我们把业务放到容器里，上面是业务可见的架构，有独立的异构 FO 和同城三级房部署。为了弹性的效率，我们还做了多副本的架构，比如传统的主库、备库以及最近两年新加的日志节点。

3、能力沉淀。大促需要的能力和日常需要的能力相辅相成，如果日常就具备这样的能力，那么大促时就能从容应对。

4、大促服务。我们今年双 11 做了 4 万 + 的变更，实际上是通过 AutoScale 平台做的，同时我们也会结合稳定性的要求，比如变更三把斧，把这些能力做进去。

我们的三年战略是百万支付，经测算三年之内交付峰值将达到一百万。因为应用是无状态的，只要我们在整个系统上做到可扩容、可弹性，把机器加上去就可以解决。但是 DB 端不行，一份数据所能够使用的存储空间和很多东西相关，比如业务方的分表、单机的性能都有一定的瓶颈，百万支付落到 DB 端最核心的问题就是怎么解决最小的数据分片，解决资源规格异构和负载均衡偏差的资源问题。

这个图代表了当前支付宝架构的解决方案。右边 00 代表一个分片，全中国路由出来是 UID 的 00。支付事务跨多张表，每一张表对应的多个分片，我们会把它聚合在一起，代表一个实例或者租户，一个租户使用的最大资源是物理机的资源。如果想要把 00 继续拆分，就把 00 分片再取两位做哈希。对新的业务通过弹性规则，访问对应的库。这样业务改造的工作量很大，因为要加四个数据库，并且加了之后没有办法回收。而且伸缩是有损的，因为要缩小服务器资源必然涉及到大量数据的缩容，那么应用就会感知到。

基于这些，我们提出了 OB2.0。这个项目最大的价值是做到 OB 分区，就是可以把一个应用维度看成一个数据分片，可以在 DB 端做到无限度的 sharding。我们通过 Partition Group 的概念，把不同表格相同分区聚合到相同的机器，同时还把任意一个分片结合物理机的数目进行二次聚合，聚合成大的 Partition Group，根据 server 数的不同，自动把分片分到不同的机器上，这就是百万支付结合 OB2.0 的架构。

OB2.0 打造百万支付能力的优势：

我们做容器化有两方面原因：第一，常态；第二，大促。

常态会面临什么样的问题？现在 DB 服务器有几万台，如果对资源进行深入统计，就会发现 DB 资源肯定是过剩的。DB 资源无非就是 CPU、IO、内存，一个数据库不可能这三类都占满。我们做一个简单的统计，大促时所有的服务器的瓶颈是 CPU，而日常的瓶颈是存储空间，绝对不会是 CPU。另外，业务状态注定存在高峰 / 低峰访问。资源负载分为长尾、碎片两类，我们需要把碎片收集起来再利用。资源分为绝对资源和相对资源，在不同业务间它们的比例差距很大，在现在的支付宝规模下使用的资源浪费很大。我们每年采用的机型都有很大的变化，现在 CPU 越来越多、内存越来越多，CPU 也有换代更新，所以针对异构的机型要把能力统一标准化，提供统一的服务能力。

而大促态的成本体现在哪里？第一，大促所需服务器总数；第二，持有服务器的时长。如果使用一千台服务器，持有一个月，资源开销远远大于持有两千台服务器五小时，这涉及到服务器运营。

这些问题就对 DB 提出了要求，DB 要有容器化的能力，目的是要调度 DB，把它放在我们想要的地方。

我们做的容器化主要有三点：

这是 OB 大促容器化的架构。底层是通用的调度平台，要识别各种 IaaS，包括蚂蚁、金融云、阿里云、混合云。再往上是统一的调度层：一层是 sigma，主要做统一资源规划、资源生命周期、资源弹性、资源规划；二层调度层分为 kipp 和 OB，按照不同租户的画像信息，得出调度策略是平铺、抢占还是资源亲和（资源亲是指，单机不超过 1% 的容灾，通过资源亲和，把一笔支付链路上所能够经过所有的应用和 DB 统一调度在同一台机器上，通过一个亲和性标签放在一起，大大降低宕机的影响面）；右边是调度管控，包含水位、资源 Plan 和资源标签；最上层是容器化达到的价值，首先是资源利用率，第二是单机 1% 容灾，第三是无损压测，第四是存区 & 存储就近，让存储节点和计算节点两者离得最近、网络和 IO 离得最近。

为什么要做平台智能化？第一是大促常态化。往年支付宝只有两个活动：双 11、双 12，但是现在每个月都有三四个大促，大促的稳定性要求很高，那怎么把活动支持得更好呢？传统上是做简单的扩容，做一些预案，但现在会发现光做这些不够了，我建议通过智能化的手段解决。可以把流程抽出来，结合最小的集群智能化，两者有机结合实现根本目标。第二是随着业务规模爆发，怎么解决硬件存在的隐患，怎么解决 10w+ 机器操作系统从 6U 升级到 7U。第三是稳定性，我们要做到 5 个 9，换算出来也就是全年停服不能超过 60 分钟。要到达到这个目标，任何的应急措施都不能依赖于人，也不能通过指令触发，必须通过智能。

介绍一下 OB 在大促智能化上的实践，主要有两点：第一，自动扩缩容；第二，SQL 调优。我们首先会对链路信息和 DB 运行状态进行建模，从应用服务器中间件数据源清洗出来链路信息，从 CPU、IO 各方面对每一条链路的 DB 节点进行数据拟合，得到拟合线后，通过指标的输入，推测在这个压力下 DB 的水位会产生什么样的波动或者峰值，从而可以把每一个业务的容量信息、每一个租户信息刻划出来，结合调度做一些智能的 rebalance；第二是 SQL 调优，我们会监控每一条 SQL 的状态，比如这一条 SQL 的使用概率、任意资源的消耗情况，给出 SQL 调优的建议。

第三是压测的资源预测和垄断。如果预测在接下来三分钟之内内存会占满，就自动停止掉。如果预测到 RT 水位对于业务来说是超时的，就停止自动压测。

我们把稳定性做到 5 个 9，分成三个模块：第一，感知，我们会对各种 workload 建模，形成非常丰富的曲线，通过曲线得出模型归纳和预测变化；第二，决策，第一个方法是基于经验，形成每一个数，每一个数的子节点是上一个节点的原因分析，往下是它的根因；第二个方法是机器学习，这是自我认知的过程，我们会把这些经验做输入，通过演进和优化不断得出最佳的决策树；第三，执行器，我们会对上一层信息进行更新阶段，根据诊断得出需要执行的方案，比如需要调优、扩容、还是修复。

OB 结合大促场景下的未来规划主要有两个方面：

资源。资源是我们做大促的核心价值，用最小的资源解决用户最大的问题。第一，统一调度。不仅仅是 DB 端的统一调度，我们还要把用户服务器、各种机型、资源池全部打通，这样就有了更大的池子，技术可发挥的空间更大；第二，混合部署。统一部署之后会分池分布、分类混布；第三，分时复用。混布和分时复用的效率体现很明显，因为不需要做大促处理时候可以节省资源开销；

自治。第一是 OB 内核的自治，第二是平台化的自治。自治分为三块：

贾岛：蚂蚁金服亿级并发下的移动端到端网络接入架构解析

你想与蚂蚁金服高级技术专家 & TGO 鲲鹏会会员右军一起学习交流吗？