云数据库产品及架构设计背后的考量

摘要：在阿里云数据库技术峰会上，阿里云数据库高级产品专家萧少聪（铁庵）介绍了全体系阿里云数据库产品并对于阿里云数据库产品的实现架构进行了分享，帮助大家了解了阿里云全数据库产品体系能解决哪些实用场景的问题，同时帮助大家了解其解决的原理。

       8月24日，阿里云数据库技术峰会到来，本次技术峰会邀请到了阿里集团和阿里云数据库老司机们，为大家分享了一线数据库实践经验和技术干货。

以下内容根据演讲嘉宾现场视频以及PPT整理而成。

       本次分享将主要介绍阿里云是如何设计云数据库产品的架构的，以及在云数据库产品的架构设计背后的故事。本次的分享将不会非常深入技术底层细节，而是希望通过分享使得大家了解在使用云数据库时应该如何去规划，以及阿里云在设计云数据库产品的时候存在什么样的思考。

一、云数据库的市场背景

多产品类型混合

       在市场上面，大家可以看到类型非常多样的数据库产品。如果大家今天还是在使用像SQL Server或者MySQL这样单独的关系型数据库，那么可能业务所覆盖的场景还是比较有限的。而往往在一家中型或者比较大型的公司里面，已经开始用到很多不同的数据库产品了。

 

系统架构越发复杂

       如上图所示，通常情况下，在业务刚开始的时候使用的是一个SQL数据库或者NoSQL数据库，但是随着业务慢慢的发展就会用到Key-Value的缓存数据库，再之后可能就会发展到数据仓库，同时也可能发展到大数据的系统。

       接下来为大家介绍一家公司从小型企业逐步成长为大型企业的过程中的数据库架构设计的发展步骤以及在运作过程中每个阶段的数据库演化情况。如下图所示，在初始阶段，整个数据库架构的结构是比较简单的，图中仅有3台服务器，这意味着公司在刚刚开始的时候可能只有几台数据库服务器，它们可能是SQL的系统，也可能是NoSQL的系统。此时DBA以及管理人员不需要去做过多的结构使用分析。然而，在进行管理的过程中，DBA往往会身兼多职，在这个时候的DBA可能在管理数据库的同时也在做开发以及对于操作系统的运维工作。

 

       更进一步，当企业发展到初具规模的时候，数据库往往就不能够以单节点的方式去运行了，此时往往需要配合一些集群以及一些其他的数据库。例如在刚刚开始的时候，只用到了单独的SQL数据库以及NoSQL数据库，但是在系统初具规模的时候，可能两方面的数据库都会用到，同时还可能会用到像Key-Value缓存数据库等进行混合来实现整体的数据库业务效果。在这个过程之中，DBA扮演着非常神奇的角色，此时的DBA不只需要去做普通的SQL系统管理，而且还需要管理NoSQL以及Key-Value数据库，而且很多时候整体系统监控以及系统维护都需要由DBA进行完整地支撑，此时的DBA可以称之为“神奇的DBA”，因为他什么都需要管。

 

       当业务进一步发展到下一个阶段时又会是什么情况呢？其实很多公司在刚刚起步时往往只有一个项目，当公司的业务发展到一定规模的时候，项目也会逐步地增加。因此，每一个项目都将会使用一整套数据库结构，而在这个时候项目也会不断地提升和增长，每个项目会使用单独整体数据库结构，这时候的数据库管理员DBA就不再是单个人了，往往会有2到3个DBA，而且他们每个人应该都能够独当一面，并且应该具有完整的架构经验。正是在这个时候才是对于企业的比较大的挑战，大家都知道在技术人员的职业发展生涯当中，技术人员都是希望能够承载更多的工作或者让自己的职业生涯获得更大的发展，所以在这个过程之中往往能够形成企业与技术人员本身之间认知差异的博弈。很多时候如果企业发展的速度跟不上技术人员的技术成长速度，技术人员就很可能尝试跳槽或者寻找其他的工作，当技术专家离开企业的时候，就会使得企业的进一步发展受到阻碍。

 

