Dubbo

Dubbo 生产部署 📖 前置阅读：本文是 Dubbo 系列的终篇，假设读者已经掌握前五篇的全部内容（核心架构、SpringBoot 集成、集群容错与负载均衡、注册中心、Dubbo 3.x 新特性）。 一、⚡ 问题切入：单机开发的配置能上生产吗？ 前五篇的页面配置——超时 1 秒、重试 2 次、单注册中心、无限流无监控——只能用来学习。生产环境： 单点/隐患 后果 一个 Nacos 实例 Nacos 挂了 → 新 Consumer 启动不了 → 新 Provider 无法注册 没设并发限制 一个 Provider 被大量请求打爆 → 线程池满 → 所有请求排队或失败 超时设太短 Provider 还在处理，Consumer 已断开 → 重复调用 没有监控 Provider 变慢了、Success Rate 下降了——完全不知道 无优雅上下线 重启 Provider → 正在处理的请求全部失败 生产最低配：Nacos 集群（至少 3 台） + Provider 并发限制 + Consumer 合理超时 + Dubbo Admin 监控 + 优雅上下线。 ...

Dubbo 3.x 新特性 📖 前置阅读：本文假设读者已掌握 Dubbo 的基本 RPC 开发、注册中心使用（Nacos）和 dubbo 协议。如果还不熟悉，建议先阅读 Dubbo 核心架构与 RPC 模型 和 注册中心：Nacos 与 Zookeeper。 一、⚡ 问题切入：dubbo 协议有什么不够用的？ 第一篇说了 dubbo 协议的优点——TCP 长连接 + Hessian2 二进制序列化，性能极佳。但它的设计产生于 2011 年： dubbo 协议的局限 为什么是问题 私有二进制协议 浏览器和 curl 调不了——非 HTTP，无法穿透通用 HTTP 网关 Java 中心 协议体是 Java 特有的——Go/Node.js/Python 客户端需要单独实现协议栈 服务网格不友好 Istio/Envoy 基于 HTTP/1.1 和 HTTP/2 做流量治理——私有协议无法被 Sidecar 理解 接口级服务发现 注册中心存储的是接口粒度数据（org.example.OrderService:getOrderById）——微服务有几百个接口时，注册数据爆炸 Dubbo 3.x 的两大革新直接解决这些问题： Triple 协议——基于 HTTP/2 + Protobuf，解决私有协议问题 应用级服务发现——从接口粒度改为应用粒度，解决注册数据爆炸 二、Triple 协议 —— HTTP/2 能力 + RPC 性能 2.1 Triple 协议的本质 Triple 协议 = 将 gRPC 的传输协议（HTTP/2 + Protobuf）搬到 Dubbo 上，同时保留 Dubbo 的服务治理能力（注册中心、负载均衡、集群容错）。 ...

Dubbo 注册中心 📖 前置阅读：本文假设读者已掌握 Dubbo 的基本 RPC 开发和集群容错配置。如果还不熟悉，建议先阅读 SpringBoot Dubbo 全操作指南 和 集群容错与负载均衡。 一、⚡ 问题切入：Registry 到底是什么？ 前面三篇反复提到"注册中心"——Provider 向它注册，Consumer 从它订阅。但注册中心不只是一个"存地址的地方"： 注册中心的职责 具体行为 服务注册 Provider 启动时把"IP:Port + 接口名 + 元数据"写入 Registry 服务发现 Consumer 启动时从 Registry 拉取"接口名 → 地址列表"的映射 健康检查 检测 Provider 是否存活——不存活就剔除 变更推送 Provider 地址列表变化时，主动通知 Consumer 配置管理（Nacos） 动态下发配置——不需要重启应用 关键点：Registry 只在服务发现阶段起作用。Consumer 拿到 Provider 地址后——直连调用，不经过 Registry。这是和 MQ 的 Broker 最本质的区别。 二、服务注册与发现的全链路 2.1 详细流程 flowchart TD classDef startEnd fill:#701a4c,stroke:#e11d48,stroke-width:2px,color:#fce7f3,font-weight:bold; classDef process fill:#1e1e24,stroke:#6b7280,stroke-width:1.5px,color:#e5e7eb; classDef data fill:#052e16,stroke:#16a34a,stroke-width:1.5px,color:#bbf7d0,font-weight:bold; classDef highlight fill:#450a0a,stroke:#dc2626,stroke-width:1.5px,color:#fecaca,font-weight:bold; subgraph REGISTER [注册阶段] P1[Provider 启动] --> P2["向 Nacos 注册\nServiceName: order-provider\nIP: 192.168.1.10\nPort: 20880\nInterface: org.example.OrderService\nMethods: getOrderById, createOrder..."] end subgraph DISCOVER [发现阶段] C1[Consumer 启动] --> C2["向 Nacos 订阅\nInterface: org.example.OrderService"] C2 --> C3["Nacos 返回\n[192.168.1.10:20880\n 192.168.1.11:20880\n 192.168.1.12:20880]"] C3 --> C4[Consumer 存到本地缓存] C4 --> C5["选一个 Provider\n建立 TCP 长连接"] end subgraph HEARTBEAT [心跳阶段] P2 --> H1["Provider 每 5s\n向 Nacos 发心跳"] H1 --> H2{Nacos 15s\n没收到心跳?} H2 -- "是" --> H3["标记为不健康\n30s 后剔除"] H3 --> H4["推送变更通知\n给所有订阅的 Consumer"] H4 --> C6[Consumer 更新\n本地地址缓存] end class P1,C1,C5 startEnd; class P2,C2,C3,C4,C6,H1,H3,H4 process; class H2 highlight; 2.2 注册中心的存储结构 以 Nacos 为例，注册的数据长这样： ...

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 是默认策略——它的逻辑是： ...

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： ...