淘宝架构演化

基本功能

LAMP（Linux+Apache+MySQL+PHP）标准架构，初期采用拿来主义，只具备基本功能。

数据库：读写分离，MyISAM存储引擎

2003年5月—2004年1月

存储瓶颈

mysql达到访问瓶颈，升级成oracle，从开源转向商用。

oracle是连接池，php是短连接，直连会导致内存打满，引入SQL Relay连接池。

2004年1月—2004年5月

连接瓶颈

SQL Relay的问题无法处理，而Oracle又无可替代，只能替换掉php语言改用java

MVC框架是阿里的WebX，控制层用了EJB，持久层是ibatis。
另外，为了缓解数据库的压力，商品查询和店铺查询放在搜索引
擎中。

2004年2月—2005年3月

查询瓶颈

数据库分库分表、放弃EJB、引入Spring、加入缓存、加入CDN

2004年10月—2007年1月

存储瓶颈

多而小的海量图片存储查询问题，自研符合淘宝特性的海量文件存储系统用于存储图片。

借鉴 GFS（Google File System）开发出TFS（TaoBao File System）

典型的一主多从架构，主保存元数据进行索引，从进行存储，以block为基础单元。

域名-》DNS-》LVS-》nginx；kong的分布式特性可以代替LVS+nginx

前端有LVS+Haproxy将原图和其所有的缩略图请求都调度到同一台Image Server

在文件定位上，内存用Hash算法做索引，最多一次读盘。另外会有很多相同的图片重复上传上来，去除重复文件也是采用Hash算法来做的。写盘方式则采用Append方式写，并采用了淘汰策略FIFO，主要考虑降低硬盘的写操作，没有必要进一步提高Cache命中率，因为ImageServer和TFS位于同一个数据中心，读盘效率还是非常高的。

在创造了TFS和Tair之后，整个系统的架构如下图所示

架构之美

一个好的架构一定是可扩展和稳定，目前业内的通用办法是解耦，也就是拆分成微服务。

• UIC：用户中心（User Information Center）
• TC：交易中心（Trade Center）
• IC：商品中心（Item Center）
• SC：店铺中心（Shop Center）

这些中心级别的服务只提供原子级的业务逻辑，如根据ID查找商品、创建交易、减少库存等操作。再往上一层是业务系统TM（Trade Manager，交易业务）、IM（ItemManager，商品业务）、SM（Shop Manager，后来改名叫SS，即Shop System，店铺业务）、Detail（商品详情）。

拆分之后，系统之间的交互关系变得非常复杂

拆分的优点无非就是解耦的优点，但拆分必然伴随着三个问题：

• 实时调用的中间件：淘宝的HSF，高性能服务框架
• 异步消息通知的中间件：淘宝的Notify
• session共享：共享状态信息

涉及到的技术：

• 集群：大家做一样的事情
• 分布式：大家做不一样的事情
• 负载均衡：工作量相当
• 动态调控：动态增减资源

HSF

nacos+dubbo：解决服务间的调用，RPC调用

Notify

异步通知：MQ/Kafka

TDDL

分库分表：Taobao Distributed Data layer，之前一直以为很简单，那是因为没有想实际使用需要解决的问题，只想到一个 hash取模存储问题，其它问题一概没想

• 如何实现分布式Join（连接）？——在跨节点以后，简单的Join会变成M×N台机器的合并，这个代价比原来的基于数据库的单机Join大太多了。
• 如何实现高速多维度查询？——就像SNS中的消息系统，A发给B一个消息，那么A要看到的是我发给所有人的消息，而B要看到的是所有人发给我的消息。这种多维度查询，如何能够做到高效快捷呢？
• 如何实现分布式事务？——原始单机数据库中存在着大量的事务操作，在分布式以后，分布式事务的代价远远大于单机事务，那么这个矛盾也变得非常明显。

目前业内的解决办法：

• 利用uid进行shardingKey，此时uid相关的查询会本地join，分布式join部分在内存进行聚合。
• 内存聚合
• 二阶段提交，分布式事务业内很多解决办法

Sesssion

• 若是分布式则只能放到公共池中存储，例如redis
• 若是集群则可以考虑分流，保证同一个session的请求始终进入同一个服务