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

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

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

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

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

一、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。

淘宝架构图如下：

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