阿里的数据库叫什么_数据库

三年前，我从淘系业务线转到阿里云数据库团队做MySQL产品。三年过去了，MySQL产品从几十万节点规模发展到百万节点规模，从非云原生的技术架构成功转型到云原生架构。阿里集团是一个巨大的练兵场，一个新的技术只要能够带来价值，会有很多的机会在顶级体量的业务中得到应用，云原生如此，Serverless也是如此。支撑MySQL产品应用的业务场景，体量通常巨大，在支撑大业务体量飞速发展的背后，技术同学一个很重要的价值在于对系统的不断迭代和重构。之前看到不少分享核心系统架构重构让业务更快迭代的阿里技术类文章，类似做着”开着飞机换引擎“的工作。这里我也做一个分享，来介绍这几年深度参与建设MySQL云原生架构的心得和思考。

起源

MySQL是全球最受欢迎的开源数据库之一，由于LAMP架构赶上了中国互联网经济爆发的窗口，也塑造了目前MySQL在国内无人能撼动的市场领导者地位。对于做技术的同学来说，对MySQL再熟悉不过了，快速、简单、易用也是大多数开发者青睐它的原因。

一般来说，要想去部署一个MySQL数据库并让自己的业务去使用，可行的方案和做法有很多。但如果要将数据库投入到生产环境去使用或者让核心业务去使用，就需要考虑很多基础问题，例如：数据库的可用性角度来看，如何保证7*24小时的不间断工作；从性能角度来看，如何保障再最优的参数和配置下能获得最优的性能。如果是更高阶一些的需求，需要进一步考虑：如何保障当数据误删后能够快速找回，遇到性能问题如何能够更快地定位到问题，数据库规模大了之后成本该如何降低等等。

基于此，我们的工作价值在于从可用性、性能、安全、成本等多维度去给用户提供一款简单易用的数据库服务，让开发者能够更专注在业务开发中。

故事的开始

阿里云RDS MySQL数据库作为数据库家族中的一款老牌数据库引擎，拥有庞大的实例和用户基数，包括阿里集团的内部用户，公共云的用户以及专有云的客户。这里面有很多核心系统使用MySQL数据库，例如集团的核心交易链路的买家库、交易库、库存库等，以及在互联网、金融、民生等各个领域头部企业的核心系统。保障这些数据库全生命周期稳定运行的背后是一套庞大和复杂的分布式系统架构。

因为多年来的发展，很多应用中有着技术和业务多次迭代的影子。我19年加入数据库团队开始接触这方面的研发工作，深切的感受到很多系统中充满了年代感，例如有些系统中还在使用10年前很流行的SSH框架等等。正因如此，无论是后续的业务迭代，还是对于存量系统的维护，历史的负担也让我们快不起来。

云原生这个词前几年出来的时候很热，每个人都有自己的理解。有人说这还是个概念，有人说这只是个炒作，snowflake上市的那一刻，这些都没有了。

2019年底，数据库管控架构就开始推进新的架构演进计划，全面基于以K8S底座+云基础设施的云原生架构方向进行演进，我也开始深度参与到了MySQL的架构演进之路。

2020年开始，我正式开始了在数据库团队”开着飞机换引擎” 的工作，建设阿里云的MySQL云原生架构。

集团上云——云原生架构第一站

2020年是数据库上云的年，核心目标是保障在当年的618、双11大促能够将核心交易链路全面上云，以云的能力来服务集团的业务，集团数据库上云的意义不言而喻：

• 第一，利用云的能力赋能集团，降本增效；
• 第二，利用集团的沉淀赋能云上，锻炼云的能力同时也为云的品牌做背书；
  

深度融合

简单来说集团数据库上云后，对公共云来说只是一个具有大B属性的用户，如何去支撑集团大规模的数据库集群是首先要考虑的问题。另外，集团上云，集团的技术能力不仅可以复用公共云的技术能力，同时给集团定制的技术能力也能反哺给公共云，公共云可以包装为产品化能力输出给公共云的客户。

从集团业务来说：

