当前位置:主页 > 查看内容

RDS MySQL 云原生架构实践

发布时间:2021-07-21 00:00| 位朋友查看

简介:一、阿里云RDS MySQL简介 一 简介 阿里云RDS MySQL是阿里云数据库产品核心产品 也是全球最受欢迎的开源数据库之一。阿里云RDS MySQL在集团内支撑核心电商交易以及数十个不同BU的业务。另一方面在公共云作为一款商业化PaaS产品 支撑阿里巴巴之外的各个公司的……

一、阿里云RDS MySQL简介


一 简介


阿里云RDS MySQL是阿里云数据库产品核心产品 也是全球最受欢迎的开源数据库之一。阿里云RDS MySQL在集团内支撑核心电商交易以及数十个不同BU的业务。另一方面在公共云作为一款商业化PaaS产品 支撑阿里巴巴之外的各个公司的业务体系。同时也作为一款专有云的产品 输出到不同企业平台


图片 1.png


可以用三个词来形容阿里云RDS MySQL。


第一个是我们的用户群体非常庞大。在数据库的产品生态中 阿里云RDS MySQL的实例数和用户数是最多的。


第二个是我们经过多年的发展 打造了丰富的企业级能力。比如弹性能力 用户可以按需计费地存储或计算 还有很多丰富的运维能力 如备份、恢复、切换、监控、告警等。同时我们还有全链路安全加密 如SSL、云盘加密、白名单等。除此之外我们还有智能化加持 能够帮用户做诊断分析 还能自诊断、自优化


第三个是我们提供了多种部署架构 最经典的是主备架构 我们还支持同城容灾的跨可用区架构。并且也支持MySQL三节点。三节点内核形态可实现RPO为0 能够做到不丢数据 并且其中的Log节点它不存数据 只做回放日志。


二 阿里云RDS MySQL整体架构

例 MySQL三节点架构


做完简单的产品介绍之后 接下来大概介绍一下我们的整体架构 这里以刚才提到的MySQL三节点架构为例。


图片 2.png


如上图所示 MySQL三节点包括主备节点和日志 我们放到了三个不同的可用区里 三个节点之间通过日志方式同步数据。因为Log节点不存数据 所以我们用的是很小的规格 这样能够减少很多成本。


同时 在这三个节点之间 主节点上面会挂一个SLB 一方面是让用户ECS通过访问SLB然后访问主节点 同时SLB也能够让线下以及自建的用户访问到云上的数据库。


在整个RDS实例里 我们基于OSS打造了全量加增量的数据备份 能够帮助用户做数据的克隆、恢复 包括按时间点恢复 按备份集恢复 除此之外还有审计以及监控。集成的所有能力通过Open API 一方面是用户能够集成我们的产品能力 另一方面是用户可以通过控制台操作整个RDS产品。



二、云原生架构之路


一 云原生架构之路?- 架构演进


在向云原生架构的演进到的过程中 我们也是一代代地进行迭代。


图片 3.png

第一代是物理机时代 我们底下都是物理机 然后物理机上放多个实例 并且是多租户的 每个实例之间用cgroup做隔离。


后边逐渐演进到容器化架构 因为我们发现有个痛点 就是大量的物理机资源需要维护 我们花费了很大的精力投入到资源维护上。因此 我们把资源交给ECS团队去维护 我们只需要关心PaaS层的东西。同时我们构建基于Docker容器化的基础设施 保证MySQL能够标准化交付、运维。


如今 我们开始探索云原生 基于Docker和K8s的容器化标准方式 去支持现在MySQL业务。


二 云原生架构之路-整体策略


为什么要往云原生方向演进 这里简单说一下我们的想法。


图片 4.png


先从底层来看 云有整个资源池化、弹性的能力。同时 云还有很多不同的产品能力 因为现在整个企业都在向在线化和数字化不断地转型 阿里云的基础设施也在飞速演进 推出了很多云的产品 不仅有ECS、云盘、VPC 还有DBFS、ECI、ACK等很多基础设施。


为了能够让我们的RDS产品更好地发展 更快地迭代 让我们更充分地使用云的能力 所以我们需要跟基础设施层做解耦 让我们关注在PaaS层的建设 通过系统的扩展性进行升级 让系统扩展性更强。同时 我们在产品上能够更专注 给到用户更好的体验 实现更好的稳定性。

?

三 云原生架构之路?- 演进的障碍和收益


MySQL积极拥抱云原生这个大势才能获得更好的发展。


接下来介绍一下我们演进的障碍跟收益。


图片 5.png


上图一个是本地盘的形态 也就是刚才提到的物理机时代 另一个是基于ECS、Docker的云盘形态。这两个架构有很大的痛点 就是如果我们要开发一个功能 需要通过本地盘实现一遍 然后再通过云盘实现一遍。同时 这对我们的人力有很大的浪费 而且需要维护相关资源。


图片 6.png


在我们演进到云原生架构之后 引入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架构中。


