首页 > 数据库技术 > 详细

在阿里云上遇见更好的Oracle(二)

时间:2018-10-10 11:45:30      阅读:69      评论:0      收藏:0      [点我收藏+]

标签:云计算   分享图片   等等   重写   及其   基本   现在   话题   大量   

从上一篇文章的反馈来看,大家还是喜欢八卦多过技术细节,那这一篇继续一些题外话,说说我对“去IOE”的看法。

 

对同一件事情,参与的没参与的人,讨论起来,都会有各自的立场。所以这里先申明一下,以下内容只是我个人的观点,与任何公司及组织及其他个人皆无关;限于个人记忆力,部分细节可能有出入,如有差错,纯属年老失忆。

 

淘宝当年从单个Java应用到服务化后的垂直分库,再到水平分库,一步一步走过来,每一步皆有其必然性。但从传播性和话题性上来讲,“淘宝技术架构升级”,显然不如“去IOE”这种标签化的短语有力量,短短几个字,既有动词“去”,又牵扯到当世三大企业服务厂商,想不吸引眼球当“网红”都难。

 

说起淘宝技术架构升级,2007年是一个绕不过去的时间点,呃,这么说的原因,当然很大一部分也因为我是这一年加入淘宝的。那一年的淘宝,意气风发,空降了几位很有影响力的高管,包括阿里巴巴集团现任CEO逍遥子、菜鸟现任CTO菲青、现任VP优昙(记不太清楚是07年底还是08年初了),还有已经离职的前技术VP空闻、前HR VP赵敏等。

 

2007年的淘宝技术架构,在Java层有一个大名鼎鼎的应用denali。真的是一个应用哦,淘宝前台业务大部分代码都堆砌在这一个应用中,牵一发而动全身。所以空闻和菲青来了以后,招了几个技术好手开始做服务化改造。于是有几个基础性的东西产生了: 毕玄主导HSF(High Speed Framwork)做为服务化的基础RPC框架,解决了服务化后各个应用之间的高性能通信需求;华黎主导的消息中间件Notify(后来Kafka出来后,又用Java重写了个MetaQ),解决了服务化后各应用之间异步依赖的消息通信需求。从产品命名上就可以看出来,包括后面的数据库中间件TDDL,当年淘宝的技术人员是有多土鳖了。有了这两大法宝,服务化和垂直拆分就水到渠成。

 

从2007年到2009年,马不停蹄的从denali中拆分出了用户中心UIC、商品中心IC、交易中心TC、店铺中心SC、评价中心、收藏夹等等垂直的服务中心,以及每个服务中心对应的上层应用,那些暂时拆不出来的一大坨,就都塞在一个叫Misc的数据库里面。数据库也从原来集中的商品和交易库垂直拆分成了十几套数据库,压力大的用IBM p950和EMC DMX高端存储,压力小一点的用IBM p550和EMC CX中端存储,2007年到2009年在每年业务至少翻番,系统压力翻几番的情况下,土鳖的淘宝技术人员,用土办法见招拆招,算是顺利度过了这段艰难时期,也奠定了后续的技术方向。这段时期当然也有很多插曲,包括各种宕机,甚至是机房两次断电等,那又是另外一个故事了。

 

技术分享图片

 

时间到了2009年,数据库这么垂直的拆下去,到最后单个数据库只放一张用户表或者一张交易表,用最高端的小型机和最高端的存储,也快顶不住压力了,尤其是连接数。前端无状态的Java应用服务器现在已经能够随着业务压力加机器扩容了,但应用加机器都得要加连接数啊。Oracle是进程模式的,基本上一个连接数需要消耗8~10MB的内存,这样5000个连接数就需要50GB左右的内存,加上SGA,连接数的天花板近在眼前。

 

数据库当时采用的高端小型机+高端存储+Oracle,价格确实是不便宜。垂直拆分已经搞出了十几套这样的硬件,再来个水平拆分,DBA团队做预算的压力真是山大。所以开始把目光投向了MySQL。当时比较成熟的版本应该还是5.0,2008年底刚刚GA没多长时间的5.1算是新锐版本。我们开始在一些边缘系统尝试,也面向全国开始招MySQL DBA,但其实一个也没招到,只好从应届生开始培养。好在服务化垂直拆分做完以后,大量的关联查询都在应用服务层通过接口调用来解决,数据库基本上就只有基于主键的增删改查操作了,基本上也就相当于一个KeyValue存储在使用。所以说,服务化是数据库水平拆分很重要的一个前提。

 