• 第一，对稳定性的强诉求，稳定性是集团数据库最核心的；
• 第二，集团数据库具备较强定制调度部署的需求，对于单机的实例数上限，应用之间的亲和性和反亲和性都有较高的要求。在云上，我们通过MyBase这种半托管的产品形态包装集团数据库用户，让用户能够看到并管理主机，对自己的实例在不同的主机之间进行自由的调度；
• 第三，集团上云后需要和公共云使用同等的产品能力体验。
  

通过MyBase专属集群模式的包装，我们将集团和云上数据库技术架构完成了深度的融合，把集团用户当做一个大B用户来服务，集团拥有和公共云的产品同等体验。

集团上云的第一个验证点是2020年的618，这次618我们以一切都是全新的技术架构来度过了第一次大考。这里全新的技术包括：全新的多点写数据库内核，云原生管控的第一次大规模接客，ENI网络架构的首次大规模应用，数据库定制神龙机型，计算存储分离架构，全新的OS内核等等。

在2020年618结束后，集团上云团队成员开始陆续发生了变化。因为项目需要，我属于第一批补位进入的集团上云项目，参与了给集团定制特性，下面详细介绍给大家。

集团定制特性

特性一：多点写架构

集团的多点写架构是我在集团上云项目中落地的一个重要特性，核心是在大促高峰能够实现备库资源可利用，通过引入Multi-PaxosGroup技术，有效实现了备库可读写的架构体系，是大大实现了降本增效的一个特性。

特性二：面向跨单读写的全球数据库

高并发低延时高可用是对数据库基础能力的要求，异地读写定制调度则是对RDS产品形态的挑战。云上的RDS以实例为基本的管理对象，主实例和只读实例在本单互相可见；RDS在各单建独立部署，单间的实例不相互感知，跨单的数据同步则需要通过DTS来完成。

集团异地读写的场景下要求全球的数据库作为一个整体，能够进行分流和切换。我们采用全球数据库网络的产品形态来满足（Global Database Network, GDN），在RDS单化的基础上，通过更高层次的抽象形成跨地域的组网方案，而这种产品形态在以往的RDS产品体系里面是不存在的。

DB采用了张北中心、南通、河源和第四单的部署方式。集团上云的过程中，核心交易通过张北为中心、南通与河源为单的三地部署模式组成一张全球数据库网络，通过xcluster原生的数据复制完成中心与单的数据同步。云管控在张北和南通河源之间进行了管控的单化独立部署，也涉及到跨单之间的数据同步问题。

通过这个GDN方案，满足了集团异地容灾、跨单读写低延时的需求。

特性三：资源调度模板

集团业务对于数据库部署的需求是极为苛刻的，一方面集团的主机资源是有限的，因为成本是每个企业都需要考虑的问题，另一方面数据库的部署模型也是很有讲究，例如相同业务的DB需要部署在同一主机，并且单机不能超过多少个实例 ，这样做主要也是为了稳定性和性能的考虑。

为了能满足2020年双11的峰值考验，需要在短短一个月内完成集团数据库达到大促态，当时提供的方案是做了一套调度策略模板，调度策略模板和业务属性挂钩，按照不同业务属性的策略来实现DB间的亲和性和反亲和性。但是由于前期集团数据库上云的不规范，导致现有集群的数据库在主机上的部署已经很混乱了，所以要从一个混乱的部署模型转变成符合业务需求规范的部署模型结构，并且要保障在有限资源的情况下去完成，我们采用了最为原始且当时认为最有效果的方案来解决，就是后面会讲到的“数据库的华容道”。

人肉运维

由于集团上云采用全新的技术架构，各种基础设施和技术能力都不完善，以及代码中还有很多bug，为了能够支撑集团数据库上云的业务，数据库管控团队到集团上云后期基本是进入了全员人肉运维的阶段，下面说几个故事：

故事1：数据库的华容道

华容道的起源是，曹操在赤壁大战中被刘备和孙权的“苦肉计”、“铁索连舟”打败，被迫退逃到华容道，又遇上诸葛亮的伏兵，关羽为了报答曹操对他的恩情，明逼实让，终于帮助曹操逃出了华容道，所以有了一个很有意思的游戏，就是在有限的区域内把曹操挪动出来。