数据库容灾：两地N中心

       在系统架构越发复杂的情况下，企业所遇到的不仅是人员的问题，在进行数据库架构发展演变的过程当中，企业还会遇到另外的一个问题：在业务发展到一定阶段之后，往往需要产生更多的数据架构的逻辑，包括在业务要求之下以及在监管部门的要求之下，可能需要实现像两地三中心等等一系列复杂的架构，这也会使得业务的运行成本成倍地提高。因为在单独的机房之下进行数据库集群的搭建会是比较方便的，而在实现像两地三中心这样的架构的时候，还需要去购买同城光纤以及异地光纤等等基础设施，这部分大量的费用也往往使得很多的企业在这样的位置上处于停步状态。

 

       如果企业希望能够进一步地突破发展瓶颈往往还需要使用更多的数据库架构，例如需要使用到OLAP的数据库仓库以及大数据的海量分析等。在这样的情况下，DBA团队以及整体系统的构建成本都将会更大地提升。

 

阿里云 云数据库：产品理念

       前面为大家介绍了一个企业从小型到中型或者说是到达爆发期以及更进一步的上升期的过程之中，对于数据库可能会出现什么样的要求。接下来为大家分享在阿里云的云数据库中希望为大家提供什么样的产品理念。

 

1. 首先，大家可以看到在业务各个不同的发展过程当中需要使用到不同的数据库、数据库的组合以及不同的数据库产品的层级，因此阿里云会设计自己的数据库产品让不同的层级都可以适用。

2. 第二点，阿里云会尽可能地去帮助企业提高自身的发展效率，也就是让企业非常方便地扩展自己的资源，让这些资源为用户直接提升生产效率。

3. 第三点，阿里云会直接降低整个架构的构建门槛，在传统企业架构之下，从单个机房变到多个机房或者从单个服务器变为多个服务器的时候，会存在很多技术以及生产成本的门槛限制，阿里云希望能够通过云数据库整体的底层架构，包括飞天架构将这些门槛降到最低。

4. 最后要提到的也是本次中最希望分享的一点就是：在云数据库之上，阿里云所希望达到的终极目标是解放DBA。其实通常情况下在一家公司里面，DBA很多时候往往不会受到很大的重视，因为在企业中DBA日常所做的工作往往是像部署、备份等等一系列运维工作，而这些工作将会占据DBA 50%到60%的时间，而这些工作却没有办法去为企业带来直接的生产效率。而在云数据库上面，通过云架构的自动化管理来完成所有的运维工作，DBA可以将自己更多的时间投入到业务架构的优化之中。什么是业务架构的优化呢？比如表结构设计的不合理需要进行优化，一些SQL存在性能问题需要优化，以及某些设计在业务发展的过程中已经不合时宜需要优化，所有的这些优化都是DBA应该去做的。而DBA也是最容易发展成为企业核心架构师的一群人，他们的工作应该更多地为企业真正地产能以及技术能力的输出发挥贡献，而不是去过多地关注每一天的部署、备份这样繁琐的运维工作。

       以上就是在设计云数据库过程中，大家所看到的市场需求情况以及阿里云的云数据库产品设计理念。

二、永恒不变的话题：需求

       其实前面所讲的长篇故事都是需求，每一个需求都需要得到满足。那么面对这些需求，阿里云的云数据库是如何一步一步解决的呢？

