简介：第十一届中国数据库技术大会（DTCC2020），在北京隆重召开。大会以“架构变革 高效可控”为主题，重点围绕数据架构、AI 与大数据、传统企业数据库实际和国产开源数据库等内容开展分享和探讨。在数据库智能运维专场上，邀请了阿里云数据库高级技术专家王涛为大家介绍阿里巴巴电商数据库上云的抉择、思考与实际。阿里巴巴电商数据库原先是在本人独立的 IDC 保护的，随同着阿里巴巴上云我的项目，数据库轻松实现上云。阿里云云原生管控以及云原生数据库技术能够帮忙业务实现平滑上云指标，进而实现资源最大化老本最优化的指标。阿里巴巴心愿利用阿里云的技术体系，帮忙客户大规模上云，打造本人的运维管控平台。

演讲嘉宾简介：

王涛，阿里云数据库高级技术专家，来自阿里云数据库产品事业部，喜爱并酷爱数据库。
职业生涯：程序员 ->DBA->DevOps 架构师。2007 年开始参加、设计、主导了阿里巴巴数据库体系演进，主导参加了阿里巴巴数据库体系演进，经验了数据库去 IOE，规模化 MySQL 运维，阿里数据库异地多活，数据库上云等多个外围我的项目。目前为阿里云 RDS 管控负责人，为大家提供平安、稳固、经济、智能的数据库服务。

本次分享次要围绕以下四个方面：
一、阿里巴巴电商数据库利用场景介绍
二、数据库管控平台演进
三、数据库上云的抉择与思考
四、将来瞻望

一、阿里巴巴电商数据库利用场景介绍

1. 阿里业务个性介绍 —— RDS 三节点企业版

什么是阿里巴巴电商数据呢？大家看到的淘宝、天猫、盒马、饿了么上的数据都属于阿里巴巴电商数据，这些业务说应用的数据库目前都在云上。阿里巴巴之前的数据库是 RDS 高可用版，采纳一主多备模式，然而发现实例无奈做到 RPO 为零。尝试应用了 MySQL 半同步等措施，但仍然无奈解决 RPO 为零的问题。其次是思考采取 CAP 实践或者 BASE 实践的问题。CAP 指的是一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。但事实上数据库是无奈做到同时满足 CAP 中的三点个性的，只能满足其中一到两项。对于 BASE 实践大家或者不太熟悉，其外围在于能够做到两头不统一，A 和 B 机器可能独自的时候不统一，然而一旦连上之后就会统一。数据管控零碎上通常恪守 BASE 实践，数据库更多的时候是抉择 CAP 原理。解决 RPO 等于 0 的问题有几种实现形式，首先是 MySQL 半同步、还有 MySQL Group Replication，这是 MySQL 5.7 版本之后推出的新性能，然而要求三份数据一样，这个老本是无奈承受的。因而阿里逐步走向了 RDS 自研的方向。

阿里巴巴在抉择数据库协定也是在 Paxos 协定 or Raft 协定中彷徨，最终抉择了 Paxos 协定。

阿里巴巴在抉择数据库协定也是在 Paxos 协定 or Raft 协定中彷徨，最终抉择了 Paxos 协定。Why Paxos，No Raft? 从下图右侧能够看到后面都在提交数据 X、前面来了数据 Y，在 S3 中先执行了 P3.1，P4.5，A4.5 Y，这意味着 Paxos 协定不肯定要有序，而 Raft 是有序的。Raft 协定会要求 S3 先执行 P3.1、A 3.1 X 而后再执行 P4.5，A 4.5 Y。这是 Paxos 协定和 Raft 协定最大的不同。其次，Paxos 协定有三种角色，提交者（Propose），接收者（Accept）以及 Learn。阿里巴巴自研的 RDS 对这三种角色进行了转化，Propose 叫做 Leader，指的是可读可写的数据库节点，Accept 叫做 Follower，多数派，有全量的数据，能够将本人变成 Leader。还有 Logger（阿里自研角色），只负责接管日志，没有数据。Leader 和 Follower 有全量数据，Logger 只是日志接管节点，如此 CPU 和内存老本就会升高。Learn 叫做 Learner，属于观察者角色，有全量数据但没有投票权，即便 Learner 挂掉，也不会影响 Learner 少数提交。

2. 阿里业务个性介绍 —— 异地多活

