【IT名人堂】何云飞：阿里云数据库的架构演进之路

原文转载自：IT168 

?

如果说淘宝革了零售的命，那么DT革了企业IT消费的命。在阿里巴巴看来，DT时代，企业IT消费的模式变成了“云服务+数据”，阿里云将打造一个像淘宝电商一样多方共赢的云生态。而作为阿里云庞大帝国的重要成员，阿里云RDS为社交网站、电子商务网站、手机App提供了可靠的数据存储服务。好的架构不是设计出来的，而是演化出来的，那么RDS经历了怎样的架构演进？本期名人堂我们邀请到了阿里云RDS首席产品架构师何云飞，为我们揭秘RDS的今世前生。

皮皮（Q1）：您专注于关系型数据库领域10年了，精通多种主流数据库，比如MySQL，SQLSERVER，Oracle等，这些主流数据库是否有相通之处？能否结合您的经历和我们分享下学习这些数据库有木有捷径可走？

     何云飞（A1）：学习是一个触类旁通，举一反三的过程，对我而言，数据库也同样如此。一旦你学会了一种数据库，其它数据库就能驾轻就熟了。深入学会了数据库最核心的三个问题，开发、优化、管理维护，你就能所向披靡了。

开发阶段，我们一般关注的是：

1）如何快速得到一个可用环境，这里你可以先不考虑一些参数配置，只要数据库运行起来能让你访问就好；

2）如何用SQL去存取你的第一行数据；这里你可能会关注：

｜SQL用法，特别是查询JOIN的写法；

｜数据类型，常用的有字符串类型、数值类型、日期类型、文本类型；

｜运算符，如算术运算符、比较运算符，这里要特别注意运算符的优化级；

｜常用函数，常用的字符串、数值、日期相关以及转换函数等；

这些一般在数据库的用户手册里可以找到，常用的你也许需要记录在你的笔记本里。

一旦你掌握了如何熟练使用SQL语言，你可能无法容忍一些运行特别慢的SQL语句，怎么拧出这些运行缓慢的SQL语句？有木有秘诀来扫除障碍呢？这里我想和大家分享几点：

1）查看执行计划并找到SQL慢的原因；

2）如何设计合理的索引并让大部分SQL能够用到它；

3）选择什么样的字段类型存储会更高效；

4）数据库内存等参数配置会让你的数据库跑得更快；

通过这个环节的思考，你会在执行过程中总结出一些应用场景标准结构设计和常用SQL写法，如果看到SQL语句你就知道哪些字段需要建索引，那就更好了。如果你是高手，你还会研究数据库多版本的实现，锁的模式等高级问题。慢慢的，你的数据库里存储了大量的数据，应用也正式上线，一切都很顺利，为企业也带来了很大的价值。这个时候你会觉得数据库非常的重要。要是数据库挂了怎么办，多长时间恢复是可以接受的，硬盘坏了我该如何恢复等、这一系列问题会接踵而来，所以下一个环节数据库维护和管理显得至关重要，搞定以下五大问题，面对数据库故障问题你就可以从容应对：

1） 如果保证数据不丢失；

2） 数据库的高可用环境设计与搭建；

3） 数据库的备份和日志的管理 ；冷备还是热备，全量还是增量，备份需要保留多久，备份有效性检查；

4） 如何快速恢复误删的数据；需要做到基于时间点的恢复；

5） 数据库权限的管理等；

与其花许多时间和精力去凿许多浅井，不如花同样的时间和精力去凿一口深井。目前业界最容易上手的数据库当属开源的MySQL，除了在线手册，我们前辈也留给大家不少资料，比如：《深入浅出MySQL》，《MySQL技术内幕Innodb存储引擎》，《高性能MySQL》等。

皮皮（Q2）：您是RDS系统设计和开发的核心创始人之一，为什么会在2011年开发这套系统？能不能和我们分享下当时的背景？

何云飞（A2）：2009年9月10日成立阿里云计算有限公司，我们是第一批员工，说实话当时每次听王博士讲云计算都不太听得懂，作为DBA的我们不知道该如何去快速拥抱云时代，冥冥之中真有些云深不知处的感慨。到了2010年，随着基础建设的推进和业务的发展，云计算变得势不可挡，这股强大的力量也曾让我们这些DBA们忧心忡忡，云环境里到底选择SQL还是NoSQL？未来是否意味着NoSQL当道，关系数据库会日薄西山？ 再加上阿里推出飞天分布式存储引擎，我们朦朦胧胧的觉得NoSQL将会吞没关系数据库的光芒，似乎感觉到了我们这些关系型数据库的DBA在云计算公司里快要失业了；

