淘宝架构演化
基本功能
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的请求始终进入同一个服务
原文地址：https://blog.csdn.net/lipviolet/article/details/143938512
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！