没有合适的资源?快使用搜索试试~ 我知道了~
阿里电商架构演变之路
3 下载量 174 浏览量
2021-02-23
23:40:33
上传
评论
收藏 1.61MB PDF 举报
温馨提示
试读
11页
阿里已经不单单有电商业务,今天我们涉猎的非常广泛,布局也非常多。阿里从一家电商公司开始,如果业务已经覆盖到了各个行业,图为2015年的布局。按照这样的业务发展速度,如果没有一套完整的技术体系支撑,势必会影响整个业务的发展。可以看到我们的技术是分层的,在最上的是业务,中间部分是中间件、搜索和大数据等中台系统。整个的大中台体系就是中中间这层通用的技术能够快速支持上层业务的快速发展。只要是用发中台的技术体系,都能够在上面快速的搭建自己的业务。整个中台包括部分如图,除了中间件、搜索,还有一些数据分析。中间件在业务研发的过程中起到非常重要的作用。这是在我们整个技术架构演变过程中,逐渐形成的一套体系。淘宝
资源详情
资源评论
资源推荐
阿里电商架构演变之路阿里电商架构演变之路
阿里已经不单单有电商业务,今天我们涉猎的非常广泛,布局也非常多。阿里从一家电商公司开始,如果业务已经覆盖到了各
个行业,图为2015年的布局。按照这样的业务发展速度,如果没有一套完整的技术体系支撑,势必会影响整个业务的发展。
可以看到我们的技术是分层的,在最上的是业务,中间部分是中间件、搜索和大数据等中台系统。整个的大中台体系就是中中
间这层通用的技术能够快速支持上层业务的快速发展。只要是用发中台的技术体系,都能够在上面快速的搭建自己的业务。
整个中台包括部分如图,除了中间件、搜索,还有一些数据分析。中间件在业务研发的过程中起到非常重要的作用。这是在我
们整个技术架构演变过程中,逐渐形成的一套体系。
淘宝从初创开始到今天,我们的技术架构总体上经历了四代:
第一代是基于LAMP的一套结构。
第二代是基于Java的应用架构。
第三代是基于分布式体系,构建出一整套的分布式架构。
第四代是基于IDC,不但应用能够分布,整数数据中心也能够分布。
那么接下来,我就从0开始,跟大家分享这一段历程。
LAMP结构
整个淘宝网从开始想去创建,到真正上线,总共经历了一个多月的时间。那这一个多月的时间都做了些什么呢?
第一件事情,我们开始做技术选型,决定我们后续怎么发展;第二件事情,如何在一个多月的时间,让我们的网站上线。
我们购买了一套基于LAMP架构的电商网站,并且拿到源代码,我们对其进行二次开发,比如界面的UI改动,上下title的改
动,其中最大的改动就是我们对它的数据库做了读写分离。
Java架构
随着业务量的增长,就会发现一些瓶颈,主要来自于数据库。当时的数据库是MySQL4,还不够稳定,数据库经常会出现死
机。因此,我们直接把数据库换成oracle,通过PHP和oracle直接去连接进行操作,但PHP不支持连接池,即使使用一些开源
的PHP中间件,让PHP去连接oracle,还是非常不稳定,连接池的中间件经常卡死。
然后我们开始考虑将技术体系转成Java,因为Java在企业级的应用中,有着比较成熟的生态。转化的过程中也还是很坎坷
的:第一,我们是一个线上正在运行的系统;第二,系统当时正在大规模的增长。所以说把系统替换成Java,最好的方法就
是分块替换。同时发现,oracle的写入量还是比较大的,当时还做了一个search,把产品搜索和店铺搜索放到search里面,这
样每一次的请求都打到数据库里面了,这样我们就完成了1.0架构到2.0架构的演进。
分布式架构
随着整个业务的发展,我们又迎来了新问题,洪峰流量给我们带来了巨大的挑战,电商行业在国内已经逐步开始盛行,我们的
流量直线上涨,电商的人口红利也开始上涨。随着流量的上涨,我们面临着服务器和数据库的压力。
从技术角度来看,我们面临着两个问题:
首先是淘宝上描述商品的图片特别多,图片问题非常严重,主要取决于我们采用的是商用存储,成本非常高,最高级别版本也
很难存储下我们所有的图片;
其次在淘宝上浏览的所有交易都有交易快照,这也是非常耗费存储成本的;
第三,虽然数据库替换成了oracle,随着数据量的增大,我们所有的请求都打到数据库上面,这时数据库的存储也快达到了极
限,压力也非常大。
所以我们开始对架构升级。第一,我们增加了内存cache,cache主要是解决数据库压力过大的问题,我们自己研制了一套
Key/Value 分布式缓存(TAIR),就是在数据库前端加了一个内存cache,缓解了我们数据库的压力。第二,我们增加了分布
式文件系统(TFS),之前的文件系统在商用的时候,成本太高,服务器的量非常大,所以我们研发了自己的一套文件系统。
随着我们的业务量逐渐增大,人也越来越多,这就导致开发维护成本特别高,当时我们是all-in-one系统,所有人改所有的代
码都是在这一个系统里面,就会出现以下问题:
技术团队规模500人左右,维护变得越来越复杂
单一War应用,应用包一直增长,更新业务特性越来越慢;数据逐步形成多个孤岛,无法拉通
基于传统应用开发架构,业务爆发,弹性不足,单点故障影响巨大
还有性能问题。随着前端业务量的增大,服务器逐渐增多的时候,oracle也出现了连接数的瓶颈。所以我们必须开始做新的架
构,让整个架构往前走一步。
剩余10页未读,继续阅读
weixin_38670420
- 粉丝: 6
- 资源: 949
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0