但后来仔细琢磨了王坚博士经常说的一个观点，“云计算要像水电煤一样被使用“。单凭NoSQL数据库在近10年不太可能实现这种美好的境界。NoSQL并非万能，具体而言，数据模型的选择、接口规范以及当前面临的新业务比如移动业务数据的处理问题，都是NoSQL无法回避的。NoSQL数据库也不是唯一的适合存储大量数据或大型数据，显然，通过良好的分区设计，SQL数据库也可以获得极好的扩展性。

所以，在云计算的大环境里，我不认为NoSQL能够取代关系型数据库。关系型数据库提供了这么多的功能，有这么多知道如何使用的专业人士，它还是如此的可靠和安全，因此不是说没就能没的。而且云发展的越快就越需要，因为不是客户来适应云，而是云去解决客户的问题。于是在2010年年底我们开始着手启动项目并完成架构设计，于2011年春节回来写下第一行代码。

皮皮（Q3）：从架构的角度，RDS经历了哪些演进？它有哪些亮点？

何云飞（A3）：好的架构不是设计出来的，而是演化出来的，RDS也同样经历了这样的演进。运维是云计算需要解决的最基础的问题之一，比如机器硬件坏了，资源升级等这样的事情应该尽可能地减少对用户应用的影响。同时还考虑到安全因素，所以我们在链路的架构上采用了三层设计：

客户端 -> 数据网关 -> 数据引擎节点

你可以想像得到，数据网关就好比是RDS的大动脉，所有请求流量将会经过这里并返回给应用程序。

在不同的时期数据网关面临不同的挑战，经历了三次优化演进。

第一代数据网关我们采用的是F5网络设备，能够满足我们当时的需求；但随着业务的发展，相应的问题也出现了；

1）进出流量都需要经过它，吞吐量成为了瓶颈；

2）IP数量有限制；

3）价格贵；

所以我们快速演进到第二代数据网关：LVS 负载均衡1.0。

这是章文嵩博士于1998年5月研发的开源项目，完全可以通过PCSERVER来替换昂贵的网络硬件设备，我们仅仅使用其1：1转发功能，并且使用DR三角转发模式，可以让LVS只接受“入流量”，而“出流量”直接通过数据节点返回给客户端。这种模式下LVS的吞吐量一般情况下不是瓶颈，但当时的版本有几个问题：

1）LVS的高可用设计采用主备模式，这意味着，主备DOWN机后，  所有VIP需要在备机重新生效，并且用户原有的所有连接全部断开；

2）VIP MAC地址是通过ARP方式广播出去，当VIP数量超过一定数量以后，由于交换机的处理能力有限会导致：

VIP MAC地址不被上层交换机学习到，这样这个VIP的失效时间会大大增加，从而导致用户连不上数据库，有时候这个时间长达30分钟，这是不可以接受的！

3）DR模式只支持组内机器在同一个VLAN里，不能跨机房转发；

经过了故障以后，我们下定决心改进核心问题：

1）硬件永远是会坏的， 硬件坏掉如何让访问流量不受影响？

2）VIP MAC地址如何快速传播到整个网络；比如怎样控制在5秒内；

3）LVS的高可用是否可以做到无状态？

只要集群（共3台）有一台活着，流量都不会受影响，于是第三代数据网关出现：内部代码RGW - 由ALIBABA 核心技术保障-网络-王昕溥团队一起打造；它很好的解决了这几个问题；

1）它通过OSPFD协议直接与核心路由通信；可以配置IP公告策略（16位、24位等），所以不会随着VIP数量线性增长；

2）它利用了等价路由协议自动实现负载均衡，RGW节点本身没有状态，所以维护时给用户的影响几乎没有；

3）DNAT 转发模式可以让组内节点分布在不同的机房；这样RDS天然可以做到同城容灾；

4）多个节点的吞吐量可以累加，这表示单个VIP的吞吐量是所有RGW吞吐量的和；

解决了链路层的问题，应用层的问题悄悄浮现出来了：部分游戏客户使用连接池连接数据库，但没有配置重连，这会导致在RDS的数据节点发生故障切换时，应用程序由于没有重连机制而无法继续工作。随着客户越来越多，这个问题变成了共性问题。于是，我们给用户一种选择： 客户端 -> 4层数据网关-> 7层数据网关 -> 数据引擎节点。在这里，7层数据网关将与用户打交道并建立连接， 同时用户的请求将由它来转发到数据节点并返回结果。这样一来，客户端的会话不直接与数据节点保持，最重要的是7层数据网关有自动重连机制能够帮助用户解决问题。

现在RDS可以做到硬件损坏切换，跨机迁移基本对应用透明；但还是要提醒用户，如果使用数据库连接池（长连接），尽量要配置“重连”机制，因为我们不能忽略，从客户端到RDS我们需要经过多层网络设备。

皮皮（Q4）：阿里云RDS为社交网站、电子商务网站、手机App提供可靠的数据存储服务，在云端集群上，RDS是如何确保数据不丢失？相应的备份策略是怎样的？

