SpringCloud架构

SpringCloud初学笔记——1.架构

学习视频为尚硅谷2025SpringCloud教程

单体架构

所有的功能模块都在一个项目

优点：开发部署方便

缺点：无法应对高并发 alt

集群架构

多个服务器一起工作就叫集群，集群其实是一种物理形态，而分布式是一种工作方式用户访问网址时，网关将请求路由，通过负载均衡算法把请求的流量均摊给服务器优点：可以解决大并发缺点：

模块化升级会导致牵一发而动全身（需要将全部服务器的模块下架升级）
不同语言开发的模块如何分工协作（多语言团队问题）

分布式架构

微服务：将大应用按照业务功能模块进行拆分，拆分出来的小应用就叫做微服务。每一个微服务可以独立部署，当并发量高的时候，整体的数据库可能卡顿，所以整体数据库也按照业务边界来拆分成不同业务的单独数据库，当微服务做业务的时候，只连上自己的数据库即可，当微服务需要调用其他数据库时，向对应的微服务发送请求即可，这样的话就做到了数据隔离，因为每个微服务可以单独部署，就可以用不同语言开发，实现自治，且与语言无关

独立部署
数据隔离
自治，语言无关

副本思想：每一个微服务都有他的几个副本在其他服务器里，这样可以解决单点故障问题

单点故障：要是将微服务副本都集中在一个服务器里，当该服务器宕机，其他服务器就没有了这个服务，整个应用就无法提供完整服务。

Remote Procedure Call：远程过程调用，简称RPC，通常为HTTP+JSON,也有其他不同方式。

注册中心：在远程调用期间，用户如何知道要调用的业务在哪个服务器，如果调用业务的服务器宕机，如何让他连上其他服务器的业务，想要做到这些，需要两个机制，分别是服务发现和服务注册，

服务注册：当某一个微服务部署到服务器上线了，他需要连上注册中心且发送上下线消息，这样注册中心将会保存信息到服务-IP清单列表。
服务发现：用户远程调用业务时，会先向注册中心发送请求查询业务位置，这时候可以用负载均衡技术将调用请求均衡分配。
配置中心：统一管理用户的配置文件，当用户微服务配置文件发生变化，主动推送配置变更给指定的微服务

服务雪崩：当订单调用支付服务时卡住，得不到返回结果，在高并发的情况下，百万请求都在支付业务里卡住，结果一个微服务的卡顿就会导致整个调用链的卡顿，随着请求流量的加大，就会导致服务器资源的耗尽，最终导致服务雪崩，要解决这个问题就要用服务熔断机制。 服务熔断（快速失败机制）：在远程调用期间，用户发起对订单的调用，当发现调用卡时，就做出一个快速返回，快速执行完成。这样，每一个调用量都很快的情况下，请求就不会过量积压。那如何得知要不要等，这时候就用熔断机制，比如在熔断里配置“5秒内50%的请求发生了卡顿，那么5秒后发送的所有请求就都直接快速失败”，快速失败及时释放这些资源，就不会导致服务器资源耗尽。