之所以说是数据库的华容道，原因是上面提到必须在有限的主机资源下，让数据库满足复杂的部署模型。基本上做法是，写了一个资源计算的脚本来计算每个集群如何达到一个最优解。另一方面是写了好几个脚本来下发和监控任务数据库在主机上的腾挪任务，手段就是通过不断对数据库在主机上腾出来挪进去，反复腾挪，就像华容道一般，最后达到部署终态。

由于业务的数据库不能白天来做资源腾挪，会对业务造成影响，我们只能选择晚上12点后开始做，那几周基本上每天是下午3点开始上班，早上6点回家睡觉，生物钟整个调整为了美东的时区。庆幸的是，云原生架构中存储计算分离带来的红利，数据搬迁不需要时间，整个腾挪效率还是比较高（除了核心的几个使用本地盘ECS形态资源的数据库实例）。经过了几周，最终还是完成了任务，让数据库集群达到了大促态，这个时差也算值得了~~

故事2：NUMA配置带来的影响

集团的全链路压测基本上从9月份就会陆续开始，当时国庆前做的全链路压测没有通过，最后排查的原因是由于在主机上线的时候NUMA配置存在问题。结果发现当时全网5000+台主机都有问题，调整NUMA还需要和ECS团队的同学配合一起来做，全网ECS主机都要进行重启和变配，所以变更起来非常费劲。

这也意味着我们要在国庆期间完成全网主机重启和变配，然后10月11日再来接受全链路压测。上千台主机的重启是非常痛苦的，因为数据库是有状态的服务，主机重启意味着上面必须全部是备库，并且由于集团使用的XCluster内核，三个节点必须达到多数派，否则就会无法写入，不仅仅要全部是备库，还需要保障主机上DB多数派节点是存活的才能重启这个主机。

当时的做法是，我写了一个脚本，功能是指定一批主机进行主机上的实例进行主备切换，检查TDDL，检查数据库集群多数派情况，设置双1参数等等，然后输出可以重启的主机列表，这批主机列表上只有备库。如果是不满足需求的主机，上面的数据库实例需要进行备库修复的工作。国庆期间整个数据库团队几十号人加上ECS团队的同学，分两班倒，一班人白天重启那批可以重启的主机和修复有问题的DB，另一班人半夜负责通过脚本下发主备切换的任务，保证业务不受影响的同时白天班次的人能够有主机去重启和做变更，就这么轮轴转，最终完成了全网主机的变更。

最终，我们在10月11日通过了全链路压测大考验。

故事3：恶性循坏带来的后果

全新的东西必然在开始阶段会带来很多问题和不稳定，再加上批量去大规模的腾挪实例，由于腾挪的任务流代码缺陷，导致很多问题，例如内核参数不一致或者不符合预期，TDDL配置不对，资源的隔离出问题等等。

这些问题对于业务带来的影响可大可小，例如内核参数来说xkv没打开，对于那种流量很高的业务来说，数据库很容易被打挂。例如，双11前有一轮全链路压测发现天猫超市有一个DB抖动很严重，结果发现是xkv参数没打开，结果压测完都快凌晨2点了，又紧急做巡检和修复，搞到早上6点才解决。

就是这些不断的小问题，基本上是在集团上云过程中被业务方喷得最惨的。

故事4：巡检保障下的双11

集团数据库集群双11对于管控的一个很重要的职责，是通过巡检的手段保证集团数据库的一个稳定态，例如某个主机是否有宕机的风险，某个参数是否设置正确，是否在高峰存在备份任务等等。

当时的解法是，写了很多脚本来去扫描数据库集群的各种保障指标，然后通过每日邮件的方式进行上报。如果存在异常，又要写一些脚本来修复这些有问题的数据库实例。

整个双11下来，累计了很多大大小小不同功能的脚本，这些脚本自然是零散并且不成体系，也没有什么能沉淀下来的东西，只能说通过这种脚本运维的模式，保障了双11的平稳度过（当然写了那么多脚本，个人写脚本的能力也是得到了突风猛进的进步~）

集团上云的最后

