SpringCloud八股分析

mengnankkzhou2025-09-242025-09-24

SpringCloud

核心机制: 长轮询（Long Polling）。

客户端行为: 应用启动后，客户端向Nacos Server请求配置，并建立一个长轮询连接，询问配置是否有更新。

服务端行为: 如果配置无变更，服务端会hold住请求30秒（默认）；如果期间配置发生变更，立即响应；如果超时，也返回一个空响应。

刷新流程: 客户端收到变更响应后，拉取最新配置，发布EnvironmentChangeEvent事件。

Spring侧响应: @RefreshScope注解的Bean监听到事件后，会销毁并重新创建，从而加载到新配置。

通信模型升级: 最大的变化是从HTTP短连接轮询模型升级为gRPC长连接模型。

性能提升: gRPC基于HTTP/2，使用长连接和二进制协议，大大降低了通信开销和服务器压力，服务注册/发现和配置推送的性能提升了一个数量级。

推送机制: 从1.x的UDP推送通知+HTTP拉取数据，变为2.x的gRPC直接推送数据，实时性更强，更可靠。

架构演进: 2.x引入了统一的连接管理和请求处理模型，为后续的架构演进打下了更好的基础。

客户端兼容: Nacos 2.x服务端兼容1.x的客户端，保证了平滑升级。

部署架构: 生产环境至少部署3个（或更多奇数个）Nacos节点，构成集群。

流量入口: 前端通过一个统一的入口（如Nginx、SLB）将客户端请求反向代理到后端的Nacos集群，实现负载均衡和故障转移。

数据持久化: 集群所有节点共享同一个外部数据源（通常是高可用的MySQL集群），保证了配置等强一致性数据的统一存储。

节点间通信: 节点间会互相通信，同步服务实例等信息。

客户端容灾: Nacos客户端会配置集群中所有节点的地址。当某个节点宕机时，客户端会自动切换到其他健康的节点上，实现Failover。

目的: 实现精确、实时的QPS等指标统计。

结构: 基于一个环形数组，每个数组元素是一个“时间桶”（Bucket），用于存储一小段时间内的统计数据。

时间窗口: 整个数组代表一个完整的时间窗口（如1秒）。

滑动机制: 随着时间流逝，一个指针会向前移动，过时的时间桶会被清空并复用于记录新的数据，从而实现窗口的“滑动”效果。

聚合: 统计总QPS时，会聚合当前时间窗口内所有有效时间桶的数据。

触发条件不同:
- blockHandler：仅当请求被Sentinel的规则（流控、熔断、系统保护等）阻止时调用。
- fallback：当被注解的方法内部抛出任何业务异常（Throwable）时调用。
优先级: 如果同时配置了两者，并且发生了业务异常，fallback会优先被调用。只有在没有业务异常，但触发了Sentinel规则时，blockHandler才会生效。
参数签名不同:
- blockHandler的方法签名需要与原方法保持一致，但可以在末尾额外添加一个BlockException类型的参数。
- fallback的方法签名也需要与原方法一致，但可以在末尾额外添加一个Throwable类型的参数。