阿里电商架构演变之路

第一部分 技术架构演进

前言阿里应该是Java大户，之前对于阿里的技术并不是很熟悉，后来接触的多了，才觉得阿里电商领域做得有多大，背后的技术支撑也是令人眼花缭乱，既然做互联网之路，那么阿里的电商技术模式就是绕不开的，面苏宁时，面试官也说，阿里现在走的路是我们以后的必经之路，不得不说，阿里在这条技术之路走得有多远。1.1. 阿里业务全貌

1.2 阿里技术大图

1.3 中间件技术大图

2.1 技术架构演进史• 1.0 → 2.0时代• LAMP向单体Java应用演进（性能）• 2.0 → 3.0 时代• 单体应用向大型分布式架构演进（效率）• 3.0 → 4.0 时代• 单IDC架构向多IDC架构演进（容量、稳定） 2.2 早期的淘宝 — 基于LAMP的1.0架构

2.3 发展中的淘宝 — 基本Java的2.0架构

2.4 流量带来的烦恼？

2.5 新的架构

2.6 开发维护成本高后期网站越做越大，对于网站的维护要求也越来越高、● 技术团队规模500人左右，维护变得越来越复杂● 单一War应用，应用包一直增长，更新业务特性越来越慢；数据逐步形成多个孤岛，无法拉通。● 基于传统应用开发架构，业务爆发，弹性不足，单点故障影响巨大。2.7 数据库问题突出双十一带来的段时间内流量暴增，对于服务器来说就是一场考验，太多的机器都需要连接数据库，然而连接池的资源是非常有限的，无法满足于应用的机器增长，对于数据库的维护需要24小时值守，一旦宕机就需要人工重新启动。面对新的问题，阿里开始了构架的第三场革命，应用拆分-3.0构架。

                                      

第二部分：分布式架构

前言随着问题的暴露，阿里技术官们还能勉强处理，但是双十一人流量的暴增，对于应用的要求也是越来越高，阿里一直在酝酿这一场技术革命。1 应用拆分

1.1 系统专业化分工千岛湖项目,交易中心(TC),类目属性中心(Forest)五彩石项目,店铺中心(SC),商品中心(IC),评价中心(RC)新组织结构支持1.1 服务中心团队用户中心(UIC),第一个业务中心于2008年上线中间件团队垂直产品团队

2 分布式构架2.1 HSF两个应用系统(集群)之间远程调用如同本地接口方法调用,远程调用对应用透明2.2 Pandora隔离中间件之间、中间件和应用之间对包的依赖提供中间件生命周期管理2.3 数据60000个+生产节点使用HSF和Pandora每天1000亿次的请求

3 数据库拆分3.1 垂直拆分大规模按业务拆分商品中心 用户中心 逐步换MySQL3.2 水平拆分数据按固定规则sharding到不同节点3.3 读写分离默认有主备做容灾

4 分布式数据库4.1 TDDL(CORONA)数据库水平拆分读写分离分布式强一致4.2 精卫/愚公数据库1对多分发和同步关系型数据库平滑扩容4.3 数据生产70000+节点使用TDDL每天1000亿+数据库调用通过TDDL每天100亿+增量数据通过精卫进行分发

精卫同步（交易买卖家）