一、阿里云RDS MySQL简介
（一）简介
阿里云RDS MySQL是阿里云数据库产品核心产品，也是全球最受欢迎的开源数据库之一。阿里云RDS MySQL在集团内支撑核心电商交易以及数十个不同BU的业务。另一方面在公共云作为一款商业化PaaS产品，支撑阿里巴巴之外的各个公司的业务体系。同时也作为一款专有云的产品，输出到不同企业平台。
可以用三个词来形容阿里云RDS MySQL。
第一个是我们的用户群体非常庞大。在数据库的产品生态中，阿里云RDS MySQL的实例数和用户数是最多的。
第二个是我们经过多年的发展，打造了丰富的企业级能力。比如弹性能力，用户可以按需计费地存储或计算，还有很多丰富的运维能力，如备份、恢复、切换、监控、告警等。同时我们还有全链路安全加密，如SSL、云盘加密、白名单等。除此之外我们还有智能化加持，能够帮用户做诊断分析，还能自诊断、自优化。
第三个是我们提供了多种部署架构，最经典的是主备架构，我们还支持同城容灾的跨可用区架构。并且也支持MySQL三节点。三节点内核形态可实现RPO为0，能够做到不丢数据，并且其中的Log节点它不存数据，只做回放日志。
（二）阿里云RDS MySQL整体架构
例：MySQL三节点架构
做完简单的产品介绍之后，接下来大概介绍一下我们的整体架构，这里以刚才提到的MySQL三节点架构为例。
如上图所示，MySQL三节点包括主备节点和日志，我们放到了三个不同的可用区里，三个节点之间通过日志方式同步数据。因为Log节点不存数据，所以我们用的是很小的规格，这样能够减少很多成本。
同时，在这三个节点之间，主节点上面会挂一个SLB，一方面是让用户ECS通过访问SLB然后访问主节点，同时SLB也能够让线下以及自建的用户访问到云上的数据库。
在整个RDS实例里，我们基于OSS打造了全量加增量的数据备份，能够帮助用户做数据的克隆、恢复，包括按时间点恢复，按备份集恢复，除此之外还有审计以及监控。集成的所有能力通过Open API，一方面是用户能够集成我们的产品能力，另一方面是用户可以通过控制台操作整个RDS产品。
二、云原生架构之路
（一）云原生架构之路 - 架构演进
在向云原生架构的演进到的过程中，我们也是一代代地进行迭代。
第一代是物理机时代，我们底下都是物理机，然后物理机上放多个实例，并且是多租户的，每个实例之间用cgroup做隔离。
后边逐渐演进到容器化架构，因为我们发现有个痛点，就是大量的物理机资源需要维护，我们花费了很大的精力投入到资源维护上。因此，我们把资源交给ECS团队去维护，我们只需要关心PaaS层的东西。同时我们构建基于Docker容器化的基础设施，保证MySQL能够标准化交付、运维。
如今，我们开始探索云原生，基于Docker和K8s的容器化标准方式，去支持现在MySQL业务。
（二）云原生架构之路-整体策略
为什么要往云原生方向演进？这里简单说一下我们的想法。
先从底层来看，云有整个资源池化、弹性的能力。同时，云还有很多不同的产品能力，因为现在整个企业都在向在线化和数字化不断地转型，阿里云的基础设施也在飞速演进，推出了很多云的产品，不仅有ECS、云盘、VPC，还有DBFS、ECI、ACK等很多基础设施。
为了能够让我们的RDS产品更好地发展，更快地迭代，让我们更充分地使用云的能力，所以我们需要跟基础设施层做解耦，让我们关注在PaaS层的建设，通过系统的扩展性进行升级，让系统扩展性更强。同时，我们在产品上能够更专注，给到用户更好的体验，实现更好的稳定性。
（三）云原生架构之路 - 演进的障碍和收益
MySQL积极拥抱云原生这个大势才能获得更好的发展。
接下来介绍一下我们演进的障碍跟收益。
上图一个是本地盘的形态，也就是刚才提到的物理机时代，另一个是基于ECS、Docker的云盘形态。这两个架构有很大的痛点，就是如果我们要开发一个功能，需要通过本地盘实现一遍，然后再通过云盘实现一遍。同时，这对我们的人力有很大的浪费，而且需要维护相关资源。
在我们演进到云原生架构之后，引入K8s作为统一的接入层。K8s能够把整个IaaS资源做抽象，抽象成Node/Pod/Pvc等不同的资源模型，并且它提供了标准化的接口，能让上层的PaaS平台统一化、标准化进行调用。
这带来的好处是什么？
一个是整个IaaS层的资源能够不断演进，比如引进ECI这样的弹性能力，我们也能把ECS替换成ECI，或者底下的存储替换成别的存储，不需要再依赖于底下不同资源的演进而改变我们上层的架构。
同样，上层的PaaS跟底下的资源层解耦之后，上层也能更专注地打造PaaS化的平台能力。在这层架构上解决的问题是代码只需要写一份，就能跑在本地盘和云盘上，或者跑在以后更新的形态上，而且统一通过K8s的方式进行管控和运维的话，我们的人力成本也大幅降低。
（四）云原生架构之路 - DSL配置式DB编排体系
基于K8S平台的DB集群调度平台。
通过K8s对整个资源层做了抽象之后，解决了IaaS层资源抽象的逻辑。
其实对于IaaS抽象还有一步没做，对于数据库来说，它有很多自己的业务特性，比如需要备份，需要有不同的内核，需要有自己的运营逻辑。
因此我们基于数据库的业务，在K8s上面再做了一层业务抽象，自己去定义了一套DSL模型，这样不仅保证了MySQL不同的业务，还保证了像Mongo、Redis、PostgresSQL等不同引擎，通过这套模型能够快速接入到K8s架构中。
（五）云原生架构之路-DSL配置式DB编排体系
MySQL三节点 DSL实例化举例
接下来简单介绍一下DSL的大概逻辑。
还是以刚才MySQL的三节点为例。在最上层，用户看到的是一个MySQL的实例，下面有三个计算的节点，Leader对应Master，Follower对应Slave，Logger对应日志。
存储节点无论是云盘还是本地盘，我们将最上层的实例抽象成了一个ReplicaSet，将计算节点抽象成了一个Replica，Replica无论指定多少个都可以，并且可以指定每个Replica分布到哪个可用区里面，包括规格之类。
同时，我们将这层模型绑定DSL，DSL描述的内容包括挂盘的方式，假如挂的是云盘，挂在容器里面怎么挂，如果是本地盘的话，把本地盘的目录挂到容器里面又该怎么挂，并且整个资源申请完之后，最后需要用什么样的方式做备份，或者说用什么样的方式拉起，这些内容都是跟整个数据库业务相关的。
当这些内容抽象完出现一个DSL之后，提交给业务中台，业务中台去做整个资源申请，类似于底座K8s Apply的资源模型一样，并且后面去完成整个实现的生产以及后面的运维。
（六）云原生架构之路 - 核心组件交互架构
上图是基于K8s的管控架构图。
这个架构里有几个特点，一个是分层的架构设计，另外每个模块里面有很多主键，每个模块主键之间是以微服务化的方式交互。此外我们也实现了一套编排式的工作流，通过这种方式能够更大地提高运维以及开发的效率。
（七）云原生架构之路 - 资源池化和云原生
资源在线+离线智能化调度
我们在资源调度层做了在线跟离线一体化的调度逻辑。
如上图所示，这里面有几个特性。一个是我们面向稳定性做了一些调度，例如一个主机上或者一个Load上资源的负载，本地盘需要做磁盘降载，对于本地盘，主机上可能需要做下线，这些都是通过主动运维调度打散的方式完成，我们把它们调度到其他安全的机器上，从而保证实例的稳定性。
第二个是面向成本的调度，我们在做调度的时候会考虑资源优化、成本优化。比如，我们会让CPU售卖率与内存售卖率达到一定的预期，会做资源的压缩，或者说对资源碎片做整理，让我们的成本做得更优。成本降低之后，我们能够给到客户的价格会更低。
第三个是面向大促场景的调度，举个例子，我们在支持阿里核心电商的数据库集群双11前，需要将数据库集群通过弹性调度的方式让整个集群达到大促态，来备战双11，双11结束后，又会将整个集群的调度为“紧凑型”，回到日常态。
（八）云原生架构之路 - 规模化弹性案例
打造规模化弹性产品能力 – 助力双11完成“大促态”准备
平时整个集团的数据库集群负载是比较低的，为了让核心交易链路能够快速达到“大促态”，我们通过离线调度的方式将核心数据库的集群变成均衡性的策略，让它们完成大促态的准备，扛过双11的峰值。
（九）云原生架构之路 - 不同存储架构选型
适合不同负载场景的“IO性能&弹性”组合
上文提到我们不仅支持本地盘，而且支持云盘，两个不同的形态各有特点。
本地盘在IO上的性能天生就非常高，IO能力会更强，但是本地盘有一个很大的缺陷是当用户需要扩容或变配的时候，假设本地的资源不够，就要去搬数据，如果量很大的话，时间成本会非常高，因此本地盘的弹性能力相对来说更弱一些。
云盘上的优势是什么？第一是它在变配的时候，计算存储节点是完全做分离的，计算节点可以直接扩，我们先停备再做一次切换，然后再去扩充。扩计算节点的话，我们会把备节点先扩掉，然后做一次切换，然后到主。如果是存储节点的话，先把备库扩完之后再扩主库，相当于它具备分钟级的弹性能力。
我们在做规模化弹性能力的话，都是基于计算存储分离架构完成的。
三、后续规划
持续不断探索云原生，通过技术演进来赋能业务。
对于后续规划，我们会在云原生方向不断探索，主要包含两点。
一是需要更极致的弹性，上文提到我们现在做计算节点扩容的时候，还是需要对计算节点停服，后续我们会让计算资源实现热扩容，并且能够在上面做Serverless on RDS的产品形态。
另一方面，在云原生之后我们会去嫁接智能化，让RDS更智能地帮助我们的业务开发，提升数据库的异常自定位，以及让数据库拥有更好的自治能力。
