揭秘:一位亲历者眼中的淘宝技术架构发展之路

前一篇淘宝发展历程最具决定性的一次技术架构演变”,详细描述了淘宝技术架构最重要的第三、四阶段演变。

由于大家的热情相当高涨,所以特意补充了本篇文章(淘宝技术架构早期第一、二阶段),从而可以完整的查看到整个淘宝技术架构演变过程。

淘宝技术发展历程

揭秘:一位亲历者眼中的淘宝技术架构发展之路

前一篇“淘宝发展历程最具决定性的一次技术架构演变”,详细描述了淘宝技术架构最重要的第三、四阶段演变。

补充本篇重点谈第一、二阶段,从而可以完整的查看整个淘宝的技术架构演变历程。

淘宝架构演变第一步

1.诞生场景

2003 年 4 月 7 日,马云,在杭州,成立了一个神秘的组织,叫来十位员工,要他们签了一份协议,并要求他们立刻离开阿里巴巴,去做一个神秘的项目。需求也很明确,上线一个可拍卖的电商网站。需求的时间也很明确,一个月。

满足需求的第一要素,那就是分析评估。评估完发现根本不可能1个月开发一个拍卖网站。于是另辟出路,是否可以买一个开源的系统,在上面修改。最后就买了个老美的PhpAuction,一个月后正常上线。

最早的淘宝效果图如下:

揭秘:一位亲历者眼中的淘宝技术架构发展之路

2.基本架构

最开始就是无比经典的LAMP经典架构(linux apache mysql php),再牛逼的网站不也是这样一步步起步的么。

揭秘:一位亲历者眼中的淘宝技术架构发展之路

3.从物理部署角度

也就是非常简单,web机器 数据库服务器搞定。

4.从软件架构的角度

小而快的简单架构,也就是无需编译,发布快速,PHP能完成从页面渲染到数据访问所有的事情,而且用到的技术都是开源的,并且免费。在那个年代类似的产物,还有大量asp网站。比如,同时期开发架构遗留下来的有京东、新蛋、携程、易迅等互联网企业,后面花了大量的时间重构,把asp网站改版为.net,最后还得花更大的经历和代价改版为java版本。

3.优点

最大的优点:快速满足业务需求。

这个时候没有过多考虑技术是否牛逼、没有过多考虑性能是否海量、没有考虑稳定性如何,主要的考虑就是:快!

当时淘宝的第一个版本的系统里面已经包含了商品发布、管理、搜索、商品详情、出价购买、评价投诉、我的淘宝这些功能。

4.瓶颈

在短时期在淘宝市场和运营部门的强大推动下,到了2003 年底就吸引了大量的注册用户,最高每日 31 万PV,到2003年年底成交额接近4000 万。

瓶颈来了,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题。

例如,第一个问题来了,出现在数据库上。当时采用的是MySQL第 4 版的,用的是默认的存储引擎 MyISAM,这种类型读数据的时候会把表锁住(我们知道 Oracle 在写数据的时候会有行锁,读数据的时候是没有的),尤其是主库往从库上面写数据的时候,会对主库产生大量的读操作,使得主库性能急剧下降。

当时最大的瓶颈还是来自于数据库,发现是访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢,但数据库连 接又不能开太多,否则数据库机器压力会很高。

备注:当时淘宝的情况, PHP 语言来说它是放在 Apache 上的,每一个请求都会对数据库产生一个连接。php的连接池只能从第三方扩展里实现连接池。

总之问题非常清楚了,数据库的访问压力过大,有什么对应的方法减少数据库端的开销变得及其重要。

于是开始了架构的第二步演变。

淘宝架构演变第二步

1.遗留问题

访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢,但数据库连接又不能开太多,否则数据库机器压力会很大。

采用mysql MyISAM,读数据的时候会发生锁表的情况。

php的代理连接池雷区太多,经常挂!

访问量越来越大,各种压力接踵而至,应用端、数据段等等。

2.架构方案

解决数据库端瓶颈

采用oracle替换mysql,解决高并发读数据等系列问题,也引入了数据库连接池,以及读写分离等。

