蚂蚁金服天街：OceanBase 在大促 5 年来的技术演进
为了与金融从业者、科技从业者共同探讨金融 + 业务的深层次问题，蚂蚁金服联手 TGO 鲲鹏会，在 12 月 8 日举办了「走进蚂蚁金服：双十一背后的蚂蚁金服技术支持」活动。蚂蚁金服高级技术专家天街为大家分享了《蚂蚁双 11 大促 OceanBase 核心技术全解析》。本文根据当天演讲整理，有部分不改变原意的删减。
天街现场演讲照片
今天给大家介绍一下 OceanBase 在大促 5 年来的技术演进，主要内容是 OceanBase 大促体系，下文简称 OB。今年 OB 大促上有三个核心技术：百万支付、容器化和平台智能化。
OB 大促主要做什么事情？大促就是把平常的能力在双 11 舞台上做最大的展示。大促的内容很多，落到技术层面就是整个体系的分析，我们可以把它抽象出六个能力：
容量。面对这种脉冲式的压力上升，我们可以从单机性能和集群性能量方面来考虑满足大促容量；
可靠性。作为金融级公司，我们在峰值上要保持脉冲风险稳定可靠；
成本。日常使用的机器与双 11 相比非常少，需要降低大促使用的机器成本；
效率。大促是常态化的流程，一年之中会有很多大促，要用最高的效率来实现大促，这是成败的关键；
抗压。用压测试保证各方面的系统满足双 11 的峰值；
弹性。这是双 11 最核心的技术，需要把应用服务器、DB 各种计算能力都弹到一个新的单元上，利用这部分资源支撑大促，同时在大促之后快速还回来。
上图是 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 打造百万支付能力的优势：
弹性伸缩。分片可以无限 sharding，实现线性扩展，并且每一个分片都具备独立的扩展能力，可以满足多元化的弹性需求；
业务无感无损。无感是指业务感觉不到 DB 的伸缩，外部公司如果想要做一个大促活动，不需要业务感知，直接由 DB 完成。无损是指整个弹性过程中业务不会有失败，因为这是通过我们的协议来实现的；
极致高可用。通过灰度做到不同分片之间互相隔离，并且可低版本和高版本同时运行，如果一个分片一个星期没有问题，就可以自动对下一个版本进行处理；
资源。我们可以把一个在高峰期占有很大资源的数据源拆成一个非常统一的资源粒度，它的好处就是可以很独立地做负载均衡。
我们做容器化有两方面原因：第一，常态；第二，大促。
常态会面临什么样的问题？现在 DB 服务器有几万台，如果对资源进行深入统计，就会发现 DB 资源肯定是过剩的。DB 资源无非就是 CPU、IO、内存，一个数据库不可能这三类都占满。我们做一个简单的统计，大促时所有的服务器的瓶颈是 CPU，而日常的瓶颈是存储空间，绝对不会是 CPU。另外，业务状态注定存在高峰 / 低峰访问。资源负载分为长尾、碎片两类，我们需要把碎片收集起来再利用。资源分为绝对资源和相对资源，在不同业务间它们的比例差距很大，在现在的支付宝规模下使用的资源浪费很大。我们每年采用的机型都有很大的变化，现在 CPU 越来越多、内存越来越多，CPU 也有换代更新，所以针对异构的机型要把能力统一标准化，提供统一的服务能力。
而大促态的成本体现在哪里？第一，大促所需服务器总数；第二，持有服务器的时长。如果使用一千台服务器，持有一个月，资源开销远远大于持有两千台服务器五小时，这涉及到服务器运营。
这些问题就对 DB 提出了要求，DB 要有容器化的能力，目的是要调度 DB，把它放在我们想要的地方。
我们做的容器化主要有三点：
规格归一。分区是一种方案，还有一种方案是业务拆分，比如把一些明显不合理的长尾业务进行拆分，我们会把线上所有的 DB 顺序分为五个可以满足需求的规格，比如 2C8G、8C32G。我们做容器化的时候，只要是这五种规格就可以；
资源隔离 / 抢占，这是一个重点，因为容器化的目的是保证系统的正常运行，不要因为成本丢弃系统的稳定性。这里有三大块：CPU、内存和 IO 通过 Cgroup 隔离，同时结合应用画像，比如根据这个业务过去三个月的增长情况、存储空间，做一个容器画像，打上业务属性的标签，比如关键点的地域信息、资源信息；
多维调度，应用、机房、机架的调度。在 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 鲲鹏会会员右军一起学习交流吗？