写点什么

淘宝网前期技术架构演进分析

用户头像
andy
关注
发布于: 2021 年 01 月 28 日
淘宝网前期技术架构演进分析

了解和探索中国互联网技术架构演进,就不得不说到淘宝,它是一个不可回避的话题。中国电商领域的佼佼者,今天的互联网巨头,它是怎么一步一步发展到今天的样子,又对于我们在进行架构设计与技术选型中有什么启示。确实是一个非常值得深入研究和探讨的案例。


我希望通过个人的方式,去解读和理解淘宝技术演进的历史,对于自己进行系统架构设计有所帮助。淘宝网十七年的架构变化分为许多重要的阶段,包含的内容很多。本篇文章主要阐述淘宝网还未进行业务拆分之前的架构迭代过程,试图以管中窥豹的方式,去了解淘宝如何进行技术选型,如何进行技术决策,技术如何更好服务于业务,帮助业务快速发展。


互联网系统架构设计,无论如何变化,始终都是围绕两个方面展开,即“业务复杂度”和“用户规模”。业务与用户相辅相成,互相成就。当然,并不是说业务复杂度越高,用户规模就越大,两者没有线性关系。只是两者在某种程度上,具有一定的关联性。当用户规模达到一定数量级时,比如千万以上,系统的业务复杂程度肯定也不会很低。比如淘宝,数以亿计的用户量,业务之间的复杂程度就非常高。


下面就以时间为量度,展开进行解读。


一、2003 年创立初期


马云于 1999 年创立阿里巴巴,旨在解决商人之间做生意困难的问题,于是构建了 B2B 商业模式的阿里巴巴。经过几年的发展,马云意识到 To C 的发展潜力将会更大,于是调集人手,于 2003 年在家中开始了淘宝的项目设计、规划、实施。我们也不能忘了当时中国所处的社会环境,就是正值非典肺炎横行的时期,人们的出行购物受到了极大限制。这就像今天的新冠肺炎一样。


淘宝创立之时,通过购买国外系统,快速进行系统上线运行,试探商业模式的市场可行性。当时的环境,世界最著名的网上交易平台就是 eBay,就是那个把硅谷钢铁侠埃隆马斯克的 PayPal 收购的公司。国外 eBay 成功模式是 C2C,也就是网上拍卖平台。


基于当时中国所处的环境,还没有像今天这样发达的互联网平台。同时,中国文化也没有那种二手交易的习惯,尤其是这种小件商品。不可能购买一把剪刀,还要到网上购买别人使用过的。于是,淘宝试点了两种方式,一种就是 C2C 拍卖模式,一种是 B2C 一口价模式。


以下是 2003 年淘宝上线运行的页面,上面能够清晰看到一口价和开价,背后就是 B2C 和 C2C 模式。



中国用户更加倾向于 B2C 一口价模式,淘宝吸引了大量的用户,用户规模不断提升。创立初期的业务相对今天而言,已经是非常简单了。也就是商品上线出售,用户下单购买,卖家发货等环节。淘宝也是基于此,探索出了更加适合中国的 B2C 模式,果断丢掉 C2C 拍卖交易。


这里需要补充一点,阿里巴巴做大做强之后,不断优化电商领域各个环节,闲鱼 APP 又是其 C2C 业务模式的应用布局,可以说是无孔不入。


淘宝初期系统,是付费购买的系统,使用 LAPM 结构,所有业务处理都是在一个应用系统之上,然后据此进行应用服务器集群部署水平扩展即可。MySql 就是采用一主多从和读写分离,保证数据同步复制。系统的架构非常简单,部署图如下。



二、2004 年快速发展时期


随着淘宝不断发展,用户规模逐渐增大。此时,淘宝进行了业务创新,将原有杂乱无章的商品,进行归类,构建了商品类目体系,为用户提供更加高效快捷的服务。商品类目的建立,极大提高了用户购买效率。对于用户而言,有时候有购物需求,但不知道从何查找。而提供了商品类目功能,用户便可以进行一层一层地去筛选查找,更加精准地进行网上交易。


商品搜索也是淘宝必须解决的问题。从用户角度出发,如何帮助用户更加快捷地根据提供的词条,搜索出相似的商品,进而能够选中商品进行购买服务。从商家角度出发,希望系统能够优先选出自己的商品提供给用户。而对于平台而言,则可以通过排序算法,为需要服务的商家提供帮助,并且从中获利。


以上便是这个时期,淘宝业务上变化重点。下图展示 2004 年淘宝页面。



对于这个阶段,淘宝技术架构进行重大变革。首先是数据库的替换。由于用户规模和业务需求快速增长,原有的 MySql 出现了容量瓶颈,整个系统的性能受到了 MySql 的极大影响。此时,便需要进行升级优化。这就是技术选型的问题。


