125
云数据库产品及架构设计背后的考量
摘要：8月24日，阿里云数据库技术峰会到来，本次技术峰会邀请到了阿里集团和阿里云数据库老司机们，为大家分享了一线数据库实践经验和技术干货。在本次峰会上，阿里云数据库高级产品专家萧少聪（铁庵）介绍了全体系阿里云数据库产品并对于阿里云数据库产品的实现架构进行了分享，帮助大家了解了阿里云全数据库产品体系能解决哪些实用场景的问题，同时帮助大家了解其解决的原理。以下内容根据演讲嘉宾现场视频以及PPT整理而成。
本次分享将主要介绍阿里云是如何设计云数据库产品的架构的，以及在云数据库产品的架构设计背后的故事。本次的分享将不会非常深入技术底层细节，而是希望通过分享使得大家了解在使用云数据库时应该如何去规划，以及阿里云在设计云数据库产品的时候存在什么样的思考。
一、云数据库的市场背景
多产品类型混合
在市场上面，大家可以看到类型非常多样的数据库产品。如果大家今天还是在使用像SQL Server或者MySQL这样单独的关系型数据库，那么可能业务所覆盖的场景还是比较有限的。而往往在一家中型或者比较大型的公司里面，已经开始用到很多不同的数据库产品了。
系统架构越发复杂
如上图所示，通常情况下，在业务刚开始的时候使用的是一个SQL数据库或者NoSQL数据库，但是随着业务慢慢的发展就会用到Key-Value的缓存数据库，再之后可能就会发展到数据仓库，同时也可能发展到大数据的系统。
接下来为大家介绍一家公司从小型企业逐步成长为大型企业的过程中的数据库架构设计的发展步骤以及在运作过程中每个阶段的数据库演化情况。如下图所示，在初始阶段，整个数据库架构的结构是比较简单的，图中仅有3台服务器，这意味着公司在刚刚开始的时候可能只有几台数据库服务器，它们可能是SQL的系统，也可能是NoSQL的系统。此时DBA以及管理人员不需要去做过多的结构使用分析。然而，在进行管理的过程中，DBA往往会身兼多职，在这个时候的DBA可能在管理数据库的同时也在做开发以及对于操作系统的运维工作。
数据库容灾：两地N中心
在系统架构越发复杂的情况下，企业所遇到的不仅是人员的问题，在进行数据库架构发展演变的过程当中，企业还会遇到另外的一个问题：在业务发展到一定阶段之后，往往需要产生更多的数据架构的逻辑，包括在业务要求之下以及在监管部门的要求之下，可能需要实现像两地三中心等等一系列复杂的架构，这也会使得业务的运行成本成倍地提高。因为在单独的机房之下进行数据库集群的搭建会是比较方便的，而在实现像两地三中心这样的架构的时候，还需要去购买同城光纤以及异地光纤等等基础设施，这部分大量的费用也往往使得很多的企业在这样的位置上处于停步状态。
阿里云 云数据库：产品理念
前面为大家介绍了一个企业从小型到中型或者说是到达爆发期以及更进一步的上升期的过程之中，对于数据库可能会出现什么样的要求。接下来为大家分享在阿里云的云数据库中希望为大家提供什么样的产品理念。
- 首先，大家可以看到在业务各个不同的发展过程当中需要使用到不同的数据库、数据库的组合以及不同的数据库产品的层级，因此阿里云会设计自己的数据库产品让不同的层级都可以适用。
- 第二点，阿里云会尽可能地去帮助企业提高自身的发展效率，也就是让企业非常方便地扩展自己的资源，让这些资源为用户直接提升生产效率。
- 第三点，阿里云会直接降低整个架构的构建门槛，在传统企业架构之下，从单个机房变到多个机房或者从单个服务器变为多个服务器的时候，会存在很多技术以及生产成本的门槛限制，阿里云希望能够通过云数据库整体的底层架构，包括飞天架构将这些门槛降到最低。
- 最后要提到的也是本次中最希望分享的一点就是：在云数据库之上，阿里云所希望达到的终极目标是解放DBA。其实通常情况下在一家公司里面，DBA很多时候往往不会受到很大的重视，因为在企业中DBA日常所做的工作往往是像部署、备份等等一系列运维工作，而这些工作将会占据DBA 50%到60%的时间，而这些工作却没有办法去为企业带来直接的生产效率。而在云数据库上面，通过云架构的自动化管理来完成所有的运维工作，DBA可以将自己更多的时间投入到业务架构的优化之中。什么是业务架构的优化呢？比如表结构设计的不合理需要进行优化，一些SQL存在性能问题需要优化，以及某些设计在业务发展的过程中已经不合时宜需要优化，所有的这些优化都是DBA应该去做的。而DBA也是最容易发展成为企业核心架构师的一群人，他们的工作应该更多地为企业真正地产能以及技术能力的输出发挥贡献，而不是去过多地关注每一天的部署、备份这样繁琐的运维工作。
二、永恒不变的话题：需求
其实前面所讲的长篇故事都是需求，每一个需求都需要得到满足。那么面对这些需求，阿里云的云数据库是如何一步一步解决的呢？
分层：扩展边界覆盖不同层级的用户
第一步就是进行分层。之前使用过阿里云数据库的朋友可能会有印象，阿里云最初推出的数据库版本叫做高可用版本，这应该也是当前阿里云数据库里面使用量最多的版本。在这个版本里面会有两个数据库服务器，一主一备，他们提供了非常好的性能并且能够快速地进行切换，然而在这样的架构之下，成本实际上翻了一倍。很多的用户，特别是入门级别的刚开始使用云数据库的用户，往往不需要主备的数据库系统，而是希望投入更低的成本，这个时候阿里云就推出了云数据库的基础版。基础版的架构只有单个节点，基础版的推出使得用户的成本得以降低。同时需要注意的一点就是：在单节点或者说是基础版之下，高可用到底是如何保障的。其实大家可以放心，在基础版之下，阿里云同样提供了高可用的保障，只不过没有两个节点的保障而是将整个数据库运行在飞天架构之上，如果数据库出现问题或者数据库所在的主机出现了问题，飞天系统会自动寻找新的主机、新的节点将整个系统运行起来，只不过切换时间会稍微长一些，但是不会出现像系统长期断开的情况。
效率：化繁为简，释放工作量
在有了数据库的运行环境之后，其实大家可以看到各个用户往往都会有自己不同时段的类似于促销、活动等的一些业务，在这些业务之中，用户的查询要求往往是非常高的，会出现非常高的查询峰值，这时可以通过只读节点来进行解决。在阿里云中就直接提供了只读请求的实例，而不需要用户自己再去搭建只读实例了。如果大家自己搭建过数据库，就可能对于这个过程有所体会，当搭建一个只读实例时往往需要去构建或者配置3到4个配置文件，而且各个主机之间，包括用户权限以及密码的同步等都需要进行规划，这个过程对于初级的DBA而言是比较困难和麻烦的事情，而且与此同时还需要保障整个系统在业务发展的过程中的稳定运行。
效率： 化繁为简，释放工作量， 直接支持读写分离
针对上述的问题，阿里云的数据库在发展的过程中也会收到用户的需求和报告，因此阿里云数据库就进行了进一步的优化。在只读实例的运行条件之下，阿里云数据库还进一步地提供了读写分离的IP访问，其主要会在Proxy业务层底下实现所有SQL的收集，并且对于所有的收集到的SQL进行分类，如果发现SQL操作既有读操作也有写操作的时候，也就是读写操作在同一个事务里面的时候，会将这些操作自动地提交到主节点。而如果当发现事务中所有的操作都是读操作的时候，Proxy层就会将这些只读的查询平均地分配到各个只读节点。这意味着应用程序不需要改变本身的代码，阿里云就能够自动地为用户实现读写分离的工作，而业务方不需要去修改自己的业务代码。通过这样查询的读写分离的功能，可以非常好地简化本身开发以及维护的工作量。
其实除了上面所说的这些，阿里云数据库所做的工作还远没有结束。如果大家留意了阿里云最近的新闻或者最新的产品动向就会知道，在阿里云数据库最新的版本中提供了关系型数据库PolarDB的集群，这款产品预计将在十月份推出，在这款产品上面不单单解决了读写分离的问题，也会使用到最新的硬件技术去达到比较好的读写资源比。在读写分离的业务之下，当主节点有数据写入的时候，所有的数据需要同步到每一个只读节点，而在主节点和只读节点之间或许会存在网络延迟，这些网络延迟可能会导致从主节点读出的数据和从只读节点读出的数据出现不一致的情况，而这是需要业务方或者开发人员知晓并通过业务进行保障的。
门槛： 综合系统管理门槛高
以上分享的是在数据库关系的演进中阿里云提供的一些思考和产品，而下面会分享另外一个问题。如下图所示，当一个业务发展到比较庞大的数据规模时，存下来的业务数据还需要进行产品的分析，比如当数据量已经存放到两三年的时候，企业主肯定希望能够通过这两三年沉淀的数据来进行业务分析。这个时候，在传统的架构之下，往往会向如图中所看到的把数据通过ETL，也就是数据导入到数据仓库，并在数据仓库之上再去做OLAP的业务分析。同时由于数据量越来越大，因此也需要通过分布式的数据库中间件实现一个动作，也就是将整个的数据库进行分库分表式的管理。当然，这样的功能在互联网圈已经使用的非常多了，但是大家会发现下图中存在四个蓝色的管理标记，这是因为在每个层级当中都需要对于数据库进行一些单独的人为操作和人为干预。
简化分库分表管理，一份数据实现OLTP+OLAP=HTAP
可以看到在上图的整个运作流程中，每一个节点上面都需要进行配置和规划，而这些所有的配置和规划都需要消耗时间。还有一点就是业务系统是OLTP的系统，所有的在线的业务都在上图中左侧的OLTP系统里面，当需要进行分析的时候并不能直接在业务系统进行分析，因为这会影响业务系统本身的性能，因此需要再进行一次数据的抽取，将数据抽取到OLAP的数据仓库中，然后再去做查询。这样动作使得数据多了冗余，而且所有的数据无法实现所谓的“T+0”的实时分析，在这种情况下，所有的操作以及运维管理会消耗更多的使用资源。因此，在阿里云中也提供了HybridDB for MySQL的架构。通过HybridDB for MySQL架构的数据库，可以实现将上图中所看到的整个数据链路，包括分布式数据库中间件以及数据仓库都整合到一个数据库中，这个数据库可以直接实现OLTP的事务操作，同时也接受OLAP的数据分析处理，而且整个系统也是分布式系统。
释放：安心原于透明，主动的提醒
阿里云的数据库产品除了提供了以上的功能以外，为了使得DBA更加省心和安心，绝对离不开的就是对于各种资源的监控以及对于引擎的监控。在这里不做过多的解析，因为在产品上大家可以看到，阿里云已经把自己原来在天猫、淘宝等的各方面的经验进行了整体的输出，会提供非常深度的包括TPS、QPS以及缓存命中率等等一系列的监控，而且可以产生直接的图表。在报警方面，可以通过云监控设置所需要的报警，当水位超过了一定的范围之后可以直接发送短信、邮件甚至通过电话的告警来提醒DBA进行扩容或者及时地发现问题。更进一步，阿里云还将会提供云DBA的协助工具，甚至还会为用户提供Index推荐以及像告警错误业务分析等服务。
释放用户成本：中小企业也可以获得高端服务
在企业发展的过程中，随着业务不断地发展，需要更好地保障业务的连续稳定性。对于很多企业而言，数据库中心里面往往只有一个IDC的机房，然而如果这个IDC机房出现断电或者故障的时候，就没有办法进行更进一步的业务操作。阿里云在数据库体系之下已经完成如下图所示的整体架构。当大家看到阿里云数据库产品购买页的时候会发现阿里云不仅提供了单中心的双节点模型，还在很多地域中提供了多可用区的模型。多可用区模型就是把主节点和备用节点放在一个城市的两个不同的可用区上，也就是说用户的实例只购买了一个，但是在部署的时候却部署在了一个城市的两个中心，一旦主中心出现整体故障的时候，用户的业务依然可以通过切换到备用中心继续提供服务。大家可以想象，如果没有云架构的支撑，依靠自己搭建多可用区模型的时候，可能会需要非常高的业务成本，这是因为同城之间光纤搭建的费用是非常昂贵的。
大家可以看到，在阿里云数据库业务中比较注重的就是如下图所示的五点：如何帮助用户节省成本，如何使数据库的性能达到更高，如何维护业务的连续性，以及业务扩展能力和数据容灾等。而这一切的能力都是通过云托管平台进行规划和赋能的。
三、生态的力量
在以上的内容中为大家分享了云数据库上的产品驱动、阿里云数据库提供了什么样的保护以及阿里云数据库是如何承载用户需求的。接下来为大家分享数据库生态的力量。
阿里云MySQL生态体系
当阿里云最初去规划数据库产品的时候，首先做的产品就是MySQL，因为在当时MySQL也是使用最为广泛的数据库，特别是在互联网业界。但是在不断的发展过程中也发现不断有更多的互联网业务以及企业客户会进入到阿里云体系上来，所以阿里云需要有更多的数据库类型来对这些用户进行支撑。很多的用户不仅仅需要使用SQL的数据库，还会需要做缓存并且需要进行数据分析。在下图中，大家可以看到阿里云逐步地增加更多的引擎，按照DB-Engines的统计，目前阿里云数据库已经能够覆盖70%的数据库产品，这也是由市场所决定的。而这些产品中的部分产品已经开始走上了阿里云自研的道路，像之前提到的HybridDB for MySQL以及PolarBD等。当然，除了自研产品之外，阿里云也会兼顾到市场上面其他用户的需求，也会提供像SQL Server、HBase、MongoDB以及Redis等一系列的数据库产品，这就是阿里云目前的数据库产品整体大生态。
阿里云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进行整体数据的打通。云上的数据可以通过比较方便的方式加上业务架构的模型开发就可以实现对于所有数据在各个数据产品之间的无缝打通，并实现了整体的数据交换。交换完数据之后就可以让各个数据系统更大地发挥自己的业务价值。
最后更新：2017-09-02 01:33:31