当前位置：首页 > article >正文

淘宝架构演化

article 2024/11/30 7:19:37

基本功能

在这里插入图片描述
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要看到的是所有人发给我的消息。这种多维度查询，如何能够做到高效快捷呢？
如何实现分布式事务？——原始单机数据库中存在着大量的事务操作，在分布式以后，分布式事务的代价远远大于单机事务，那么这个矛盾也变得非常明显。

目前业内的解决办法：