简介：第十一届中国数据库技术大会（DTCC2020）在北京隆重召开。本次大会以“架构创新·高效可控”为主题，围绕数据架构、人工智能与大数据、传统企业数据库实践、国产开源数据库等方面进行了重点分享与探讨。在数据库智能运维专场，阿里云数据库高级技术专家王涛受邀介绍了阿里巴巴电商数据库上云的选型、思考和实践。阿里巴巴的电商数据库原本是在自己独立的IDC维护的。借助阿里云项目，可以轻松将数据库迁移到云端。阿里云的云原生管控和云原生数据库技术可以帮助业务实现平滑上云的目标，进而实现资源最大化和成本优化的目标。阿里巴巴希望借助阿里云的技术体系，帮助客户大规模上云，搭建自己的运维管控平台。主讲人简介：王涛，阿里云数据库高级技术专家，来自阿里云数据库产品事业部，喜欢数据库，热爱数据库。职业：程序员->DBA->DevOps架构师。2007年开始参与、设计并主导阿里巴巴数据库系统的演进。主导并参与了阿里巴巴数据库系统的演进。经历过数据库IOE、大规模MySQL运维、阿里数据库多活、数据库云等核心项目。.目前担任阿里云RDS管控负责人，为大家提供安全、稳定、经济、智能的数据库服务。本次分享主要围绕以下四个方面进行：1.阿里巴巴电商数据库应用场景介绍2.数据库管控平台的演进3.数据库上云的选择与思考4.未来展望.阿里巴巴业务特性介绍-RDS三节点企业版阿里巴巴的电商数据是什么？你在淘宝、天猫、盒马、饿了么看到的数据都是阿里巴巴的电商数据。这些业务使用的数据库目前都在云端。阿里巴巴之前的数据库是RDS的高可用版本，采用的是一主多备的模式，但是发现实例的RPO不能为零。尝试使用MySQL半同步等措施，仍然无法解决RPO为零的问题。二是考虑采用CAP理论还是BASE理论的问题。CAP指的是一致性（Consistency）、可用性（Availability）、分区容错性（Partitiontolerance）。但实际上，数据库不可能同时满足CAP的三个特性，只能满足其中的一两个。您可能不熟悉BASE理论。核心是中间可以不一致。A、B机器单独使用时可能会不一致，但是一旦连接起来就会一致。数据管控系统通常遵循BASE理论，而数据库更多的时候选择CAP原则。解决RPO等于0的方法有几种，第一种是MySQL半同步，MySQLGroupReplication，这是MySQL5.7之后引入的新功能，但是需要同一份数据的三副本，代价是不可接受的。于是，阿里逐渐走向了RDS自研的方向。阿里巴巴在选择数据库协议的时候，也在Paxos协议或者Raft协议之间徘徊，最终选择了Paxos协议。阿里巴巴在选择数据库协议的时候，也在Paxos协议或者Raft协议之间徘徊，最终选择了Paxos协议。为什么选择Paxos而不是Raft？从下图右侧可以看出，数据X是先提交的，数据Y是后提交的。在S3中，P3.1、P4.5和A4.5Y先执行，这意味着PaxosProtocols不需要排序，而Raft是。Raft协议会要求S3先执行P3.1，A3.1X，然后再执行P4.5，A4.5Y。这是Paxos协议和Raft协议最大的区别。其次，Paxos协议具有三种角色，提交者（Propose）、接收者（Accept）和Learn。阿里巴巴自研的RDS对这三个角色进行了改造。Propose称为Leader，指的是可读写的数据库节点，Accept称为Follower。多数党拥有全量数据，可以把自己变成领导者。还有Logger（阿里巴巴自研角色），只负责接收日志，没有数据。Leader和Follower是全量数据，Logger只是一个日志接收节点，CPU和内存开销会降低。Learn称为Learner，属于观察者的角色。它有完整的数据，但没有投票权。即使Learner挂了，也不会影响大部分Learner的提交。2、阿里业务特点介绍——异地多活众所周知，阿里巴巴业务还有一个特点，就是异地多活。多住异地有两个好处，都可以拥有Region层级的逃生能力，用户可以在任意一个单位进行交易。下图右侧是通过规则分配用户，可以在数据中心等单位进行交易。异地多活可以实现横向扩展和异地容灾。每年双11可以临时建站，9月完成，双11后两周撤站。3、阿里业务特点介绍——数据库多写异地，那么RDS如何处理异地多活？多住异地，多写异地。下图是支持多活的数据库在异地的分布情况。首先，必须有一个中心DB，对应多个中心环境，包括交易、购物车、商品。中央数据库写入的数据会去对应的store，store可以避免多线程调整时影响数据库性能的问题。Writer负责将数据写入对应的单元DB。unitDB中的数据通过Store返回给centralWriter，返回给centralDB。可以发现数据的推送是星形的，而不是网状的。这是出于几方面的考虑。第一，做DTL难。大家都在做DTL，很容易被抄袭；第二，星型结构至少可以保证一个节点的数据。是全局一致的，即使unitDB宕机了，centralDB里面还是有全量的数据。4.阿里业务特性介绍——数据库远程只读阿里业务特性要求数据库支持远程只读特性。Learner节点数据全，不影响Paxos协议。每个Learner节点必须是灾难恢复节点。基于数据库原生复制的高一致性。保证MySQL内部数据的一致性。因此，数据库架构将如下图右侧所示。中心有三个节点：Follower、Logger、Learner，它们之间可以相互切换。每个单元都有一个Learner节点和一个备用Learner节点，单元应用也在单元Learner中。假设需要一级容灾，可以将单元写权重路由到中心，再通过中心放到各个单元。这样不仅可以实现全局一致性，还可以实现异地多次写入。二、数据库管控平台的演进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运维系统诞生，“D??BFree”。主要用于自动化运维。6）2016年，阿里第三代数据库运维系统“DBPaaS”诞生，满足异地多活、混合云等业务需求。7）2018年底层IaaS将上云，使用云资源。8）2020年，阿里巴巴电商数据库全面上云，采用云管控。所有核心数据库（交易、购物车、产品、折扣等）和核心环节均采用云数据库专用集群（MyBase）模式。基于云原生数据库，搭建数万节点，实现RPO=0。数据库上云的选择与注意事项1、云迁移方案的选择——数据上云方案数据上云有多种选择。首先是选择如何将数据迁移到云端。您使用逻辑迁移还是物理迁移？下图对比了两种数据上云方式。大多数迁移都是逻辑迁移，使用MySQL/DTS方式。但是阿里巴巴的业务特点导致数据量庞大，需要进行物理迁移，XtraBackup云原生物理迁移。上云后，2020年12月底，MyBase将推出物理机房推送的上云模式。从下图可以发现，迁移效率、数据对象平滑线、数据一致性、权限等都高于逻辑迁移。逻辑迁移足够小规模数据上云，物理迁移更适合大规模数据。2、云方案的选择——网络方案的选择网络方面也有多种选择。第一个是ALB。它最大的优点是比较成熟，但是缺点也很明显，就是所有的报文都要经过ALB。不满足极端的性能要求。NGLB可以解决ALB的痛点。只有第一个数据包通过XGW，后面的数据包不需要通过。但是在0分的场景下，NGLB实在是扛不住了。NGLB也不支持ECS。ENI（ElasticNetworkInterfaceCard），业界领先的弹性网卡解决方案。但是弹性网卡方案还是有一个问题，就是不支持物理机。这让阿里巴巴向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卡进行虚拟化，这样就大大减少了其他的开销，也就是把一台机器变成和用户一样的体验。一个虚拟机。采用神龙架构，分分钟打造100%物理机性能和功能的云服务器。兼容VPC、SLB、RDS，支持云盘启动和挂载云盘，兼容虚拟机镜像，保证物理机性能和性能。隔离，淘汰了人肉的自动化运维。使用ECS还可以在宕机后10分钟内就地拉起一个数据库，进行迁移和恢复。基于下图的考虑，在对比了物理机、虚拟机KVM、ECS裸机服务器后，阿里巴巴选择了裸机服务器。在运维自动化方面，裸机服务器支持分钟级交付。使用MOC卡机是无损的。存储方面，裸机服务器操作系统采用云盘，可以快速重置系统盘。在组网方面，物理机部分支持网络一致性。裸机服务器方案和虚拟机都兼容现有的ECS管控。云方案选择-存储选择下面简单讨论一下为什么要用云盘做存储？本来云盘的最大限制是16T，现在这个值变成了32T，基本可以满足99%以上用户的数据库需求，而物理机可能最大只有6T。云盘可以支持分钟级的备份，而之前的方式迁移1T的数据需要3个小时。云盘分钟级实例克隆、分钟级实例跨地域克隆、数据在线扩容。数据库的性能设置让运维人员很头疼。没有替代。云盘支持可配置的磁盘IOPS，即运维人员可以强制设置数据库IO吞吐量。目前最高吞吐量为500MB/s。MySQL具有双写特性，云盘支持MySQL原子写，节省了一次写的开销。在可靠性方面，物理机总是不如分布式存储高。一个ECS里面包含POD，拉上一个容器，使用ESSD存储，底层是分布式存储。云迁移方案的选择——异地只读（GAN）目前阿里云还没有开通异地只读上云功能。阿里巴巴希望把每个Region独立出来，主要是基于GlobalDatabaseNetwork的方案。上海的APP通过MaxScale发送到上海的数据库。同样，深圳的APP通过MaxScale一部分分发给原数据库leader，一部分分发给深圳的数据库，实现异地多写。7、云迁移方案的选择——充分利用MyBase的特性为什么要使用MyBase？如下图，我买了一对云主机，左边备份了几个Leaders和Follower，右边也一样。节点之间实现亲和、交叉、超卖和弹性。MyBase可以做到交叉，两主两备，性能最好，亲和度次之，购物车的数据和其他数据库在一起，但又相互独立。因为业务特性需要临时扩容，这种情况很常见，MyBase可以实现动态调参。因为底层使用云盘，可以满足弹性需求。8.云化解决方案的九大特征概括起来，云化解决方案必须满足以下九大特征：高可用：数据库主备架构，高可用保障，宕机自动切换和修复。高可靠：数据库多副本保障，数据同步可调一致性保障（RPO优先级），三节点企业版RPO=0保障。高性能：与开源版本MySQL（1.5x）和Redis（3x）相比，内核性能得到提升。高安全性：SSL链接加密、TDE磁盘加密、审计日志系统等，保证事前、事中、事后的数据库安全。运维能力：备份与恢复、监控告警、智能运维诊断等一整套数据库运维解决方案。自主可控：开放OS，数据库全权限；开放数据库管控平台标准化底层接口；用户可以深度定制数据库管理逻辑。混合部门：MySQL、Redis等混合部署，并提供云数据库管理功能。资源调度：物理主机资源池专供用户使用，可定制实例分配和分发策略，高度适应业务需求。超配能力：100%隔离用户物理资源，支持CPU、内存（Redis）、空间等资源超配。将数据库迁移到云端有多种原因。首先，自建数据库不支持数据库管控平台的很多特性。RDS支持一些特性，比如弹性网卡。而MyBase是RDS的衍生产品，目前基本可以支持这九个特性。四、总结和未来展望1、用好云，用好云阿里的数据库云是基于业务场景本身，云原生技术，阿里云内部转型的推动。目前，2020年双11期间交易量达4982亿，订单峰值为每秒58.3万笔。云原生数据库可以顺??利支撑这些业务。阿里巴巴电商数据库上云，不仅仅是把数据库搬上云，还要思考如何用好云。为了支撑阿里的业务，阿里云在内部进行了很多改造。通过利用阿里云的云原生管控和云原生数据库技术，帮助业务实现平滑上云的目标，进而实现资源最大化和成本优化的目标。二、未来展望数据库上云将经历几个主要阶段。最早的阶段是物理机阶段，随后是存贮分离。阿里巴巴在2016年开始存储和存储分离，然后才走到现在的MyBase形式。我相信未来在多样性方面会有很大的发展。以后不仅要用MySQL做数据库，还会有很多OLTP数据库。最后，数据库的智能化一定是未来的大趋势。作者：stromal原文链接本文为阿里云原创内容，未经允许不得转载