分层：扩展边界覆盖不同层级的用户

       第一步就是进行分层。之前使用过阿里云数据库的朋友可能会有印象，阿里云最初推出的数据库版本叫做高可用版本，这应该也是当前阿里云数据库里面使用量最多的版本。在这个版本里面会有两个数据库服务器，一主一备，他们提供了非常好的性能并且能够快速地进行切换，然而在这样的架构之下，成本实际上翻了一倍。很多的用户，特别是入门级别的刚开始使用云数据库的用户，往往不需要主备的数据库系统，而是希望投入更低的成本，这个时候阿里云就推出了云数据库的基础版。基础版的架构只有单个节点，基础版的推出使得用户的成本得以降低。同时需要注意的一点就是：在单节点或者说是基础版之下，高可用到底是如何保障的。其实大家可以放心，在基础版之下，阿里云同样提供了高可用的保障，只不过没有两个节点的保障而是将整个数据库运行在飞天架构之上，如果数据库出现问题或者数据库所在的主机出现了问题，飞天系统会自动寻找新的主机、新的节点将整个系统运行起来，只不过切换时间会稍微长一些，但是不会出现像系统长期断开的情况。

 

       再进一步，很多高级用户，特别是在金融界中的用户所要求的数据稳定性以及对于数据故障时的RPO都会有更高的要求，这时候阿里云就提供了金融版数据库。在两节点的基础之上可能会扩展到三节点甚至更多节点的集群的应用。在做了这样的工作之后，阿里云实际上是拓展了云数据库产品的边界，从刚开始阿里云数据库只有高可用双节点版本，扩展到单节点的基础版以及多节点的金融版，使得不同需求的用户可以获取到他们所需要的各种不同规格的云数据库服务。

效率：化繁为简，释放工作量

       在有了数据库的运行环境之后，其实大家可以看到各个用户往往都会有自己不同时段的类似于促销、活动等的一些业务，在这些业务之中，用户的查询要求往往是非常高的，会出现非常高的查询峰值，这时可以通过只读节点来进行解决。在阿里云中就直接提供了只读请求的实例，而不需要用户自己再去搭建只读实例了。如果大家自己搭建过数据库，就可能对于这个过程有所体会，当搭建一个只读实例时往往需要去构建或者配置3到4个配置文件，而且各个主机之间，包括用户权限以及密码的同步等都需要进行规划，这个过程对于初级的DBA而言是比较困难和麻烦的事情，而且与此同时还需要保障整个系统在业务发展的过程中的稳定运行。

 

       在阿里云上面，实际上会将构建只读实例的过程更加简化，因为阿里云数据库本身的底层系统架构会自动化地进行所有的配置以及业务确认，用户只需要在界面上面点击按钮并添加一个只读实例就能够将只读实例建立完成，而且允许用户建立5个甚至10个只读实例。在这个过程中，大家会发现虽然阿里云提供了直接添加只读实例的功能，而且完成了其中的同步，但是业务方也就是如上图所示的云服务器ECS上面的应用还是需要通过把读写请求和只读请求进行业务分离，这对于数据库的开发是存在入侵性的，也就是说原来开发的程序只需要一个数据库进行操作就可以了，而由于当前使用了只读实例，则需要将所有的只读查询都单独地拎出来让其去访问其他节点，这一点对于程序的入侵性可能会是非常大的，这就可能会使得很多的开发者无法直接使用到阿里云的只读实例了，或者有很多的工作需要重新进行开发。

效率： 化繁为简，释放工作量， 直接支持读写分离

      针对上述的问题，阿里云的数据库在发展的过程中也会收到用户的需求和报告，因此阿里云数据库就进行了进一步的优化。在只读实例的运行条件之下，阿里云数据库还进一步地提供了读写分离的IP访问，其主要会在Proxy业务层底下实现所有SQL的收集，并且对于所有的收集到的SQL进行分类，如果发现SQL操作既有读操作也有写操作的时候，也就是读写操作在同一个事务里面的时候，会将这些操作自动地提交到主节点。而如果当发现事务中所有的操作都是读操作的时候，Proxy层就会将这些只读的查询平均地分配到各个只读节点。这意味着应用程序不需要改变本身的代码，阿里云就能够自动地为用户实现读写分离的工作，而业务方不需要去修改自己的业务代码。通过这样查询的读写分离的功能，可以非常好地简化本身开发以及维护的工作量。

 