图片 7.png


五 云原生架构之路-DSL配置式DB编排体系


MySQL三节点 DSL实例化举例


接下来简单介绍一下DSL的大概逻辑。


图片 8.png

?

还是以刚才MySQL的三节点为例。在最上层 用户看到的是一个MySQL的实例 下面有三个计算的节点 Leader对应Master Follower对应Slave Logger对应日志。


存储节点无论是云盘还是本地盘 我们将最上层的实例抽象成了一个ReplicaSet 将计算节点抽象成了一个Replica Replica无论指定多少个都可以 并且可以指定每个Replica分布到哪个可用区里面 包括规格之类。


同时 我们将这层模型绑定DSL DSL描述的内容包括挂盘的方式 假如挂的是云盘 挂在容器里面怎么挂 如果是本地盘的话 把本地盘的目录挂到容器里面又该怎么挂 并且整个资源申请完之后 最后需要用什么样的方式做备份 或者说用什么样的方式拉起 这些内容都是跟整个数据库业务相关的。


当这些内容抽象完出现一个DSL之后 提交给业务中台 业务中台去做整个资源申请 类似于底座K8s Apply的资源模型一样 并且后面去完成整个实现的生产以及后面的运维。


六 云原生架构之路?- 核心组件交互架构

?

图片 9.png


上图是基于K8s的管控架构图。


这个架构里有几个特点 一个是分层的架构设计 另外每个模块里面有很多主键 每个模块主键之间是以微服务化的方式交互。此外我们也实现了一套编排式的工作流 通过这种方式能够更大地提高运维以及开发的效率。


七 云原生架构之路?- 资源池化和云原生


资源在线 离线智能化调度


我们在资源调度层做了在线跟离线一体化的调度逻辑。

?

图片 10.png


如上图所示 这里面有几个特性。一个是我们面向稳定性做了一些调度 例如一个主机上或者一个Load上资源的负载 本地盘需要做磁盘降载 对于本地盘 主机上可能需要做下线 这些都是通过主动运维调度打散的方式完成 我们把它们调度到其他安全的机器上 从而保证实例的稳定性。


第二个是面向成本的调度 我们在做调度的时候会考虑资源优化、成本优化。比如 我们会让CPU售卖率与内存售卖率达到一定的预期 会做资源的压缩 或者说对资源碎片做整理 让我们的成本做得更优。成本降低之后 我们能够给到客户的价格会更低。


第三个是面向大促场景的调度 举个例子 我们在支持阿里核心电商的数据库集群双11前 需要将数据库集群通过弹性调度的方式让整个集群达到大促态 来备战双11 双11结束后 又会将整个集群的调度为“紧凑型” 回到日常态。

?

八 云原生架构之路?- 规模化弹性案例


打造规模化弹性产品能力?– 助力双11完成“大促态”准备

?

图片 11.png


平时整个集团的数据库集群负载是比较低的 为了让核心交易链路能够快速达到“大促态” 我们通过离线调度的方式将核心数据库的集群变成均衡性的策略 让它们完成大促态的准备 扛过双11的峰值。


九 云原生架构之路?- 不同存储架构选型


适合不同负载场景的“IO性能 弹性”组合

?

图片 12.png

上文提到我们不仅支持本地盘 而且支持云盘 两个不同的形态各有特点。


本地盘在IO上的性能天生就非常高 IO能力会更强 但是本地盘有一个很大的缺陷是当用户需要扩容或变配的时候 假设本地的资源不够 就要去搬数据 如果量很大的话 时间成本会非常高 因此本地盘的弹性能力相对来说更弱一些。


云盘上的优势是什么 第一是它在变配的时候 计算存储节点是完全做分离的 计算节点可以直接扩 我们先停备再做一次切换 然后再去扩充。扩计算节点的话 我们会把备节点先扩掉 然后做一次切换 然后到主。如果是存储节点的话 先把备库扩完之后再扩主库 相当于它具备分钟级的弹性能力。


我们在做规模化弹性能力的话 都是基于计算存储分离架构完成的。



三、后续规划


持续不断探索云原生 通过技术演进来赋能业务。


图片 13.png


对于后续规划 我们会在云原生方向不断探索 主要包含两点。


一是需要更极致的弹性 上文提到我们现在做计算节点扩容的时候 还是需要对计算节点停服 后续我们会让计算资源实现热扩容 并且能够在上面做Serverless on RDS的产品形态。


另一方面 在云原生之后我们会去嫁接智能化 让RDS更智能地帮助我们的业务开发 提升数据库的异常自定位 以及让数据库拥有更好的自治能力。


本文转自网络,原文链接:https://developer.aliyun.com/article/785477
本站部分内容转载于网络,版权归原作者所有,转载之目的在于传播更多优秀技术内容,如有侵权请联系QQ/微信:153890879删除,谢谢!

推荐图文

  • 周排行
  • 月排行
  • 总排行

随机推荐