淘宝技术架构经历从最初的LAMP架构，到IOE架构，再到分布式架构，再到去IOE，最后到现在的云计算平台架构这一变化过程在不断解决上面的技术问题，可以说淘宝技术架构的演变就是活生生的一本架构教科书。这次为大家带来淘宝架构从1.0到3.0的整个演变过程，淘宝架构前世今生下部将为大家带来4.0-5.0架构的演变过程以及重点解读到淘宝架构走过哪些弯路，哪些是现在公司的技术架构可以避免和参考的。
淘宝1.0架构
第一个阶段：LAMP+数据库读写分离
技术架构比较简单，采用经典的LAMP结构，mySQL采用M-S模式，实现了读写分离。
这种架构的优点是：无需编译，发布快速，PHP功能强大，能做从页面渲染到数据访问所有的事情，而且用到的技术都是开源的，免费。
直到如今，大部分公司仍然沿用经典的LAMP，特别是适合早期创业公司在产品和商业模式的验证阶段，可以快速实现产品原型，快速部署，比较高效。
数据库端采用读写分离，缓解了数据库在大量读访问的压力。其实，在这个阶段，大部分创业公司还不用采用读写分离，大量的访问压力，应用端的压力比如：大量的图片、数据访问的可以先转移到多态服务器，或者转移到CDN以及缓存上面，这样来降低数据库端的压力，过了这个阶段，后面才来考虑读写分离会好很多。
最后部署也比较简单，这一步架构演变对技术上的知识体系基本没有要求。
这个阶段，基本都是硬件水平扩展阶段。
淘宝2.0架构
随着访问量和数据量的飞速上涨，问题很快就出来了，主要还是数据库阶段，当时对于PHP语言来说它是放在Apache上的，每一个请求都会对数据库产生一个连接，它没有连接池这种功能（Java语言有Servlet容器，可以存放连接池），造成的数据库端的瓶颈就特别明显。
Oracle容量大、稳定、安全、性能高，Oracle的性能和并发访问能力之所以如此强大，有一个关键性设计——连接池，连接池中放的是长连接，任何一个请求只需要从连接池中取得一个链接即可，用完后释放，不需要频繁的创建和断开连接。
于是年底，把MySQL换成Oracle的同时，语言还是php，但是数据库连接端使用一个开源的连接池代理服务SQLRelay。
调整后的2.0架构如下：
调整后的问题也比较多，特别是sqlreplay，这个个代理服务经常会死锁。
这个阶段比较明显的压力还是来自于数据库端，除了加入了代理连接池使用oracle的数据库连接池外，应用端的压力还是非常大，急需要缓存以及对大量商品库的搜索的压力解决方案。
淘宝3.0架构
年在淘宝业务发展的推动下，参考电信运营商、银行等的一些企业解决方案，将LAMP架构改造为Oracle+IBM小型机的数据库架构和EMC存储方式。虽然方案成本昂贵，但性能非常好。同时，随着网站流量的增加，系统显得有些不堪重负。当时最担心的问题是网站流量如果持续增加，交易量持续增加，网站的系统架构怎么设计？如何选择数据库？如何选择缓存？如何构建业务系统？……后来参考eBay的互联网设计架构，设计了一个Java的技术方案，并使用了非常多的Java开源产品。
为了解决上文提到的大量商品库的查询，采用自己开发的ISearch搜索引擎来取代在Oracle数据库中进行搜索，降低数据库服务器的压力。做法比较简单，每天晚上全量将Oracle小型机的数据dump出来，Build成ISearch的索引，当时商品量也不大，一台普通配置的服务器，基本上可以将所有的索引都放进去，没做切分，直接做了一个对等集群。
调整后的3.1最后调整架构如下为：
这个阶段语言完全换成了java时代，以及对应的多层架构体系。
-（大概是这个时间段），引入IBM小型机、使用EMC存储。
1、Oracle数据库分库，商品信息和用户信息分库存放，由数据库路由的框架DBRoute统一处理数据的合并、排序、分页等操作；
2、控制层用Spring框架替换EJB；
3、研发基于BerkeleyDB的缓存系统，把很多不太变动的只读信息放了进去；
4、加入CDN内容分发网络。
最后在3.1这个基础上在年左右改进为3.2这个版本：
年初，为了解决Oracle数据库集中式架构的瓶颈问题（连接数限制、I/O性能），将系统进行了拆分，按照用户域、商品域、交易域、店铺域等业务领域进行拆分，建立了20多个业务中心，如商品中心、用户中心、交易中心等。
所有有用户访问需求的系统，必须使用业务中心提供的远程接口来访问，不能够直接访问底层的MySQL数据库，通过HSF这种远程通信方式来调用业务中心的服务接口，业务系统之间则通过Notify消息中间件异步方式完成调用。
从年开始后的的服务化淘宝4.0技术架构以及后续的后续的智能化架构5.0的将是淘宝最重要的一次技术升级，4.0和5.0的演变将在淘宝技术架构的前世今生(下)详细讲解。
优知学院(youzhixueyuan.