效率：新一代关系型数据库演进

       其实除了上面所说的这些，阿里云数据库所做的工作还远没有结束。如果大家留意了阿里云最近的新闻或者最新的产品动向就会知道，在阿里云数据库最新的版本中提供了关系型数据库PolarDB的集群，这款产品预计将在十月份推出，在这款产品上面不单单解决了读写分离的问题，也会使用到最新的硬件技术去达到比较好的读写资源比。在读写分离的业务之下，当主节点有数据写入的时候，所有的数据需要同步到每一个只读节点，而在主节点和只读节点之间或许会存在网络延迟，这些网络延迟可能会导致从主节点读出的数据和从只读节点读出的数据出现不一致的情况，而这是需要业务方或者开发人员知晓并通过业务进行保障的。

 

       而在PolarDB中，阿里云尝试使用了一种新型的架构，通过RDMA网络会将下层的各个存储节点进行整合管理，通过分布式Raft协议实现完整的底层集群。这样所能达到的效果就是当主节点进行数据写入的过程中，底层的Raft协议的数据集群会把数据自动打散到三个或者以上的存储节点上面，同时这些数据一旦写入，在其他的只读节点上就可以读到。因此可以看到在这样的架构之下，减少了多节点之间的数据复制，网络带宽的消耗会更低，同时主节点和只读节点之间网络数据延迟基本为零，也就是说只要数据写入了，只读节点就能够读取到，符合ACID的完整原则。所有的数据在存放的时候都不会少于三节点，任何一个节点或者数据模块出现故障的时候，都不会造成数据丢失。在这样的架构之下，可以进一步使得数据库的使用者获取更高的性价比。

门槛： 综合系统管理门槛高

       以上分享的是在数据库关系的演进中阿里云提供的一些思考和产品，而下面会分享另外一个问题。如下图所示，当一个业务发展到比较庞大的数据规模时，存下来的业务数据还需要进行产品的分析，比如当数据量已经存放到两三年的时候，企业主肯定希望能够通过这两三年沉淀的数据来进行业务分析。这个时候，在传统的架构之下，往往会向如图中所看到的把数据通过ETL，也就是数据导入到数据仓库，并在数据仓库之上再去做OLAP的业务分析。同时由于数据量越来越大，因此也需要通过分布式的数据库中间件实现一个动作，也就是将整个的数据库进行分库分表式的管理。当然，这样的功能在互联网圈已经使用的非常多了，但是大家会发现下图中存在四个蓝色的管理标记，这是因为在每个层级当中都需要对于数据库进行一些单独的人为操作和人为干预。

 

简化分库分表管理，一份数据实现OLTP+OLAP=HTAP

       可以看到在上图的整个运作流程中，每一个节点上面都需要进行配置和规划，而这些所有的配置和规划都需要消耗时间。还有一点就是业务系统是OLTP的系统，所有的在线的业务都在上图中左侧的OLTP系统里面，当需要进行分析的时候并不能直接在业务系统进行分析，因为这会影响业务系统本身的性能，因此需要再进行一次数据的抽取，将数据抽取到OLAP的数据仓库中，然后再去做查询。这样动作使得数据多了冗余，而且所有的数据无法实现所谓的“T+0”的实时分析，在这种情况下，所有的操作以及运维管理会消耗更多的使用资源。因此，在阿里云中也提供了HybridDB for MySQL的架构。通过HybridDB for MySQL架构的数据库，可以实现将上图中所看到的整个数据链路，包括分布式数据库中间件以及数据仓库都整合到一个数据库中，这个数据库可以直接实现OLTP的事务操作，同时也接受OLAP的数据分析处理，而且整个系统也是分布式系统。

 

       在这个系统之上最大的好处就是用户不再需要去分别地管理两个业务系统：OLTP系统和OLAP系统。与此同时还可以实现计算和存储的分离操作，如果计算资源不足还可以单独地增加计算资源使得查询速度更快。而且整个系统将会直接兼容MySQL的生态，因此用户不需要过多地修改自己数据库查询的业务逻辑，可以直接使用MySQL的客户端以及各种工具来连接到数据库上面去进行操作。因此，在HybridDB for MySQL数据库中实现了一种新的形态叫做HTAP，实际上就是在同一个数据库里面不仅可以进行OLTP操作，还可以进行OLAP操作，而且其空间可以扩展到超过PB的级别。