现在回过来看2020年我们做的集团上云，确确实实锻炼了云的能力，也确确实实锻炼了经历了这年集团上云的每一个同学。虽然集团上云带来的变化和压力，上云团队的研发成员换了一波又一波。但是最后坚持下来的也收获了巨大的经验宝藏，也让自己能够更从容的面对压力，正是这段经历，为后续在云原生架构的演进积累了宝贵的经验，这次经历也是此生难忘的一段经历。

混合云——DBStack的一段经历

2020年双11后马不停蹄，一方面维护集团上云，另一方面开始进场混合云的DBStack。

DBStack核心背景是：

• 从行业背景来说，大型行业企业基本建有自己的IAAS基础设施，希望数据库能够轻量级部署。
• 之前专有云敏捷版的最大问题是起步规模3台独占机器，不支持容灾、不支持第三方IAAS部署、敏捷版其实不敏捷的一个问题。
  

DBStack是阿里云数据团队针对混合云市场推出的集交易、分析、传输、治理于一体的企业级数据库管理平台。DBStack作为公共云的一个切片，将公共云能力对接到混合云底座上，一方面实现最小化纯软输出的能力，另一方面可以对接到第三方IAAS的资源部署，实现轻资产、被集成的能力。

我参与DBStack核心工作是让RDS MySQL进场DBStack，将集团的XDB结合PolarDB-X以两地三中心的部署模型实现可输出能力。

当时做了几个核心的事情：

• 管控服务组件完全对接了混合云的k8s底座，满足管控组件和DB混部，实现最小单输出能力
• 将依赖的部分基础服务做到了完全可插拔弱依赖（例：VPC服务，白名单服务等）
• 复用集团上云的能力，将XDB三节点模型扩展成符合两地三中心的部署模型结构
  

DBStack的经历到去年2月初收尾，虽然只经历了短短3个月的时间，但是基于K8S底座的云原生架构带来的红利已经逐渐开始显现出来。

All in 公共云

2020年团队的主要精力都是All in 集团上云，从而也导致公共云的业务迭代停滞了很长一段时间。在2020年双11后才开始逐步慢慢释放人力开始在公共云的业务上进行开展，在FY22财年开始，组织架构做了很大的调整，团队从之前集团上云+混合云+公共云转变为：All in 公共云。

相较集团上云来说，公共云的整体节奏是自主可控的，留给思考的时间更充足了，想清楚怎么做以及怎么规避之前遇到的问题显得非常重要。

重新定义云原生架构

再去看如何更好落地MySQL公共云的云原生架构，最开始需要思考在公共云的体系中，云原生能给MySQL带来什么变化？

MySQL作为一款开源托管的数据库产品，在这个宏观的定义下，我们希望是能够将云的能力最大化去利用，使用云的资源池化的能力，使用好云的能力去做好上层的PAAS产品能力，并服务好客户。

通过K8S对资源的抽象，让上层的PAAS能够更方便地操作IAAS的资源，让PAAS和IAAS彻底实现解耦，并让PAAS享受IAAS演进带来的红利。

云盘技术架构重构

云盘产品重构第一站：MySQL的基础版形态

整体背景：基础版实例往往是客户体验云数据库的第一站。基础版实例的数量庞大，然而，在多个渠道（NPS、工单、客户问题等）中，我们听到很多客户对这类实例的性价比和稳定性提出质疑。对工单、客户问题等进一步分析，我们发现基础版实例给客户带来了以下几大痛点：

• 实例创建时间长：单实例创建时间长达20分钟，严重影响用户业务效率；
• 存在部分稳定性问题：小规格实例经常会发生内存耗尽导致ECS
  Hang，严重影响客户业务的顺畅度。稳定性问题也体现在我们每月服务量上，有些单类问题一直是居高不下，给客户带来了很多产品体验问题；
• 资源成本高：单租户架构要为每个RDS实例创建系统盘，使用独立的管控组件资源，我们不能降成本的同时意味着用户的价格也没办法降低。

之前的架构模型，主要采用单租户的架构，一个ECS对应一个RDS。

优点：

• 资源交给ECS团队，不需要再关心底层资源供给问题；
• 不同用户DB之间的隔离性更好。

缺点：