家喻户晓，阿里巴巴的业务还有一个个性，就是异地多活。异地多活有两点益处，都是能够具备 Region 级别逃逸能力，用户能够在任意单元进行交易。下图右侧是 User 通过规定分流，在数据中心及其它单元都能够进行交易。异地多活能够做到程度扩大和异地容灾，在每年的双 11 能够长期建设站点，在 9 月份建好，在双 11 之后 2 周撤掉。

3. 阿里业务个性介绍 —— 数据库异地多写

那么 RDS 如何应答异地多活？异地多活意味着异地多写。下图展现了反对异地多活的数据库散布状况，首先要有一个核心 DB，对应多个核心环境，别离是交易、购物车、商品等。核心数据库写的数据会到对应的 Store，Store 能够防止调多个线程时影响数据库性能的问题。Writer 负责将数据写到对应的单元 DB。单元 DB 中的数据通过 Store 回到核心的 Writer，回到核心 DB。能够发现数据的 push 出现星状，而不是网状，这是出于几点思考，首先很难做 DTL，大家都在做 DTL，很容易被复制；其次，星状构造能够至多保障一个节点数据是全局统一的，哪怕单元 DB 挂掉，在核心 DB 中也有全量数据。

4. 阿里业务个性介绍 —— 数据库异地只读

阿里业务个性使得数据库须要有反对异地只读的个性。Learner 节点，具备全量数据，不影响 Paxos 协定，每个 Learner 节点都要灾备节点。基于数据库原生复制一致性高。要保障 MySQL 外部数据的一致性。因而数据库架构会如下图右侧所示，核心有三种节点：Follower、Logger、Learner，它们之间能够相互切换。每个单元有 Learner 节点和备用的 Learner 节点，单元利用也在单元 Learner 中。假如要做一级容灾，那么能够将单元写权重路由到核心，通过核心再 Put 到各个单元中，如此不仅能够做的全局一致性还能够做到异地多写。

二、数据库管控平台演进

1. 数据库管控平台定义

大家往往会误以为做数据库管控就是做数据库运维，但事实上并不是那么简略。数据库管控要做的事件有十分多：
首先，数据库高可用是独立的模块，业界罕用的有 HA 策略；数据备份，业界有备份策略，如全量备份、日志备份、数据轨迹备份等；数据库运维包含实例创立、实例变更、实例销毁、备库重大搭等；建设基础设施，如 IDC、服务器选型、硬件运维、CMDB；数据库监控链路和数据告警链路两个不同的模块；还有数据库的计量计费；资源调度；控制台；数据库底层服务，如网关、服务发现等；数据库安全；智能数据库，如数据库智能诊断、数据库智能调参、性能调优等，也是目前次要的一个模块；数据巡检，如配置、参数、状态巡检；网络管理；故障演练；异地多活等等。

能够发现，即便粗略的列举完数据库管控平台蕴含的内容，也会十分多的模块，这导致平台的系统性、复杂性都很高，因为对数据库的依赖性很高，必然造成对其可用性的要求的晋升。那么这些要求应该如何满足？

2. 阿里巴巴数据库管控平台演进

阿里巴巴的数据库管控平台也是经验了若干代前辈的致力：
1) 2003 年，过后并没有 DBA 这个职业。阿里从 SA（系统管理员）团队拆出了一位同学做 DBA，属于纯人工运维。
2) 2006 年，开始应用业界风行的 Nagios、Cacti 等开源工具。
3) 2009 年，阿里开始自研，自主研发了第一代运维零碎“北斗”，替换了 Nagios、Cacti 等开源工具。
4) 2010 年，阿里巴巴开始进行去 IOE 工作，减速了管控的规模化运维，阿里第一代 MySQL 运维零碎诞生，“天机”。次要面向监控、可用性、备份。属于单体利用。
5) 2013 年，随着业务规模不断扩大，阿里第二代 MySQL 运维零碎诞生，“DBFree”。次要面向自动化运维。
6) 2016 年，阿里第三代数据库运维零碎“DBPaaS”诞生，满足异地多活、混合云等业务需要。
7) 2018 年，底层 IaaS 上云，应用云资源。
8) 2020 年，阿里电商数据库全面开始上云，开始应用云管控。所有外围数据库（交易、购物车、商品、优惠等）及外围链路都采纳云数据库专属集群（MyBase）模式。基于云原生数据库，构建了上万个节点，实现了 RPO=0。

