首页 > 代码库 > 【IT名人堂】何云飞:阿里云数据库的架构演进之路

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

【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名人堂】何云飞:阿里云数据库的架构演进之路