分布式应用架构的演变
整体演变过程
第一阶段：单一应用架构
单一应用架构，是把所有服务都放在一个项目中，进行打包部署到服务器上，如果流量特别大的话，就在另外的服务器上部署相同的功能模块用来分摊流量。但是这样的话，一旦有某个功能模块需要修改，就需要将修改后的整个项目重新打包部署到这些服务器上
第二阶段：垂直应用架构
将大的应用拆成了各个独立的小应用，且每个应用都是完整的，从页面到业务逻辑到程序数据库都是完整的。当某一块的小应用用户访问量比较大，就将该应用多放几台，分摊访问量
优点：
- 分工独立，不同的人负责开发维护不同的模块，各个模块互不干扰
- 性能扩展比较容易，如用户模块需要扩展，就直接将用户模块放在多个服务器上就好了
缺点：
- 因为界面可能需要经常美化，所以页面一改，就需要把这个小业务模块的整个都重新部署（即：没实现界面+业务逻辑的分离
- 模块可能会逐渐增多，业务模块间可能做不到完全独立，大量的应用之间需要交互
第三阶段：分布式服务架构
将界面与业务逻辑分离开，此时web界面可能与Service逻辑业务不在同一个服务器上，之前在同一个服务器上时，属于进程间调用；现在的话，在不同服务器间调用，我们称为RPC（远程过程调用）
缺点：可能用户业务访问量比较小，却有100台服务器在跑，商品业务访问量比较大，却只有10台服务器在跑，就会造成资源的浪费，此时就需要一个调度中心，能够实时监控流量等数据，来基于访问压力来动态分配服务器资源，提高资源利用率
第四阶段：流动计算架构
引入调度中心，用于维护各个不同服务模块之间的复杂关系以及实时管理整个服务集群。给不同访问压力的业务逻辑分配不同大小的服务器资源，且同一个业务逻辑，优先将新来的请求分配给正在处理该模块业务逻辑的服务器中压力较小的那个（比如用户模块被分配了3台服务器，服务器1正在处理10个请求，服务器2正在处理1000个请求，服务器3正在处理100000个请求，那么新进来的请求就会分配给服务器1或者2而不分配给3了）
优点：基于访问压力实时管理集群容量，提高集群利用率
参考链接：https://www.bilibili.com/video/BV1ns411c7jV
原文地址：https://blog.csdn.net/qq_73700396/article/details/147212195
免责声明：本站文章内容转载自网络资源，如侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！