数据库上云的抉择与思考

1. 上云计划抉择 —— 数据上云计划抉择

数据上云计划有很多抉择。首先是数据上云形式的抉择，是应用逻辑迁徙还是物理迁徙？下图这两种数据上云形式的比照，绝大多数迁徙都是逻辑迁徙，应用的是 MySQL/DTS 的形式。然而阿里巴巴的业务个性导致数据规模的体量微小，须要应用物理迁徙，XtraBackup 云原生物理迁徙。上云之后在 2020 年 12 月底，MyBase 会推出物理机房 push 的上云模式。从下图能够发现迁徙的效率、数据对象平滑线、数据一致性、权限等相比于逻辑迁徙都是较高的。对于小规模数据上云时逻辑迁徙是足够的，然而大规模体量下，物理迁徙更适合。

2. 上云计划抉择 —— 网络计划抉择

在网络方面也有几种抉择，首先是 ALB，它最好的长处是绝对成熟，然而也存在很显著的毛病，就是所有的包都要通过 ALB，这不合乎极致性能要求。NGLB，能够解决 ALB 的痛点，只有首包通过 XGW，前面的包不须要通过。然而在 0 点场景中，NGLB 确实是扛不住的。NGLB 也不反对 ECS。ENI（弹性网卡），业界主推的弹性网卡计划。然而弹性网卡计划仍然有个问题，就是不反对物理机。这使得阿里巴巴又往 ENI+RDS 走了一步，然而目前还没有打算推出这个产品，而且因为网卡都是双向联通的，会存在平安危险。阿里目前应用的是 ENI+MyBase 计划，此计划的长处是利用和数据库在同一个网络立体，两头没有代理层，效率较高。但对于管控而言，复杂度晋升了不少。一个机器上有两块网卡，用户用到的网卡和物理机网卡。机器不得不做两次操作，别离是数据链路和管控链路。思考到数据须要双向联动和性能问题，所以应用了 ENI，又思考到安全性问题，应用了 ENI+MyBase 形式。

3. 上云计划抉择 —— 网络拓扑图

如下图，最上层是数据库管控立体，下一层是 RDS 售卖区 VPC，用户核心 VPC 与用户单元 VPC 之间通过 CEN 买通，使得全链路买通，这里应用了阿里云产品撑持整个云上架构。在云下，反对用户自建网络，通过专线买通用户自建网络与用户核心 VPC，用户单元 VPC。用户自建网络之间通过专线买通。保障整个数据库在用户之间是联通的。

4. 上云计划抉择 —— 裸金服务器

阿里巴巴没有应用一般的金属服务器，而是应用了裸金服务器。它们之间区别在于裸金服务
器最上层有一个叫做 X -Dragon 芯片，也叫 MOC 卡。机器自身是消耗资源的，但应用“神龙”服务器当前能够齐全剥离掉这部分，就是说如果买了 96C，768G 的机器，那么就是这么多的资源，不会再因为虚拟化的老本带来额定的开销。MOC 卡还有一个作用是下层的组件，如 VPC/SLB、EBS 云盘都会通过 MOC 卡进行虚拟化，大大减少其它开销，也就是把一台机器变成和虚拟机一样的用户体验。

应用 X -Dragon 架构能够分钟级的去创立 100%物理机性能和性能的云服务器，兼容 VPC、SLB、RDS，撑持云盘启动和挂载云盘，兼容虚拟机镜像，保障物理机的性能和隔离性，。免去了人肉主动运维的事件。应用 ECS 还能够在宕机后，10 分钟内原地拉起一台数据库，迁徙复原。

基于下图中几方面的思考，在比照了物理机，虚拟机 KVM，裸金属服务器 ECS 之后，阿里巴巴抉择了裸金属服务器。运维自动化方面裸金属服务器撑持分钟级交付。应用 MOC 卡机器是无损耗的。在存储方面，裸金属服务器操作系统应用了云盘，能够疾速重置系统盘。在网络方面，物理机局部反对网络一致性。裸金属服务器计划和虚拟机都兼容 ECS 现有管控。

上云计划抉择 —— 存储抉择