• 创建时间长：因为ECS买来对我们来说不是直接就能使用，上面还需要安装管控的服务以及对DB进行相应的初始化，整个耗时差不多20min。
• 稳定性差：小规格实例量非常大，但是由于管控和DB共享ECS的资源，小规格实例经常将ECS内存耗尽，导致实例hang死，用户体验差的同时，也给我们值班带来很大的压力。
• 资源成本问题：给到我们可二次调度的空间为0，采购ECS的成本往往是不可控，其次DB资源利用率是非常低的，我们没有最大化的去优化和利用资源的手段。

为了能够解决遇到的这些痛点，在基于云原生架构的底座之上，我们一方面保留了单租户的架构，给到对有隔离性需求的用户；另一方面也增加了多租户的架构模型。

多租户模型的优点：

• 资源共享：一个主机上部署一套管控Agent来服务主机上的多套DB实例，并且多套DB实例共享一个系统盘，大幅提升了资源利用率；
• 资源隔离：将管控的Agent资源和DB资源进行隔离，主机上剩余的资源给到管控做二次资源调度，DB在主机上的资源有保障，稳定性大幅度提升；
• 离线调度：我们引入了离线调度，对资源进行压缩和优化，一方面是基于成本的，另一方面是基于稳定性的，优化了成本的同时也保障了整个主机水位的稳定性。

基础版产品的架构重构在2021年S1完成落地后，我们将增量的新购实例全部切流到了云原生架构上，同时也打通了存量的实例可无感迁移到云原生架构的迁移流程，用户可以通过控制台内核版本升级就能完成迁移。

整个架构的重构项目做下来，团队也拿到了阿里云FY22-S1的红草莓奖。

弹性能力是核心竞争力

云数据库的一大核心就是弹性能力，弹性能力能给数据库带来更多想象的空间，例如：数据库的Serverless，当RDS MySQL全面跑在云原生架构上之后，弹性是最优先需要去提升的能力。

对于外界用户来说，在MySQL产品上购买本地盘形态是大多数用户的一个默认行为，其主要原因是本地盘的性能是云盘性能很难去超越的。虽然云盘的技术体系一直在不断演进，性能也越来越优，但是要在成本+性能上超越本地盘尚且需要时间。

云原生架构主打存计分离的架构，所以弹性能力是一大需要突破的点，也是云盘架构的一大核心竞争力，依托云原生资源池化的技术红利，到今天为止针对弹性能力我们做了几大核心优化：

• 存储弹性：通过云盘提供的onlineResize，性能等级热升级等能力，实现了存储的弹性；
• 实例创建提速：引入系统盘快照，镜像加速，组件预安装，流程并行化等技术，实现了实例创建的提速，完成了实例拉起提速的突破，多租户降低到3分钟内，单租户降低到5分钟内；
• 本地快弹：在多租户场景下，最大化利用主机资源，解决用户在高负载下做DB的资源变配由于备库复制延迟导致经常失败的问题，我们通过引入Pod变化监听来动态修改cgroup+内核的BP热修改来实现DB的热升级；
• 只读实例并行化：引入秒级快照，备份复用等能力，满足用户添加多个只读，做到能够并行创建，且在3分钟内完成只读实例创建；
• 弹性节点池：多租户形态下，我们有了二层调度做到MySQL业务的资源池化。同时在ECS资源节点池的管理上，利用ECS带来资源池化的能力，来保障了持有成本的最大化。

通过这几个手段大幅提升了弹性能力，一方面提升了云盘架构的核心竞争力，另一方面为RDS on Serverless打下了坚实的基础。弹性能力的升级给RDS产品带来了更多的可能。

稳定性是一切的基础

集团上云那次“开着飞机换引擎”的经历，给我带来很大的一个经验和思考是：如果再去做一次“开着飞机换引擎”的项目，该如何去提升保障的稳定性。公共云的云原生架构升级不仅不比集团上云轻松，反而更困难，用户使用云数据库的用法是多样化但不是标准化的。

我们需要在用户无感的情况下自动切流到云原生架构上。核心思路还是要去构建一套基于数据驱动的稳定性基础设施的通路闭环。

核心几个点：

