面试官问用过 Dubbo 没，我说就是调远程接口用的。他追问那和直接写 HTTP 有什么不一样，我卡住了。回来补了一下才理清楚。

一句话：它是服务间通信的框架

早期单体拆成多个服务后，A 服务要调 B 的方法。用 HTTP 加 JSON 也能调，但不够「像本地方法」。Dubbo 把这些远程调用包装成接口的样子，本地写一个接口注入进来直接用，底层帮你做了网络传输、序列化和负载均衡。

它解决的几件事

  • 服务注册发现：服务上线把地址注册到注册中心，比如 ZooKeeper 或 Nacos，调用方动态拿到可用列表。
  • 负载均衡：同一个服务多实例，随机、轮询、一致性哈希策略可选。
  • 容错：失败重试、快速失败、熔断降级都能配。
  • 服务治理：超时、限流、路由规则统一在配置里管。

现在还用吗

Dubbo 经历过停更又重启，现在是 Apache 顶级项目，Dubbo 3 支持应用级发现，和云原生结合更紧。国内不少公司仍在大规模使用，尤其是电商和金融这类对性能敏感、内部服务多的场景。

和 Spring Cloud 比

Spring Cloud 是一整套解决方案，HTTP 加 REST 风格，生态全但偏重。Dubbo 更聚焦 RPC 通信这一块，性能通常更好，组件也少。选哪个看团队和既有技术栈，两者也能混用。现在的趋势是往 Service Mesh 走，把这层通信能力下沉到 sidecar，业务代码更干净。

说到底，Dubbo 只是把服务调用这件事做得更顺手。服务怎么拆、边界怎么划，才是更难的活，框架帮不上太多忙。