早在2007年的时候，整个淘宝网站是一个几百兆字节的WAR包，大小功能模块超过200个，当时的淘宝业务处于每几个月就翻倍高速发展，这样的应用架构给淘宝技术团队带来了
非常大的压力 ,虽然技术团队规模已超过500人。几百人维护一个War包的模式，带了几个大问题：
1、项目团队间协同成本高，业务响应越来越慢。比方说各团队开发各自模块的分支，一旦理临*新版本上线，各分支合并会出现大量的jar包冲突、代码不一致的情况。如果再遇到有些功能
开发的进度滞后，情况就变得更加复杂。
2、应用复杂度已超出人的认知。淘宝早期还有同事能对*台各个功能和实现了如指掌，但面对越来越复杂的淘宝*台，各种业务错综复杂地揉在了一起，已经没有一个人能完全清楚每一个功能
和业务流程的细节。一个小小的改动可能会给其他功能带来未知的风险，会有种“牵一发而动全身”的感觉。
3、错误难隔离。淘宝台中有用户、商品、交易、店铺等核心功能模块（相对稳定），也有基于运营需求的非核心模块，如广告展示，每天都会有新版本发布。核心功能和这些非核心功能在同一个
环境（同一JVM）中，任何一个小的问题都有可能造成应用实例崩溃。
4、数据库连接能力很难扩展。整个淘宝*台的所有业务功能均在一个War应用中，所有数据也均保存在同一数据库集群中，而数据库集群的数据库连接数量是有上限的，随着淘宝应用实例数量增加，2007年峰会数据库连接数量已经超过5000个，离数据库官方支持的连接数上限已经非常接*。*台也已经因为过高的数据库连接处于一个非常不稳定的状态。
5、应用扩展成本高。业务处理瓶颈的时候，只是由于某一个或几个功能模块（比如在大促时商品库存功能和订单创建功能的压力会非常大）负载较高造成的，但因为所有功能都打包在一起，所以在出现此类性能问题。
解决以上问题的根本就在于业务的拆分，淘宝在2007年10月开始了一系列的基于SOA理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用架构的改造工作。
首先淘宝从现有应用中选择了用户相关的功能作为试点，由于用户的业务逻辑相对独立和简单，而且服务功能的复用率最高，在逐渐完善新研发的服务框架的同时，可以积累大量服务化实施经验。2个月改造2008年年初成功上线。紧接着，又开始了两个在阿里巴巴内部非常著名的项目：“千岛湖”项目成功将“交易中心”和“类目中心”从现有*台中进行了剥离和改造，“五彩石”项目则将剩下的“商品中心”、“店铺中心”等核心业务功能模块进行了全部的改造。最终在保障淘宝业务不间断运行和不影响业务发展的同时，在14个月的时间内将原来单一应用的模式改造成为基于SOA理念的分布式服务架构。在应用部署形态上，由之前一个几百兆字节大小的WAR包部署模式改造成为上百个WAR包独立部署的服务化架构。这次改造被阿里巴巴同事称为“给飞行中的飞机换发动机”，也为后来的共享服务体系的建设打下了扎实的技术和理论基础。
*********************************************************************************************
【如果文字看累了，可b站搜索“沙皮狗2021”，用听的方式领略知识的魅力】
传送门 ：https://space.bilibili.com/407643589
【微信公众号】： 沙皮狗2021