• 数据采集：结合DBAAS产品团队提供的数据中台能力，通过Agent+中心化体检，解决了当初集团上云中每天写脚本去巡检的方式，同时数据采集异常和事件进入中台沉淀；
• 实例体检：当初在集团上云过程中遇到最大的问题就是，由于代码发布导致线上的实例发生可能在做变更的时候出现非预期的行为，但是这个时候我们完全没有感知。吸取了当初的教训，我们新增了实例变更触发一次全量的体检，保证不会再由于代码发布或者其它因素导致实例出现非预期的行为。
• 稳定性大盘：基于数据中台的能力，构建一套稳定性的可视化大盘，让全局稳定性是可观测可分析的，通过稳定性大盘解决了当年集团上云对稳定性层面抓瞎的问题；
• 自愈&治理：基于异常事件数据，通过数据驱动的方式对部分异常做到自动化的自愈，另一部分异常事件成立专项进行单独治理；
• 变更规范：事前、事中、事后通过建立变更三板斧的机制来保障云原生架构切流上线的稳定性；
• 工具化：稳定性和工具体系结合是提升稳定性保障很有效的一个手段，我们将稳定性的能力孵化出了实例一键诊断、大客户重保等工具能力，提供问题排查、日常值班等场景，提升了整个效率和效能。

稳定性是业务发展的基石，也是我们持续在构建的方向，在公共云业务升级云原生架构中，到目前为止，通过构建稳定性基础能力让我们没有产生过故障，也顺利达到了之前制定的向云原生架构全面演进的目标。

我们需要工具来提效

在2021年我们专门找了一个同学来做工具平台，为什么要做工具？

核心思想是：

• 中心化管理：数据库是分单化部署的，差不多涉及十几个单，缺少一个中心化管理的平台，我们需要有一个具有全局维度的视角；
• 经验沉淀：MySQL的公共云体量大，日常值班压力是很大的，但是值班这个工作又是一个靠经验+重复性的体力活，我们需要一个工具平台来解决经验沉淀以及减少重复性操作的问题；
• 数据驱动：通过数据驱动的方式来解决稳定性问题，实现从之前巡检式的异常修复全面切换到基于数据驱动的异常消除；
• 数据运营：做业务研发是非常需要数据运营去支撑的，举个最简单例子：当一个产品功能上线后，有多少用户在使用、用得怎么样都不清楚，然后还需要这个数据还需要去捞数据库，这种事情就太鸡肋了；
• 合作桥梁：内核和管控组成的技术团队，虽然职责和工作范围不一样，但我们也希望提供一些方式来不断提升内核和管控之间的合作模式，让整个RDS产品更好的发展。

在2021年下半年开始，我们主要围绕RDS MySQL的业务属性，打造了工具平台的几个大模块：

工具平台的逐步建设，为我们在云原生架构的建设道路上从多个维度实现了提能提效，同时也让更多同学能够更容易地参与进来，让我们在云原生架构的建设道路上能够跑起来。

现在的公共云

到今天为止，我们已经将RDS MySQL的云盘架构完成了全面向云原生架构的转型，其中包括基础版和高可用产品形态。公共云的用户购买云盘产品形态的数据库实例，已经完全切换到了云原生的架构中，目前已将近十多万个RDS MySQL数据库实例跑在了云原生的架构上。同时我们也做了通过自建用户备份集一键上云的能力，帮助用户把自建的数据库实例上到云原生架构，经过在这条道路上不断的探索，MySQL在云原生架构上逐渐找到了自己的方向。

基于云原生架构，我们目前也在逐渐往极致弹性的技术方向进行演进，RDS on Serverless 打造的极致弹性的数据库产品形态也将会在今年进行发布，敬请期待。

写在最后

从2020年开始到今天，我们从0到1建立起了MySQL的云原生架构，经历了两次“开着飞机换引擎”，一次集团上云，一次公共云架构升级，云原生的技术架构体系逐步走向正轨。我认为，云原生架构的旅程才刚刚开始，接下来我会不断去结合云原生带来的红利提升产品的竞争力，打造更极致的MySQL产品体验。

当然，RDS产品未来的想象力不仅如此，云原生的技术架构也不是终点。随着技术的不断发展迭代，我们也需要不断和阿里云的ECS、存储、容器等团队一起创造更多的可能性。（正文完）

阿里云数据库专家王颜培：我做MySQL云原生这些年