阿里电商架构演变之路

阿里电商架构演变之路

第一部分技术架构演进

前言

阿里应该是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 垂直拆分

大规模按业务拆分

商品中心用户中心逐步换MySQL 3.2 水平拆分

数据按固定规则sharding到不同节点3.3 读写分离

默认有主备做容灾

4 分布式数据库

4.1 TDDL(CORONA)

数据库水平拆分

读写分离

分布式强一致

4.2 精卫/愚公

数据库1对多分发和同步

关系型数据库平滑扩容

4.3 数据

生产70000+节点使用TDDL

每天1000亿+数据库调用通过TDDL 每天100亿+增量数据通过精卫进行分发

精卫同步（交易买卖家）