Survive by day and develop by night.
talk for import biz , show your perfect code,full busy，skip hardness,make a better result,wait for change,challenge Survive.
happy for hardess to solve denpendies.

目录

概述

需求：

1、单库单应用架构：最简单的，可能大家都见过

设计思路

实现思路分析

1.URL管理

1、单库单应用架构：最简单的，可能大家都见过
2、内容分发架构：目前用的比较多
3.、读写分离架构：对于大并发的查询、业务

2.微服务架构

4、微服务架构：适用于复杂的业务模式的拆解

5、多级缓存架构：可以把缓存玩的很好
6、分库分表架构：解决单体数据库瓶颈

3.四、微服务架构

1、单体数据库写请求量大量增加，导致数据库压力变大
2、数据库一旦挂了，那么整个业务都挂了

3、业务代码越来越多，都在一个GIT里，越来越难以维护

4、代码腐化严重，臭味越来越浓
如上图所示，我把业务分块，做了垂直切分，切成一个个独立的系统，每个系统各自衍化，有自己的库、缓存、ES等辅助系统，系统之间的实时交互通过RPC，异步交互通过MQ，通过这种组合，共同完成整个系统功能。

对于问题一，由于拆分成多个子系统，系统的压力被分散了，而各个子系统都有自己的数据库实例，所以数据库的压力变小。
对于问题二，一个子系统A的数据库挂了，只是影响到系统A和使用系统A的那些功能，不会所有的功能不可用，从而解决一个数据库挂了，导致所有的功能都不可用的情况。

对于问题三、四，也因为拆分得到了解决，各个子系统都有自己独立的GIT代码库，不会相互影响。通用的模块可通过库、服务、平台的形式解决。

4.多级缓存架构

这个模式可以说是应对超高查询压力的一种普遍采用的策略，基本的思想就是在所有链路的地方，能加缓存的就加缓存，如下图所示：

如上图所示，一般在三个地方加入缓存，一个是客户端处，一个是API网关处，一个是具体的后端业务处，下面分别介绍：

客户端处缓存：这个地方加缓存可以说是效果最好的一个——无延迟。因为不用经过长长的网络链条去后端业务处获取数据，从而导致加载时间过长，客户流失等损失，虽然有CDN的支持，但是从客户端到CDN还是有网络延迟的，虽然不大，具体的技术依据不同的客户端而定，对于WEB来讲，有浏览器本地缓存、Cookie、Storage、缓存策略等技术；对于APP来讲，有本地数据库，本地文件，本地内存，进程内缓存支持，以上提到的各种技术有兴趣的同学可以继续展开学习，如果客户端缓存没有命中，那么会去后端业务拿数据，一般来讲，就会有个API网关，在这里加缓存也是非常重要的。

优点：抗住大量读请求，减少后端压力。

缺点：数据一致性问题较为突出，容易发生雪崩，即：如果客户端缓存失效、API网关缓存失效，那么所有的大量请求瞬间压向后端业务系统，后果可想而知。

六、分库分表架构
这种模式主要解决单表写入、读取 、存储压力过大，从而导致业务缓慢甚至超时，交易失败，容量不够的问题。一般有水平切分和垂直切分两种，这里主要介绍水平切分。这个模式也是技术架构迭代演进的必经之路。

主机：这是最主要的也是最重要的点，本质上分库分表是因为计算与存储资源不够导致的，而这种资源主要由物理机，主机提供的，毕竟没有可用的计算资源，怎么分效果都不是太好。

参考资料和推荐阅读

1. https://blog.csdn.net/weixin_38889300/article/details/121433945

欢迎阅读，各位老铁，如果对你有帮助，点个赞加个关注呗！~
如有侵权，请私信联系删除，多谢啦