释放：安心原于透明，主动的提醒

       阿里云的数据库产品除了提供了以上的功能以外，为了使得DBA更加省心和安心，绝对离不开的就是对于各种资源的监控以及对于引擎的监控。在这里不做过多的解析，因为在产品上大家可以看到，阿里云已经把自己原来在天猫、淘宝等的各方面的经验进行了整体的输出，会提供非常深度的包括TPS、QPS以及缓存命中率等等一系列的监控，而且可以产生直接的图表。在报警方面，可以通过云监控设置所需要的报警，当水位超过了一定的范围之后可以直接发送短信、邮件甚至通过电话的告警来提醒DBA进行扩容或者及时地发现问题。更进一步，阿里云还将会提供云DBA的协助工具，甚至还会为用户提供Index推荐以及像告警错误业务分析等服务。

 

释放用户成本：中小企业也可以获得高端服务

       在企业发展的过程中，随着业务不断地发展，需要更好地保障业务的连续稳定性。对于很多企业而言，数据库中心里面往往只有一个IDC的机房，然而如果这个IDC机房出现断电或者故障的时候，就没有办法进行更进一步的业务操作。阿里云在数据库体系之下已经完成如下图所示的整体架构。当大家看到阿里云数据库产品购买页的时候会发现阿里云不仅提供了单中心的双节点模型，还在很多地域中提供了多可用区的模型。多可用区模型就是把主节点和备用节点放在一个城市的两个不同的可用区上，也就是说用户的实例只购买了一个，但是在部署的时候却部署在了一个城市的两个中心，一旦主中心出现整体故障的时候，用户的业务依然可以通过切换到备用中心继续提供服务。大家可以想象，如果没有云架构的支撑，依靠自己搭建多可用区模型的时候，可能会需要非常高的业务成本，这是因为同城之间光纤搭建的费用是非常昂贵的。

 

       除此之外，阿里云还会为企业提供跨数据中心的访问。很多用户可能会说现在自己的企业还不大，还不需要到这样的业务保护，但是在这里想告诉大家的是这样的观点往往是不正确的。如上图所示，当前在同城双中心灾备里面不需要增加用户的成本，那么就完全可以在企业发展之初就使用这样的架构，因为在企业发展的过程中，任何一个技术上的故障或者服务的宕机往往会造成后续更大的损失。所以如果能够提前在不增加过多成本的情况下实现企业同城容灾以及跨地域业务，往往能够对于企业业务的发展提供更大的帮助。在阿里云上，其实基于阿里云本身的技术架构就可以为用户更好地释放这部分成本，而用户不需要自己搭建光纤就可以复用所有现有的网络，这使得企业在初始阶段就可以像大企业一样使用到所有的数据库的高端服务。

       大家可以看到，在阿里云数据库业务中比较注重的就是如下图所示的五点：如何帮助用户节省成本，如何使数据库的性能达到更高，如何维护业务的连续性，以及业务扩展能力和数据容灾等。而这一切的能力都是通过云托管平台进行规划和赋能的。

 

三、生态的力量

       在以上的内容中为大家分享了云数据库上的产品驱动、阿里云数据库提供了什么样的保护以及阿里云数据库是如何承载用户需求的。接下来为大家分享数据库生态的力量。

阿里云MySQL生态体系

       当阿里云最初去规划数据库产品的时候，首先做的产品就是MySQL，因为在当时MySQL也是使用最为广泛的数据库，特别是在互联网业界。但是在不断的发展过程中也发现不断有更多的互联网业务以及企业客户会进入到阿里云体系上来，所以阿里云需要有更多的数据库类型来对这些用户进行支撑。很多的用户不仅仅需要使用SQL的数据库，还会需要做缓存并且需要进行数据分析。在下图中，大家可以看到阿里云逐步地增加更多的引擎，按照DB-Engines的统计，目前阿里云数据库已经能够覆盖70%的数据库产品，这也是由市场所决定的。而这些产品中的部分产品已经开始走上了阿里云自研的道路，像之前提到的HybridDB for MySQL以及PolarBD等。当然，除了自研产品之外，阿里云也会兼顾到市场上面其他用户的需求，也会提供像SQL Server、HBase、MongoDB以及Redis等一系列的数据库产品，这就是阿里云目前的数据库产品整体大生态。

 

       当然我们也可以看到另外一个生态模型，举个例子就是目前很多的用户都在使用MySQL的数据库，在MySQL数据库之下，阿里云会提供多种不同的数据库形态和模式，让用户可以完全沉浸在MySQL整体生态链路之中。如下图左侧所示，RDS for MySQL提供了基础版、高可用版以及金融版，使得用户可以快速地进行业务的使用，进一步在未来阿里云数据库将会发布的PolarDB也会率先地支持MySQL的引擎，让具有几十TB数据或者上百TB数据的并且想要使用更加稳定的数据库系统的大型客户能够非常好地解决遇到的问题。同时，很多人会认为MySQL上面并不适合去做OLAP业务分析工作，但是如果所有的开发人员都是熟悉MySQL的并且不希望跳出MySQL的框架而且希望去基于MySQL实现业务分析操作，这样通过HybridDB for MySQL就能够继续去承载这样的业务，而且在这个系统上面还可以同时整合OLTP和OLAP。因此，在数据库产品的规划过程之中，阿里云会充分地考虑用户本身的感情因素，当用户特别倾向于某一数据库的时候，阿里云就会针对于这个数据库做出一系列的产品，使得用户可以通过统一的技术去完成所有的技术工作，而没必要将所有的工作分散到不同的数据库并使用不同的SQL模型进行重新开发。

 

