到2008年初，整个主站系统(有了机票、彩票系统之后，把原来的系统叫做主站)的容量已经到了瓶颈，商品数在一亿以上，PV在2.5亿以上，会员数超过了五千万。这个时候Oracle的连接池数量都不够用了，数据库的容量到了极限，上层系统再增加机器也无法继续扩容了，我们只有把底层的基础服务继续拆分，从底层开始扩容，上层才能扩展，这才能容纳以后三五年的增长。

　　于是那一年我们专门启动了一个更大的项目，把交易这个核心业务模块也拆分出来了。原来的淘宝交易除了跟商品管理耦合在一起，也在支付宝和淘宝之间跳来跳去，跟支付宝耦合在一起，系统复杂，用户体验也很不好。我们把交易的底层业务拆出来叫交易中心TC(trade center)，所谓底层业务是例如创建订单、减库存、修改订单状态等原子型的操作;交易的上层业务叫交易管理TM(trade manager)，例如拍下一件普通商品要对订单、库存、物流进行操作，拍下虚拟商品不需要对物流进行操作，这些在TM里面完成。这个项目取了一个很没有创意的名字——“千岛湖”，这帮开发人员取这个名字的目的是想在开发完毕之后，去千岛湖玩一圈，后来他们如愿以偿了。这个时候还有一个项目也在搞，就是淘宝商城，之前拆分出来的那些基础服务，给商城的快速构建，提供了良好的基础。

　　类目属性、用户中心、交易中心，随着这些模块逐步的拆分和服务化改造，我们在系统架构方面也积累了不少的经验。到2008年底干脆做了一个更大的项目，把淘宝所有的业务都模块化，这是继2004年从LAMP架构到Java架构之后的第二次脱胎换骨。这个项目取了一个很霸气的名字，叫“五彩石”(女娲炼石补天，用的石头)。这个系统重构的工作非常惊险，有人称之为“给一架高速飞行的飞机换发动机”。

　　五彩石项目发布之后，这帮工程师去三亚玩了几天。他们把淘宝的系统拆分成了如下架构：

　　其中UIC和Forest上文说过，TC、IC、SC分别是交易中心(Trade Center)、商品中心(Item Center)、店铺中心(Shop Center)，这些中心级别的服务只提供原子级的业务逻辑，如根据ID查找商品、创建交易、减少库存等操作。再往上一层是业务系统TM(Trade Manager交易业务)、IM(Item Manager商品业务)、SM(Shop Manager，因为不好听，所以后来改名叫SS：Shop System，店铺业务)、Detail(商品详情)。

　　拆分之后，系统之间的交互关系变得非常复杂，示意图如下：

　　系统这么拆分的话，好处显而易见，拆分之后每个系统可以单独部署，业务简单，方便扩容;有大量可重用的模块以便于开发新的业务;能够做到专人专事，让技术人员更加专注于某一个领域。这样要解决的问题也很明显，分拆之后，系统之间还是必须要打交道的，越往底层的系统，调用它的客户方越多，这就要求底层的系统必须具有超大规模的容量和非常高的可用性。另外，拆分之后的系统如何通讯?这里需要两种中间件系统，一种是实时调用的中间件(淘宝的HSF，高性能服务框架)、一种是异步消息通知的中间件(淘宝的Notify)。另外还有一个需要解决的问题是用户在A系统登录了，到B系统的时候，用户的登录信息怎么保存?这又涉及到一个Session框架。再者，还有一个软件工程方面的问题，这么多层的一套系统，怎么去测试它?