采用了Oracle 的 RAC(Real Application Clusters),做了集群管理,以及读写分离Master/Slave等。

下图是oracle ace的结构:

揭秘:一位亲历者眼中的淘宝技术架构发展之路

最后,为了配合Oracle,php也彻底被替换为java。替换为java其实还有一个很重要的原因:配合数据库连接池的使用,毕竟php的代理连接池坑太多。当然,java的开源体系也是非常重要的考虑。

3.应用端解决方案

第一个,往集群方向发展,从硬件的角度可以横向扩展应用服务器。对应的就会涉及到应用端的负载均衡,类似的方案非常多LVS等。

为了减少对数据库端的访问压力,把访问转移到缓存上,也就涉及到了分布式缓存,eg:memcached等开源架构。最早淘宝采用的分布式缓存就是memcached,后来开始定制化,改进了部分内容,演变成了现在这个Tari版本。

也是为了减少数据库端的压力,把小文件存储转换到便宜的硬件上,也就有了分布式存储,后来的TFS。

最终你会发现,都是为了缓解数据库端的压力。

4.第二阶段架构大致如图:

揭秘:一位亲历者眼中的淘宝技术架构发展之路

应用服务器采用了jboss服务器,之前用的是weblogic。

框架采用了webx(自己研发的web框架),spring,ibatis,antx。

antx重点说下,webx和antx都是阿里最早的架构师(十八罗汉)宝宝设计的。你可以理解为现在的maven,当时这么早就可以设计出这么牛叉的东西。只不过没有开源出来,否则完全可以很早就替换现在的maven。

怎么扩展?基本就是硬件水平扩展,应用端和数据库端加机器扩展。

5.挑战来了

第一个:代码工程臃肿到了极致,严重影响了开发速度和发布。

上百人维护一个代码百万行的核心工程denali。多个业务系统中的超过1/3的核心代码重复编写。 你可想而知,这有多臃肿。一群人在上面拉分支,发布上线,然后在合并分支。线上出问题了,还得回滚,再合并,特别是开发、SCM等痛苦死了!

备注:我自己就亲身经历过两次,从denali里面拆了两个业务系统,从一个百万行代码抽取出一个打包后就十几M的文件。拆分一次,你绝对不想再去拆分第二次,我拆了两次:(

第二个:数据库端的压力又到瓶颈了。

原因很简单,访问比之前大了无数倍了,还是扛不住啊。 数据库端的压力一直是重中之重,小型机也扛不住了。

当时的淘宝的典型症状,就是数据库服务器的CPU占用超过90%,说明开的数据库连接也达到了极限,数据库机随时崩溃。

揭秘:一位亲历者眼中的淘宝技术架构发展之路

关于这一条,很多没有经历过雪崩的,也许你死都不知道怎么死的。雪崩效应,90%都是来源于数据库端的压力。数据库端的压力会转移到应用端,最后互相死循环。最重要的就是要管住数据库端的压力,并且把应用端的压力与数据库端做切割。切割有多种方法,最好的方法就是物理隔离

很显然,即将面临的挑战和瓶颈来了:

数据库的瓶颈快到极限了,数据库端需要做垂直拆分了,按照业务线。

应用端的代码结构也需要做垂直拆分了,按照业务垂直拆分代码。

接口需要清理依赖关系,是否需要单独部署?需要一个支撑高并发的通讯框架?

中间件需要形成自己的矩阵了,分布式缓存、分布式存储、SQL路由等等。

为此,想从根本上解决以上问题,是否需要探索出自己的一套SOA之路?

带着这些问题,可以查看前一篇“淘宝发展历程最具决定性的一次技术架构演变”,详细描述了淘宝怎么来解决以上问题。

作者简介

陈睿|mikechen,10年+大厂架构经验,大厂资深面试官,就职于阿里巴巴、淘宝、百度等一线互联网大厂。

以上!

关注作者「mikechen」公众号,获取更多架构面试干货!

后台回复架构,即可获取《阿里架构师进阶专题全部合集》,后台回复面试即可获取《史上最全阿里Java面试题总结

评论交流
    暂无讨论,说说你的看法吧