RPC框架

Dubbo 集群容错 📖 前置阅读：本文假设读者已掌握 SpringBoot Dubbo 的基本 RPC 操作（@DubboService / @DubboReference）。如果还不熟悉，建议先阅读 SpringBoot Dubbo 全操作指南。 一、⚡ 问题切入：RPC 调用失败了怎么办？ 上一篇文章的 @DubboReference 默认配置了三件事： Provider 有多个实例时——随机选一个（负载均衡） 调用失败时——自动重试 2 次（集群容错） 调用超过 1 秒——抛超时异常 默认策略覆盖了 80% 的场景，但剩下的 20% 需要精确控制——这就是 Dubbo 服务治理的核心：集群容错（怎么处理失败）、负载均衡（怎么选择节点）、调用模式（同步还是异步）。 二、集群容错 —— 失败了怎么办 2.1 六种集群容错策略 Dubbo 的 Cluster 接口定义了容错行为。Consumer 侧配置： 策略 配置值 行为 适用场景 Failover（默认） failover 失败后自动切换其他 Provider 重试，默认重试 2 次（共 3 次调用） 幂等的读操作 Failfast failfast 失败后立即报错——不重试 非幂等写操作（创建订单、扣库存） Failsafe failsafe 失败后吞掉异常——返回 null / 忽略错误 非关键操作（日志、通知） Failback failback 失败后记录到后台线程——定时重试 最终一致性场景（数据同步） Forking forking 同时调用所有 Provider——取第一个成功返回的 高可用低延迟，但浪费资源 Broadcast broadcast 逐个调用所有 Provider——任何一个失败就报错 通知所有实例（缓存刷新、配置更新） // 消费端配置集群容错策略 @DubboReference( cluster = "failfast", // 写操作——不重试 retries = 0 // 即使 Failover 模式，也可以设 retries=0 关掉重试 ) private OrderService orderService; 2.2 Failover 原理与幂等陷阱 Failover 是默认策略——它的逻辑是： ...

SpringBoot Dubbo 📖 前置阅读：本文假设读者已理解 Dubbo 的核心概念（Registry、Provider、Consumer、RPC 调用链路）。如果还不熟悉，建议先阅读 Dubbo 核心架构与 RPC 模型。 🎯 第一步：目标说明 上一篇用原生 Dubbo + Spring XML 写了 <dubbo:service>、<dubbo:reference>、<dubbo:registry>。SpringBoot 时代不需要那些 XML——dubbo-spring-boot-starter 用两个注解 + 一套 yml 配置替代全部 XML。 读完这篇会掌握： dubbo-spring-boot-starter 环境搭建——依赖 + yml 配置 @DubboService——暴露服务，替代 <dubbo:service> @DubboReference——引用远程服务，替代 <dubbo:reference> dubbo 协议 vs triple 协议——什么时候用哪个 Hessian2 / Fastjson2 序列化配置 Nacos 注册中心的 SpringBoot 集成 📋 第二步：前置条件 前置项 具体要求 验证命令 JDK 17+（8+ 也兼容） java -version SpringBoot 3.x（文中用 3.2） mvn dependency:tree | grep spring-boot Nacos 2.3.0（单机即可） docker ps | grep nacos 前置知识 Registry/Provider/Consumer 概念 — 确认 Nacos 在跑： ...

Dubbo 核心架构 📖 前置阅读：本文假设读者理解基本的网络通信概念（TCP/IP、HTTP、序列化）。不需要预先了解 RPC——本文从零讲起。 一、⚡ 问题切入：HTTP REST 调用有什么"不够用"的？ 互联网公司典型的微服务架构中，服务间通信最常见的方式是 HTTP REST： 订单服务 (OrderService) → 商品服务 (ProductService) GET /api/products/10001 → 返回 JSON {"id": 10001, "name": "iPhone", "stock": 50} POST /api/orders → 返回 JSON {"orderId": 20001, "status": "created"} 这套方案在服务数量少、调用量低时完全够用。但当公司扩张到几十个微服务、每秒上万次调用时，REST 的短板就暴露了： 痛点 REST 的具体表现 连接开销 每次请求都需要建 TCP 连接（HTTP/1.1 支持复用但仍是短连接语义）——高并发时 CPU 和内存吃紧 序列化冗余 JSON 文本格式——字段名重复传输，体量大、解析慢。对比二进制序列化，JSON 的带宽占用高出 3~10 倍 弱类型契约 没有强类型接口定义——调用方靠"文档"或"口头约定"知道参数和返回值类型。商品服务改了字段名，订单服务的代码编译通过、运行时崩 路由单一 URL 路由——无法按业务特性做灰度发布、权重分配、同机房优先路由 缺乏治理 没有内置的负载均衡、熔断、限流——需要额外引入 Spring Cloud、Sentinel 等组件 这时候再看 Dubbo 的设计思路——不是把 HTTP 做得更好，而是用另一套协议和模型来替代 HTTP： ...