但是,服务化只是一个前提。要做核心数据库如用户库和交易库的拆分,还必须要解决IOPS的问题。为什么要用高端存储?因为IOPS啊。传统机械硬盘在可接受的10ms响应时间内的IOPS峰值大约只有80~100。当时我们一个交易库使用的高端存储配置了480块硬盘,可以支撑大约4万~5万的IOPS,按照一台PC Server可以插16块硬盘来计算,需要30台机器。看起来也不多是吧?但这么大的动作做完,肯定需要至少能支撑2~3倍的余量才行啊,所以需要一下子拆分到至少64个节点128台机器,而且很可能两三年后就要朝着上千台的规模去了,而这个规模纯粹是因为IOPS,CPU却是大大浪费的。对于当时还只有十几套Oracle数据库的DBA团队来说,维护成本也犹如达摩克利斯之剑啊。

 

正所谓车到山前必有路。我们在Percona的mysqlperformanceblog.com上了解到了一款名叫FusionIO的PCI-E Flash闪存卡,小小一片印刷电路,竟然拥有超过十万甚至百万IOPS的能力,响应时间还能到1ms级别,这种法宝正好也开始进入中国了。于是我们相当激进的开始引入测试,并且一举上线,反正压力在身不得不前行,加上有主备复制,还有Notify做Oracle/MySQL异步复制新旧两套数据库系统并行的双保险,就这么搞成了。

 

所以说,所谓的“去IOE”,在当时其实有两个重要的前提条件:

1. 服务化的完成,数据库变成了简单的KeyValue存储模式;

2. PCI-E Flash卡的成熟,解决了IOPS的问题

 

PCI-E卡是好东西,可是也很贵,当时一片的价格要10万左右。Flash存储成熟后,英特尔也跑出来要分一杯羹,推出了传统IDE接口的SSD硬盘,虽然单个盘的IOPS比PCI-E卡下降了至少一个数量级,但价格也便宜了很多,而且一台机器上可以插多个盘。所以除了压力非常大的核心数据库,其他的数据库也就可以一股脑儿的从Oracle迁移到了基于SSD的MySQL上。反正迁移和拆分这事儿,一回生二回熟了。

 

水平拆分的架构升级帮助淘宝沉淀了另外一个神器:TDDL(Taobao Distributed Data Layer)。TDDL除了水平分库的路由功能,还有一个非常核心的模块叫动态数据源。因为原来需要在Java应用中显式的配置每个数据库的连接参数,每次修改都需要重新打包发布应用。水平拆分以后,数据库节点变多了,应用的机器也越来越多,这个事情就越来越不好玩。我就和华黎/沈询商量,能不能把数据库连接参数搞成动态可配置,这样DBA干拆库/主备切换这样的小动作时,应用的同学就不用陪着熬夜了。就这样,这帮靠谱的家伙就搞定了三层的动态数据源。

 

淘宝这一路的技术架构升级,沉淀出来,其实就三个东西,今天已经在阿里云上做为互联网中间件对外提供服务,这是一个好事情:

  1. 企业级分布式应用服务EDAS,就是HSF和阿里巴巴B2B团队搞的Dubbo(已经开源)的内部合体版本

  2. 消息队列MQ,就是Kafka的Java版本MetaQ

  3. 分布式关系型数据库服务DRDS,就是内部的TDDL

 

所以我一直认为,“去IOE”更准确的说法应该是淘宝技术架构的大升级;而云计算,则是传统IT架构的一次大升级。这两者相互之间也可以说是有传承的,都是在向着拥抱X86开放式体系,向着弹性升缩的方向升级。但“去IOE”这种简单粗暴的标签化提法,虽然在宣传上比较有效,但其实掩盖了很多的来龙去脉。

在阿里云上遇见更好的Oracle(二)

标签:云计算   分享图片   等等   重写   及其   基本   现在   话题   大量   

原文:https://www.cnblogs.com/dtstack/p/9765278.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号