阿里云PostgreSQL生态系统

       除了MySQL生态之外，近年PostgreSQL生态系统也是非常火热的，阿里云数据库团队在PostgreSQL生态上也沿用了和MySQL生态中相同的思路。阿里云不只是为用户提供一个单独的RDS for PostgreSQL的系统，因为PostgreSQL和Oracle比较相似，所以还会针对基于PostgreSQL的增强版本——RDS for PPS来协助Oracle用户来进行数据迁移。同时阿里云也会推出针对于数据仓库的HybridDB for PostgreSQL来实现数据分析。而且所有的这些体系都可以通过外部表的形式去操作OSS，甚至在OSS上面放一份数据，各个不同的OLTP、OLAP数据库产品都可以对于OSS上的数据进行读写操作和分析应用来实现整体生态链的运行过程。

 

四、SQL+NoSQL+Big Data一站式解决数据打通

       除了上述提到的阿里云为拆分的MySQL和PostgreSQL生态链打造的独特的方案之外，阿里云数据库还会与阿里云的各种数据链路的软件进行整合规划。在下面这张图中，大家可以看到，通过阿里云的DTS以及CDP这样数据工具，可以将前端的Key-Value的缓存层、OLTP、NoSQL、分析以及Big Data进行整体数据的打通。云上的数据可以通过比较方便的方式加上业务架构的模型开发就可以实现对于所有数据在各个数据产品之间的无缝打通，并实现了整体的数据交换。交换完数据之后就可以让各个数据系统更大地发挥自己的业务价值。

 

       如今，数据库其实已经是达到了百花齐放的状态，目前有非常多的引擎以及不同的业务规划。而阿里云的云数据库依旧秉持着这样的几点产品理念：阿里云会为用户提供不同层级的数据库产品，让用户可以实现不同的需求，不同的用户可以购买到不同价格、可靠性以及性能的数据库产品。阿里云希望通过云平台的打通实现用户数据库构建的最快速的发展效率，而不希望因为架构的改变或者演变，而去等待几周甚至一个月的规划，而希望通过点几下按钮就能够得到新的数据库或者搭建出新的集群，并与原有的集群进行无缝连接。同时，在成本上面，因为得到了云基础架构的保证，用户没有必要自己去再搭建昂贵的光纤或者机柜等硬件设备，而可以直接去生产实例。用户所购买的云数据库其实代表了很多东西，包括软件、机器、机架以及网络等，而这一系列的东西阿里云已经搭建好了，用户可以根据自己的需求直接去购买一个月、两个月或者一年的使用量级，而没有必要去一次性地进行成本的支付。最后，阿里云希望通过自动化的部署、管理和监控，释放DBA的工作量，让DBA免于去被部署、管理等运维工作所缠绕，让他们把更多的时间和经历去投入到为企业进行业务优化，用技术为企业创造更多的核心生产力上面去。

本文为云栖社区原创内容，未经允许不得转载，如需转载请发送邮件至[e-mail]