微服务治理六大支柱发现/配置/网关/熔断/链路/网格问题场景从单体拆成 20 个微服务。然后发现——服务 IP 天天变怎么发现20 个 yml 配置散落在各个仓库怎么统一管跨 5 个服务的请求到底慢在哪一段一个服务挂了怎么不拖垮全局这些不是微服务化自动解决的——是微服务治理六大支柱各自解决一个维度的问题。少一根支柱微服务化的收益就被运维复杂度完全抵消。30秒速览六大支柱各解决一个维度——① 服务发现Nacos APDistro 协议优先可用性② 配置管理Nacos CPRaft 协议优先一致性③ API 网关Spring Cloud Gateway 路由/限流④ 熔断降级Sentinel 慢调用比例/异常比例/异常数三种策略⑤ 链路追踪SkyWalking TraceID 跨服务传递一个请求从头到尾一条线⑥ 服务网格Istio 进阶Sidecar 接管流量。从 J01 到这里——17 篇文章从 JVM 到并发从 MySQL 到 Redis从单体到微服务形成了 Java 后端知识的完整闭环。本文是《Java 后端核心知识图谱》系列第 17 篇正刊收官共 172 篇。一、为什么需要微服务治理单体拆成微服务后从一个进程内的方法调用变成跨网络的 RPC 调用引入了一系列新问题单体时代微服务时代治理需求方法调用编译期绑定RPC 调用IP:Port 可能随时变化→服务发现配置文件在 classpath20 个服务 × 3 环境 60 份配置→配置中心一个入口没有外部流量问题几十个服务暴露 API鉴权/限流分散→API 网关单进程异常即 crash下游慢 ≠ 上游 crash但会雪崩→熔断限流堆栈日志一目了然请求跨 5 个服务日志散落各处→链路追踪一句话微服务治理不是锦上添花——拆得越多治理越重要。拆服务是分治理是把分出去的东西管起来。二、服务发现2.1 注册中心的核心数据模型服务提供者启动 → 向注册中心注册serviceName ip:port metadata 服务消费者启动 → 从注册中心订阅 → 缓存本地 长轮询监听变更 注册中心 → 健康检查心跳/主动探测→ 剔除不健康实例2.2 Nacos vs Eureka vs Consul维度NacosEurekaConsulCAP 模型CP AP 可切换APCP健康检查TCP/HTTP/MySQL/自定义客户端心跳15s续约TCP/HTTP/Script配置管理✅ 内置配置中心二合一❌ 需外接 Config Server✅ KV Store一致性协议自研 Distro(AP) Raft(CP)异步复制最终一致Raft适用场景国内微服务首选Spring Cloud Netflix 遗留多 DC 强一致性选型建议国内新项目首选 Nacos阿里开源、活跃维护、配置中心二合一、中文社区友好。2.3 保护阈值——防止雪崩的关键设计Nacos 的保护阈值生产建议值 0.8Nacos 源码默认为 0即关闭保护当健康实例比例降至 80%即约 20% 实例健康检查失败时触发保护。此时 Nacos 仍然返回所有实例健康的不健康的防止因注册中心误判导致流量全部压到剩余的少量健康实例上引发雪崩。实际场景K8s 滚动更新时旧 Pod 被 Kill 但 Nacos 心跳还没超时默认 15s保护阈值保证这 15 秒内流量均匀分配而非全部压到新 Pod。2.4 临时实例 vs 持久化实例临时实例默认主动心跳上报断连 15s 后自动剔除。适合 K8s Pod、弹性伸缩场景持久化实例注册中心主动探测不在线时保留元数据不剔除。适合数据库、MQ 等基础设施2.5 负载均衡策略服务发现告诉你有哪些实例可用负载均衡决定选哪个实例去调用。Spring Cloud LoadBalancer替代已弃用的 Ribbon通过LoadBalanced注解为RestTemplate/WebClient注入负载均衡能力。策略原理适用场景轮询Round Robin按顺序依次分配简单均匀实例配置相同、无状态服务默认最小连接数Least Connections选当前活跃连接数最少的实例长连接场景WebSocket/RPC一致性哈希Consistent Hash相同请求参数路由到同一实例需要会话保持的有状态服务加权响应时间Weighted Response Time根据实例响应时间动态调整权重实例配置异构不同规格机器混部区域感知Zone-Aware优先选择同区域实例跨区域降级多机房部署减少跨机房延迟三、配置中心3.1 配置隔离三层模型Nacos 配置中心Namespace环境隔离dev/test/prod→ Group业务分组ORDER_SERVICE→ Data ID具体配置文件名。spring:cloud:nacos:config:server-addr:127.0.0.1:8848namespace:prodgroup:ORDER_SERVICEfile-extension:yamlshared-configs:# 共享配置多服务复用-data-id:common-db.yamlgroup:COMMONrefresh:true# 动态刷新3.2 动态刷新原理Nacos 控制台修改配置 → 服务端发布 ConfigChangeEvent → 客户端长轮询30s 超时检测到 MD5 变化 → 拉取新配置 → Spring RefreshScope 重建 Bean⚠️RefreshScope只对真正需要热更新的配置类使用不要在Service等高频调用的 Bean 上滥用——被代理后每次方法调用都会检查是否需要重建。3.3 敏感配置加密Jasyptspring:datasource:password:ENC(3jFq9Kx2mP7vR5nW8tY1aB4cD6eF0gH)# 原文: MyDB2024# jasypt 3.xSpring Boot 3算法 PBEWithHmacSHA256AndAES_256java-jarjasypt-3.0.5.jarinputMyDB2024passwordmaster-key# 启动时传入主密钥不写在配置文件中java-jarapp.jar--jasypt.encryptor.passwordyour-master-key⚠️ Jasypt 适合中小项目快速落地金融/合规强需求 → 升级到 Vault KMS 方案。3.4 Apollo vs Nacos 选型维度ApolloNacos灰度发布✅ 完善的发布审核→灰度→全量流程✅ 支持但不如 Apollo 成熟权限审计✅ 完善⚠️ 开源版权限较弱注册发现❌ 仅配置中心✅ 配置注册二合一需要配置审核流程和操作审计 → Apollo需要注册配置二合一的中小团队 → Nacos。四、API 网关网关是微服务对外的唯一入口承担横切关注点的统一处理——鉴权、限流、日志、路由、跨域都应在网关层完成。4.1 Spring Cloud Gateway 核心路由spring:cloud:gateway:routes:-id:order-serviceuri:lb://order-service# lb:// 负载均衡predicates:-Path/api/orders/**filters:-StripPrefix1-name:RequestRateLimiter# 令牌桶限流args:redis-rate-limiter.replenishRate:100redis-rate-limiter.burstCapacity:200-name:CircuitBreaker# 网关层熔断args:name:orderServiceCBfallbackUri:forward:/fallback/order4.2 网关的高可用自身高可用网关无状态 → 多实例部署 Nginx L4 前置下游容错超时 重试幂等接口 熔断 降级fallbackUri限流维度接口级QPS 100 用户级单用户 10/s IP 级防盗刷五、熔断与限流Sentinel5.1 熔断、降级、限流的区别机制触发条件行为恢复熔断下游错误率 阈值如 50%快速失败不再调用下游半开状态试探恢复降级下游不可用/超时返回兜底响应fallback下游恢复后自动切回限流QPS 超过阈值拒绝超量请求下一秒重新计数三者配合限流——主动控制流量未雨绸缪熔断——下游出错时保护自己亡羊补牢降级——出错时保证基本体验底线兜底。5.2 Sentinel 核心规则// 流控规则 — SentinelResource 注解SentinelResource(valuecreateOrder,blockHandlercreateOrderBlock)publicOrdercreateOrder(OrderDTOdto){...}// 熔断规则DegradeRulerulenewDegradeRule(remoteService).setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO).setCount(0.5)// 异常比例阈值 50%.setTimeWindow(10);// 熔断时长 10s后半开试探5.3 三种流控效果效果行为场景快速失败超过阈值直接抛 FlowExceptionAPI 限流最常用Warm Up阈值从 1/3 逐步升到目标值秒杀开始前的系统预热排队等待请求排队匀速通过对延迟不敏感的消息处理六、分布式链路追踪SkyWalking6.1 为什么堆栈日志不够用一个用户请求 → Gateway → OrderService → InventoryService → PaymentService。OrderService 超时了是它自己慢还是下游 InventoryService 慢逐个服务翻日志 大海捞针。链路追踪用一个全局 TraceId 串起所有调用。6.2 SkyWalking Agent 零侵入接入# -javaagent:/path/to/skywalking-agent.jar# -DSW_AGENT_NAMEorder-service# -DSW_AGENT_COLLECTOR_BACKEND_SERVICESskywalking-oap:11800Agent 通过字节码增强自动拦截 Spring MVC、Dubbo、Feign、MyBatis、Redis、Kafka 等常见框架的调用零代码侵入即可获得完整调用链。6.3 链路追踪的价值场景无追踪有追踪某接口 P99 慢了逐个服务查慢日志直接定位到慢 Span 对应 SQL某个下游挂了影响面看报警不知道谁调了它拓扑图展示所有上游调用方性能瓶颈定位凭经验猜测链路拓扑 耗时占比一目了然七、服务网格Service Mesh7.1 Sidecar 模式将通信逻辑负载均衡、熔断、重试、TLS从应用代码中剥离到独立的 Sidecar 代理通常用 Envoy中┌──────────────────────────────┐ │ Pod │ │ ┌──────────┐ ┌──────────┐ │ │ │ 业务容器 │→│ Sidecar │→│ 网络 │ │(无SDK) │ │ (Envoy) │ │ │ └──────────┘ └──────────┘ │ └──────────────────────────────┘7.2 什么时候需要 Service Mesh❌ 团队 20 人、服务 15 个 → Sentinel Gateway SkyWalking 够用Service Mesh 运维成本 收益✅ 多语言微服务Java Go Python→ 用 Mesh 统一治理避免为每种语言维护一套 SDK✅ 需要零代码侵入的 mTLS 全链路加密✅ 需要细粒度的流量管理按 Header/Cookie 路由、百分比灰度国内现状大多数团队用 Spring Cloud AlibabaNacos Sentinel Gateway已经能解决 90% 的治理需求。Service Mesh 是进阶选项而非必选项。八、治理能力矩阵速查治理维度核心组件解决的问题生产就绪检查项服务发现Nacos/Eureka实例动态上下线保护阈值、健康检查、AP/CP 选型配置中心Nacos/Apollo配置一致性与热更新敏感信息加密、灰度发布、版本回滚API 网关Spring Cloud Gateway统一入口、横切关注点自身高可用、超时重试、限流熔断熔断限流Sentinel防止雪崩、流量整形规则持久化、降级策略、控制台监控链路追踪SkyWalking调用链可视、瓶颈定位TraceId 传递完整性、采样率服务网格Istio/Envoy通信逻辑剥离进阶只在多语言或安全合规强需求时引入九、实战金融系统的三层容错以某商业银行交易链路为例——Gateway → OrderService → InventoryService → PaymentService第一层网关IP 级限流 200 QPS 用户级限流 10 QPS 无效 Token 直接 401。第二层服务间OrderService 调 InventoryService 配置 Sentinel 熔断异常比例 50% → 熔断 10s → fallback 返回库存服务繁忙。OrderService 调 PaymentService 配置超时重试超时 2s → 重试 1 次支付接口自带幂等→ 仍失败 → 快速失败。第三层兜底全局异常 → 降级订单状态为待处理 → 定时任务补偿 人工介入。设计原则每层只做自己最擅长的事。网关做鉴权和粗粒度限流Sentinel 做细粒度熔断业务代码做补偿逻辑。不要把所有容错逻辑堆在一层。核心要点回顾服务发现是微服务治理的基石——注册中心Nacos 为首选解决实例在哪的问题保护阈值防止误判引发雪崩五种负载均衡策略覆盖从无状态轮询到区域感知的完整场景。配置中心解决 20 个服务 × 3 环境的配置散落问题——Nacos 三层隔离Namespace/Group/Data IDRefreshScope动态刷新 Jasypt 加密敏感信息。Apollo 在审核流程和灰度发布上更成熟适合大型企业。API 网关Spring Cloud Gateway作为对外的唯一入口承担鉴权/限流/路由/跨域的统一处理——通过lb://负载均衡路由 RequestRateLimiter 令牌桶限流 GlobalFilter 全局鉴权。Sentinel提供三个维度的容错——限流主动控制流量、熔断下游异常比例超过阈值后快速失败半开恢复、降级返回 fallback 兜底响应。三者协同形成未雨绸缪→亡羊补牢→底线兜底的递进防御。SkyWalking通过字节码增强实现零侵入的链路追踪——一个 TraceId 串起所有 Span拓扑图直观展示调用关系和耗时占比瓶颈定位从逐服务翻日志变为点击慢 Span 直接看 SQL。Service Mesh将通信逻辑从代码剥离到 Sidecar适合多语言微服务和零代码侵入 mTLS 场景——但对大多数 Spring Cloud 团队来说这是进阶选项而非必选项。上一篇《分库分表》 | 下一篇《Oracle与信创迁移》番外系列专栏《Java 后端核心知识图谱》Java专栏 正刊 17 篇完结——从 JVM 到微服务每一篇回答一个核心问题。番外篇继续。聊聊你的经历从单体拆到微服务最大的坑是什么来投个票A. 分布式链路追踪拆完不知道慢在哪B. 配置管理散落各仓库不敢改C. 熔断策略阈值设错要么不熔断要么全熔断D. 服务拆分粒度拆太细运维爆炸、拆太粗跟单体没区别。我选 A——原来一个请求 3 秒拆完不知道哪段慢。你选哪个如果这套六大支柱架构图帮你理清了微服务治理的完整版图欢迎收藏点赞 单体拆成20个微服务才发现：服务IP天天变、配置散落20个仓库、一个请求跨5个服务不知慢在哪→微服务治理六大支柱+从JVM到微服务的完整知识闭环
微服务治理六大支柱发现/配置/网关/熔断/链路/网格问题场景从单体拆成 20 个微服务。然后发现——服务 IP 天天变怎么发现20 个 yml 配置散落在各个仓库怎么统一管跨 5 个服务的请求到底慢在哪一段一个服务挂了怎么不拖垮全局这些不是微服务化自动解决的——是微服务治理六大支柱各自解决一个维度的问题。少一根支柱微服务化的收益就被运维复杂度完全抵消。30秒速览六大支柱各解决一个维度——① 服务发现Nacos APDistro 协议优先可用性② 配置管理Nacos CPRaft 协议优先一致性③ API 网关Spring Cloud Gateway 路由/限流④ 熔断降级Sentinel 慢调用比例/异常比例/异常数三种策略⑤ 链路追踪SkyWalking TraceID 跨服务传递一个请求从头到尾一条线⑥ 服务网格Istio 进阶Sidecar 接管流量。从 J01 到这里——17 篇文章从 JVM 到并发从 MySQL 到 Redis从单体到微服务形成了 Java 后端知识的完整闭环。本文是《Java 后端核心知识图谱》系列第 17 篇正刊收官共 172 篇。一、为什么需要微服务治理单体拆成微服务后从一个进程内的方法调用变成跨网络的 RPC 调用引入了一系列新问题单体时代微服务时代治理需求方法调用编译期绑定RPC 调用IP:Port 可能随时变化→服务发现配置文件在 classpath20 个服务 × 3 环境 60 份配置→配置中心一个入口没有外部流量问题几十个服务暴露 API鉴权/限流分散→API 网关单进程异常即 crash下游慢 ≠ 上游 crash但会雪崩→熔断限流堆栈日志一目了然请求跨 5 个服务日志散落各处→链路追踪一句话微服务治理不是锦上添花——拆得越多治理越重要。拆服务是分治理是把分出去的东西管起来。二、服务发现2.1 注册中心的核心数据模型服务提供者启动 → 向注册中心注册serviceName ip:port metadata 服务消费者启动 → 从注册中心订阅 → 缓存本地 长轮询监听变更 注册中心 → 健康检查心跳/主动探测→ 剔除不健康实例2.2 Nacos vs Eureka vs Consul维度NacosEurekaConsulCAP 模型CP AP 可切换APCP健康检查TCP/HTTP/MySQL/自定义客户端心跳15s续约TCP/HTTP/Script配置管理✅ 内置配置中心二合一❌ 需外接 Config Server✅ KV Store一致性协议自研 Distro(AP) Raft(CP)异步复制最终一致Raft适用场景国内微服务首选Spring Cloud Netflix 遗留多 DC 强一致性选型建议国内新项目首选 Nacos阿里开源、活跃维护、配置中心二合一、中文社区友好。2.3 保护阈值——防止雪崩的关键设计Nacos 的保护阈值生产建议值 0.8Nacos 源码默认为 0即关闭保护当健康实例比例降至 80%即约 20% 实例健康检查失败时触发保护。此时 Nacos 仍然返回所有实例健康的不健康的防止因注册中心误判导致流量全部压到剩余的少量健康实例上引发雪崩。实际场景K8s 滚动更新时旧 Pod 被 Kill 但 Nacos 心跳还没超时默认 15s保护阈值保证这 15 秒内流量均匀分配而非全部压到新 Pod。2.4 临时实例 vs 持久化实例临时实例默认主动心跳上报断连 15s 后自动剔除。适合 K8s Pod、弹性伸缩场景持久化实例注册中心主动探测不在线时保留元数据不剔除。适合数据库、MQ 等基础设施2.5 负载均衡策略服务发现告诉你有哪些实例可用负载均衡决定选哪个实例去调用。Spring Cloud LoadBalancer替代已弃用的 Ribbon通过LoadBalanced注解为RestTemplate/WebClient注入负载均衡能力。策略原理适用场景轮询Round Robin按顺序依次分配简单均匀实例配置相同、无状态服务默认最小连接数Least Connections选当前活跃连接数最少的实例长连接场景WebSocket/RPC一致性哈希Consistent Hash相同请求参数路由到同一实例需要会话保持的有状态服务加权响应时间Weighted Response Time根据实例响应时间动态调整权重实例配置异构不同规格机器混部区域感知Zone-Aware优先选择同区域实例跨区域降级多机房部署减少跨机房延迟三、配置中心3.1 配置隔离三层模型Nacos 配置中心Namespace环境隔离dev/test/prod→ Group业务分组ORDER_SERVICE→ Data ID具体配置文件名。spring:cloud:nacos:config:server-addr:127.0.0.1:8848namespace:prodgroup:ORDER_SERVICEfile-extension:yamlshared-configs:# 共享配置多服务复用-data-id:common-db.yamlgroup:COMMONrefresh:true# 动态刷新3.2 动态刷新原理Nacos 控制台修改配置 → 服务端发布 ConfigChangeEvent → 客户端长轮询30s 超时检测到 MD5 变化 → 拉取新配置 → Spring RefreshScope 重建 Bean⚠️RefreshScope只对真正需要热更新的配置类使用不要在Service等高频调用的 Bean 上滥用——被代理后每次方法调用都会检查是否需要重建。3.3 敏感配置加密Jasyptspring:datasource:password:ENC(3jFq9Kx2mP7vR5nW8tY1aB4cD6eF0gH)# 原文: MyDB2024# jasypt 3.xSpring Boot 3算法 PBEWithHmacSHA256AndAES_256java-jarjasypt-3.0.5.jarinputMyDB2024passwordmaster-key# 启动时传入主密钥不写在配置文件中java-jarapp.jar--jasypt.encryptor.passwordyour-master-key⚠️ Jasypt 适合中小项目快速落地金融/合规强需求 → 升级到 Vault KMS 方案。3.4 Apollo vs Nacos 选型维度ApolloNacos灰度发布✅ 完善的发布审核→灰度→全量流程✅ 支持但不如 Apollo 成熟权限审计✅ 完善⚠️ 开源版权限较弱注册发现❌ 仅配置中心✅ 配置注册二合一需要配置审核流程和操作审计 → Apollo需要注册配置二合一的中小团队 → Nacos。四、API 网关网关是微服务对外的唯一入口承担横切关注点的统一处理——鉴权、限流、日志、路由、跨域都应在网关层完成。4.1 Spring Cloud Gateway 核心路由spring:cloud:gateway:routes:-id:order-serviceuri:lb://order-service# lb:// 负载均衡predicates:-Path/api/orders/**filters:-StripPrefix1-name:RequestRateLimiter# 令牌桶限流args:redis-rate-limiter.replenishRate:100redis-rate-limiter.burstCapacity:200-name:CircuitBreaker# 网关层熔断args:name:orderServiceCBfallbackUri:forward:/fallback/order4.2 网关的高可用自身高可用网关无状态 → 多实例部署 Nginx L4 前置下游容错超时 重试幂等接口 熔断 降级fallbackUri限流维度接口级QPS 100 用户级单用户 10/s IP 级防盗刷五、熔断与限流Sentinel5.1 熔断、降级、限流的区别机制触发条件行为恢复熔断下游错误率 阈值如 50%快速失败不再调用下游半开状态试探恢复降级下游不可用/超时返回兜底响应fallback下游恢复后自动切回限流QPS 超过阈值拒绝超量请求下一秒重新计数三者配合限流——主动控制流量未雨绸缪熔断——下游出错时保护自己亡羊补牢降级——出错时保证基本体验底线兜底。5.2 Sentinel 核心规则// 流控规则 — SentinelResource 注解SentinelResource(valuecreateOrder,blockHandlercreateOrderBlock)publicOrdercreateOrder(OrderDTOdto){...}// 熔断规则DegradeRulerulenewDegradeRule(remoteService).setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO).setCount(0.5)// 异常比例阈值 50%.setTimeWindow(10);// 熔断时长 10s后半开试探5.3 三种流控效果效果行为场景快速失败超过阈值直接抛 FlowExceptionAPI 限流最常用Warm Up阈值从 1/3 逐步升到目标值秒杀开始前的系统预热排队等待请求排队匀速通过对延迟不敏感的消息处理六、分布式链路追踪SkyWalking6.1 为什么堆栈日志不够用一个用户请求 → Gateway → OrderService → InventoryService → PaymentService。OrderService 超时了是它自己慢还是下游 InventoryService 慢逐个服务翻日志 大海捞针。链路追踪用一个全局 TraceId 串起所有调用。6.2 SkyWalking Agent 零侵入接入# -javaagent:/path/to/skywalking-agent.jar# -DSW_AGENT_NAMEorder-service# -DSW_AGENT_COLLECTOR_BACKEND_SERVICESskywalking-oap:11800Agent 通过字节码增强自动拦截 Spring MVC、Dubbo、Feign、MyBatis、Redis、Kafka 等常见框架的调用零代码侵入即可获得完整调用链。6.3 链路追踪的价值场景无追踪有追踪某接口 P99 慢了逐个服务查慢日志直接定位到慢 Span 对应 SQL某个下游挂了影响面看报警不知道谁调了它拓扑图展示所有上游调用方性能瓶颈定位凭经验猜测链路拓扑 耗时占比一目了然七、服务网格Service Mesh7.1 Sidecar 模式将通信逻辑负载均衡、熔断、重试、TLS从应用代码中剥离到独立的 Sidecar 代理通常用 Envoy中┌──────────────────────────────┐ │ Pod │ │ ┌──────────┐ ┌──────────┐ │ │ │ 业务容器 │→│ Sidecar │→│ 网络 │ │(无SDK) │ │ (Envoy) │ │ │ └──────────┘ └──────────┘ │ └──────────────────────────────┘7.2 什么时候需要 Service Mesh❌ 团队 20 人、服务 15 个 → Sentinel Gateway SkyWalking 够用Service Mesh 运维成本 收益✅ 多语言微服务Java Go Python→ 用 Mesh 统一治理避免为每种语言维护一套 SDK✅ 需要零代码侵入的 mTLS 全链路加密✅ 需要细粒度的流量管理按 Header/Cookie 路由、百分比灰度国内现状大多数团队用 Spring Cloud AlibabaNacos Sentinel Gateway已经能解决 90% 的治理需求。Service Mesh 是进阶选项而非必选项。八、治理能力矩阵速查治理维度核心组件解决的问题生产就绪检查项服务发现Nacos/Eureka实例动态上下线保护阈值、健康检查、AP/CP 选型配置中心Nacos/Apollo配置一致性与热更新敏感信息加密、灰度发布、版本回滚API 网关Spring Cloud Gateway统一入口、横切关注点自身高可用、超时重试、限流熔断熔断限流Sentinel防止雪崩、流量整形规则持久化、降级策略、控制台监控链路追踪SkyWalking调用链可视、瓶颈定位TraceId 传递完整性、采样率服务网格Istio/Envoy通信逻辑剥离进阶只在多语言或安全合规强需求时引入九、实战金融系统的三层容错以某商业银行交易链路为例——Gateway → OrderService → InventoryService → PaymentService第一层网关IP 级限流 200 QPS 用户级限流 10 QPS 无效 Token 直接 401。第二层服务间OrderService 调 InventoryService 配置 Sentinel 熔断异常比例 50% → 熔断 10s → fallback 返回库存服务繁忙。OrderService 调 PaymentService 配置超时重试超时 2s → 重试 1 次支付接口自带幂等→ 仍失败 → 快速失败。第三层兜底全局异常 → 降级订单状态为待处理 → 定时任务补偿 人工介入。设计原则每层只做自己最擅长的事。网关做鉴权和粗粒度限流Sentinel 做细粒度熔断业务代码做补偿逻辑。不要把所有容错逻辑堆在一层。核心要点回顾服务发现是微服务治理的基石——注册中心Nacos 为首选解决实例在哪的问题保护阈值防止误判引发雪崩五种负载均衡策略覆盖从无状态轮询到区域感知的完整场景。配置中心解决 20 个服务 × 3 环境的配置散落问题——Nacos 三层隔离Namespace/Group/Data IDRefreshScope动态刷新 Jasypt 加密敏感信息。Apollo 在审核流程和灰度发布上更成熟适合大型企业。API 网关Spring Cloud Gateway作为对外的唯一入口承担鉴权/限流/路由/跨域的统一处理——通过lb://负载均衡路由 RequestRateLimiter 令牌桶限流 GlobalFilter 全局鉴权。Sentinel提供三个维度的容错——限流主动控制流量、熔断下游异常比例超过阈值后快速失败半开恢复、降级返回 fallback 兜底响应。三者协同形成未雨绸缪→亡羊补牢→底线兜底的递进防御。SkyWalking通过字节码增强实现零侵入的链路追踪——一个 TraceId 串起所有 Span拓扑图直观展示调用关系和耗时占比瓶颈定位从逐服务翻日志变为点击慢 Span 直接看 SQL。Service Mesh将通信逻辑从代码剥离到 Sidecar适合多语言微服务和零代码侵入 mTLS 场景——但对大多数 Spring Cloud 团队来说这是进阶选项而非必选项。上一篇《分库分表》 | 下一篇《Oracle与信创迁移》番外系列专栏《Java 后端核心知识图谱》Java专栏 正刊 17 篇完结——从 JVM 到微服务每一篇回答一个核心问题。番外篇继续。聊聊你的经历从单体拆到微服务最大的坑是什么来投个票A. 分布式链路追踪拆完不知道慢在哪B. 配置管理散落各仓库不敢改C. 熔断策略阈值设错要么不熔断要么全熔断D. 服务拆分粒度拆太细运维爆炸、拆太粗跟单体没区别。我选 A——原来一个请求 3 秒拆完不知道哪段慢。你选哪个如果这套六大支柱架构图帮你理清了微服务治理的完整版图欢迎收藏点赞