通常而言,对于系统架构的性能问题,解决问题的方向主要分为垂直伸缩和水平伸缩。当时,淘宝面临巨大的增量压力,为了能够快速解决问题,淘宝决定放弃优化 MySql,放弃构建分布式 MySql 数据库,转而购买 Oracle 数据库服务。


这里需要提一点,Oracle 要发挥真正的作用,需要依托强大的服务器,高质量的存储,因此,就需要使用 IOE 架构,即使用 IBM 小型机、Oracle 数据库、EMC 专用存储。这样下来,费用也非常高,大约百万左右。


为什么选择 Oracle,花费如此高的费用。实际上还是需要回到技术和业务之间的关系问题。业务驱动技术发展,技术服务于业务。当淘宝业务快速发展,无法容忍技术容错时间,并且能够拥有一定成本购买高级服务。那么,垂直伸缩便是一个极好选择,也就是升级软件和硬件条件。因为,它不需要更改应用系统,只需要将 MySql 数据迁移至 Oracle 即可,其他的部分几乎不变。


架构变化部署图如下:



同时,淘宝也做了另一件技术改革,将 PHP 替换成了 Java,以及引入雅虎的搜索引擎 ISearch。我们知道,淘宝最开始购买的是 PHP 系统,由于业务快速发展,原有的系统架构已经无法满足需要。同时,受限于 PHP 的技术局限。个人以为,应该是 PHP 没有 Java 那样成熟的生态,提供的企业级应用解决方案不如 Java 多。综合多种原因,淘宝重新构建了系统,将 PHP 迁移至 Java。这一期间,淘宝使用了自研的 MVC 框架 WebX。Apache 容器替换为 Weblogic。


架构如下:



三、2005 年持续发展时期


随着业务与用户的持续增长,淘宝继续进行了系统架构的优化。抛弃较重的 EJB,转而使用性能更加优良的 Spring。EJB 的优点在于分布式的服务和调用,缺点就是开发和维护过于复杂,于是 Spring 便成了更加合适的选择。


之前使用的 weblogic 更换为 jboss。为什么如此选择。weblogic 提供强大的运维和部署工具,非常适合服务器上运行使用,这对于传统的系统应用而言,非常适用。但是由于淘宝采用的分布式服务器,基于分布式的脚本语言进行系统运维和部署,而不是去到每一台服务器使用工具进行项目部署。开源免费的 jboss 便是极好的选择。


同时,由于 Oracle 达到了瓶颈,便构建分布式数据库,支持分库的数据库访问框架。淘宝为了加速数据的读操作,增加了基于 BDB 的 ESI 缓存。同时,构建 CDN 服务器,在运营商处解决用户访问静态数据的问题。


系统架构部署图如下:



四、2007 年架构定型


基于前期的技术积累,此时的淘宝技术已经开始非常完善,整体的架构也固定下来,剩下的工作就是针对系统,不断进行各个细节的优化和提升,这个时期最大的特征就是分布式技术层出不穷。各种缓存、各种 NoSql 组件等。


淘宝技术架构部署图如下:



这里有个小思考,我们技术人确实需要跟进时代潮流,当年各种分布式技术诞生,从事分布式技术的工程师是能够获得极高的收入回报的。这就告诉我们,要符合时代要求。但是,也需要清醒认识,对于一项技能,我们应该放长远去看,看看自己是不是在未来十年二十年从事这项技术的工作,同时,也需要看看未来这项技术的发展趋势。如果,过了那个时代,再回头去研究,实际上,就是吃力不讨好的事情。也就是,技术之路的选择,既要符合自己的兴趣爱好,也好符合时代发展的要求。


对于技术选型的决策,可以分为两个方面去思考。


第一,分析技术方案的优点、缺点、核心点有哪些;

第二,认清自己的需求,判断技术方案的优点是否满足需求,自己是否容忍技术方案的缺点。


以之前的 weblogic 为例。weblogic 提供了强大的运维和部署工具,但是,并不符合分布式脚本语言部署方式,同时,还是一款收费软件。而 jboss 则是一款开源免费适合分布式部署的容器。故淘宝之后技术选型,选择了 jboss。


淘宝架构图如下:



以上便是自己对于淘宝前期技术架构演进的分析,非常感觉你阅读完整篇文章。由于个人水平有限,文章中肯定有着许多的不足之处,希望你能够指出,帮助我进步。最后,再次深深感谢。


用户头像

andy

关注

还未添加个人签名 2019.11.21 加入

还未添加个人简介

评论

发布
暂无评论
淘宝网前期技术架构演进分析