揭秘：一位亲历者眼中的淘宝技术架构发展之路
“
前一篇“淘宝发展历程最具决定性的一次技术架构演变”，详细描述了淘宝技术架构最重要的第三、四阶段演变。
由于大家的热情相当高涨，所以特意补充了本篇文章（淘宝技术架构早期第一、二阶段），从而可以完整的查看到整个淘宝技术架构演变过程。
淘宝技术发展历程
前一篇“淘宝发展历程最具决定性的一次技术架构演变”，详细描述了淘宝技术架构最重要的第三、四阶段演变。
补充本篇重点谈第一、二阶段，从而可以完整的查看整个淘宝的技术架构演变历程。
淘宝架构演变第一步
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之路？
带着这些问题，可以查看前一篇“淘宝发展历程最具决定性的一次技术架构演变”，详细描述了淘宝怎么来解决以上问题。
关注优知学院后，可以完整查看到淘宝架构的第三、四阶段：“淘宝发展历程最具决定性的一次技术架构演变”。