何云飞（A4）： 不管是自建数据库还是云端，数据的备份永远是基础工作；就像一个人要生存下来，离不开基本的衣食住行，而阿里云的RDS拥有强大的数据备份机制。首先RDS所有的存储设备都采用RAID 阵列，这让你的数据除了有多余的冗余外,还保证了数据存取的高性能；其次，RDS可以让用户自己配置备份策略，包括备份周期和开始时间。

RDS的备份工作发生在“备库”上，所以备份过程不会影响“主库”的使用；RDS产生的备份集将统一存储到OSS分布式存储集群目前可免费存储7天。由于OSS本身就是多份存储设计，所以你的实例备份还享受着多份存储的保障；再有，不管你使用RDS哪个型号的读写实例，RDS都在后端有“备库”实时同步数据，当“主库”发生故障时，我们将自动快速地（30秒内）进行切换；最近我们也接到一些用户的需求，想要让备份存储更久，1年，2年，甚至10年；这些都是冷数据，RDS打算与阿里云最近公测的OAS对接，这样可以让用户享受RDS更廉价的备份服务。

皮皮（Q5）：很多用户都还是在自建数据库，自建数据库虽然解决了数据存放的问题，但是一旦被黑，所有数据就没有了。阿里云的RDS对于这方面的安全保障有哪些优势？

何云飞（A5）：这个问题非常关键，也是RDS产品努力的方向。最近我们从安全部门了解到，在浩大的网络世界里，每天被入侵的数据库数以千计。当然，如果黑客对你没有深仇大恨，是不会破坏你的数据，一般只是拉走你的数据，但这已经让你或者公司产生了足够大的损失。

RDS会尽量让您避免这方面的损失，有如下安全功能：

1）每个实例可以配置：信任来源IP白名单（100个），你可以决定哪些主机来访问你的数据库；

2）在上个问题中提到的7层网关，可以实时检测并拦截SQL注入行为，这些注入规则是阿里巴巴安全团队多年积累下来的宝贝；

3）RDS提供SQL审计功能，用户可以查看某时间点，哪个来源IP，哪个用户调用什么SQL语句查看了多少行数据；

4）最坏的情况，当你的数据被破坏，RDS还免费提供“数据恢复到指定时间点”的功能；该功能将开辟新的空间来恢复数据，你要做的只是确认数据是你想要的；

其中，1和2属于事前防护，

3和4属于事后审计和补偿。此些功能可以配合使用。

皮皮（Q6）：哪些数据库可以存放到阿里云关系型数据库里，RDS支持哪些SQL查询语言？阿里云关系型数据库RDS怎么扩容？

何云飞（A6）：RDS当前兼容MySQL和SQLServer，其中MySQL支持5.1，5.5，5.6版本。SQLServer支持2008R2版本。

 弹性是云计算最大的特色之一，用户可根据业务压力购买需要的资源，当资源不够时可随时在线升级。RDS在业务扩容有如下功能：

1）单实例，内存从240M - 48000M等7个规格支持在线扩容，磁盘空间最大支持1T；

2）只读实例，当我们的应用场景需要满足大量读请求时，最近发布的只读实例是很好的选择；他可以支持主实例最大5倍的读请求，并且支持自由升降配置；

3）分布式实例（DRDS），当我们的整体业务（读写）压力都很大时，我们要考虑用分布式方案来解决。DRDS可以让用户自由的将多个RDS组装成一个大的虚拟库，并且支持数据自动拆分和合并；当前DRDS最大规模可以支持128个节点；

   相信RDS应该可以支撑99%的业务场景。

皮皮（Q7）：在阿里巴巴看来，信息时代的企业IT消费已走过两个阶段：第一个阶段是IT时代，企业IT消费的模式是“计算机+软件”。第二个阶段是DT时代，企业IT消费的模式则是“云服务+数据”。云计算和大数据到底是怎样的关系？阿里在DT时代会有哪些创新之举？

何云飞（A7）： IT时代，数据是应用的结果；在DT时代，应用是数据的展现形式。云计算和大数据是一个硬币的正反面，云计算使大数据变得可行。如果说淘宝革了零售的命，那么可以说DT革了企业IT消费的命，企业可以通过数据为大家创造更加智慧的生活。“数据、平台和金融”是阿里的三大核心战略，阿里在DT时代走的依然是大平台和开放的策略，发挥阿里在数据积累、数据平台和数据应用三方面的优势，来推动整个社会的产业革新。

微博互动地址：http://weibo.com/1644971875/BmXiaE4zY?mod=weibotime 

原文地址：http://www.itpub.net/thread-1887486-1-1.html

【IT名人堂】何云飞：阿里云数据库的架构演进之路