上面简略讨论一下存储为何应用云盘？原来云盘最大的下限是 16T，当初这个值曾经变成了 32T，根本能够满足 99% 以上用户的数据库需要，而物理机可能最多只有 6T。云盘能够反对分钟级备份，而之前的办法迁徙 1T 数据就须要 3 个小时。云盘分钟级实例 Clone、分钟级实例跨 Region Clone、数据在线扩盘。运维人员在设置数据库的性能时十分头疼，没有可选的方法，云盘可反对磁盘 IOPS 可配置，意味着能够运维人员强制设置数据库 IO 吞吐，目前最高的吞吐是 500MB/ 秒。MySQL 有 double write 的个性，云盘撑持 MySQL 原子写，少了一次 write 的开销。可靠性方面物理机总是没有分布式存储高。一个 ECS，外面是 POD，拉起一个容器，应用 ESSD 存储，最上面是分布式存储。

上云计划抉择 ——异地只读（GAN）

目前阿里云还没有凋谢异地只读的上云个性。阿里巴巴心愿做到各个 Region 独立，次要是基于 Global Database Network 解决方案。上海的 APP 通过 MaxScale 到上海的数据库，同理，深圳的 APP 通过 MaxScale 一部分分流到原生的数据库 Leader 中，一部分到深圳的数据库，从而实现异地多写。

7. 上云计划抉择 —— 充分利用 MyBase 个性

为什么应用 MyBase? 如下图，买了一对云主机，左侧备份几个 Leader，几个 Follower，右侧同理。节点之间做到亲和、穿插、超卖、弹性。MyBase 能够做到穿插，两主两备，性能最好，其次是亲和，购物车的数据和其它数据库在一起，但又相互独立。因为业务个性须要进行长期扩容，这种状况十分常见，而 MyBase 能够做到动静的调参。因为底层应用了云盘，能够满足弹性需要。

8. 上云的计划 9 大个性

总结而言，上云的计划别离要满足以下 9 个个性：

• 高可用：数据库主备架构，高可用性保障，宕机主动切换、修复。
• 高牢靠：数据库多正本保障、数据同步可调一致性保障（RPO 优先）、三节点企业版 RPO= 0 保障。
• 高性能：内核性能晋升，相比开源版本 MySQL（1.5x）Redis（3x）。
• 高平安：SSL 链路加密、TDE 落盘加密、审计日志体系等。保障事先，事中，预先的数据库安全。
• 运维能力：备份复原、监控报警、智能运维诊断等全套数据库运维解决方案。
• 自主可控：凋谢 OS、数据库残缺权限；凋谢数据库管控平台标准化底层接口；用户可深度自定义数据库治理逻辑。
• 混部：混合部署 MySQL、Redis 等，并提供云数据库治理个性。
• 资源调度：用户专属一片物理主机资源池，可自定义实例调配、散布策略，高度适配业务需要。
• 超配能力：用户物理资源 100% 隔离，反对 CPU、内存（Redis）、空间等资源的超配。

数据库上云是出于几点思考，首先自建数据库不反对很多的数据库管控平台个性，RDS 反对局部个性，如弹性网卡等。而 MyBase 是在 RDS 根底之上衍生进去的产品，目前根本都能够反对这 9 个个性。

四、总结及将来瞻望

1. 上好云，用好云

阿里巴巴数据库上云是思考到业务自身场景，还有云原生技术，以及促成阿里云外部革新等起因。目前 2020 年双 11 期间交易额达到了 4982 亿，顶峰订单 58.3 万笔 / 秒，云原生数据库能够很平滑的反对这些业务。阿里巴巴电商数据库上云不仅仅是把数据库搬上云，更多的思考是如何上好云，用好云。为了反对阿里巴巴的业务，阿里云外部做了很多的革新。通过应用阿里云云原生管控以及云原生数据库技术帮忙业务实现平滑上云指标，进而实现资源最大化老本最优化的指标。

2. 将来瞻望

数据库上云会经验几个大的阶段。最早是物理机阶段，之后是存计拆散，阿里巴巴在 2016 年就开始存计拆散，之后到当初的 MyBase 状态。置信之后在多样性方面会有很多倒退，将来不仅仅应用 MySQL 这一种数据库，还会有很多 OLTP 的数据库。最初，数据库的智能化肯定是将来的大趋势。

作者：stromal
原文链接
本文为阿里云原创内容，未经容许不得转载