从零上手Dubbo：微服务RPC通信与服务治理实战笔记

我第一次把项目从单体应用拆成微服务的时候心里其实很没底。拆之前一切正常拆完之后反而乱了服务A要调服务B服务地址散落在各个配置文件里某个服务实例挂了一台机器这边完全感知不到接口升级了调用方不知道上线前联调经常鸡飞狗跳。那段时间我几乎每天都在折腾服务之间怎么稳定地互相通信。后来团队引入Dubbo整个服务调用的局面才彻底变简单。这是个在国内互联网公司用了十几年的微服务框架主打高性能RPC通信和服务治理。服务注册发现、负载均衡、容错重试、灰度分组这些以前靠人肉维护的东西配置一下就自动接管了。这篇文章是我从零上手Dubbo到写进生产环境的完整笔记不绕弯子适合刚接触微服务、准备把单体拆成多个服务的后端开发也适合想快速搞懂Dubbo核心机制的读者。很多人对Dubbo的认知停留在一个RPC框架这个层面但真正落地时你会发现Dubbo的价值更多体现在它整套服务治理机制上。下面我从为什么需要它开始讲起一路带你把Provider、Consumer、注册中心跑通再补上生产环境必配的负载均衡、容错、安全校验这些硬知识点。1. 为什么服务一拆就乱Dubbo要解决的通信痛点1.1 从一个真实的架构演进场景说起单体应用里订单模块要查询用户信息直接方法调用就完了一个进程内解决。但拆成订单服务和用户服务后这两个模块分布在不同的进程、甚至不同的机器上互相之间怎么调用最原始的做法是在订单服务里写一个HTTP客户端通过IP端口去请求用户服务暴露的HTTP接口。这套玩法在小规模下勉强能跑但服务一多问题立刻冒出来。第一个是服务地址管理问题配置文件里写死IP机器扩容缩容都要改配置再发布第二个是服务状态感知问题某台机器挂了调用方完全不知情请求还是往那里打故障被放大第三个是高性能问题HTTP协议一次次三次握手、一次请求大量的报文头在调用量大的场景下开销非常可观。微服务架构如果只是把单体拆小而不解决服务之间的通信和治理问题拆得越多系统越脆弱。Dubbo本质上就是为了这个场景设计的它让远程调用看起来像本地方法调用同时把服务地址管理、健康检查、自动故障转移这些事全部接管过去让开发者只关心业务逻辑不用每次手动处理服务间通信的琐碎细节。1.2 注册中心就是服务界的通讯录Dubbo架构里最核心的四个角色是Provider服务提供者、Consumer服务消费者、Registry注册中心、Monitor监控中心。可以把注册中心理解为服务界的一本动态通讯录。Provider启动时会把自己的服务名、IP、端口、协议这些信息登记到注册中心相当于我上线了地址是xx大家快来调用我。Consumer启动时会向注册中心订阅自己需要的服务列表拿到当前所有可用的Provider地址。最妙的是这个通讯录是实时更新的Provider新增实例、下线实例、缩容注册中心都会立刻感知并推送给订阅的Consumer。这就解决了两个关键问题。一是地址自动发现新增服务实例不需要改调用方配置注册中心会自动下发新地址二是故障自动摘除Provider如果心跳失败被注册中心剔除Consumer会自动拿到剔除后的最新列表请求不会再发往死掉的机器。在网络里这套机制通常叫服务发现与注册。Dubbo的RPC底层通信也值得一提。默认的dubbo协议基于Netty做长连接多路复用支持多种序列化方式相比每次调用都要新建连接的HTTP短连接省去了大量连接建立和拆除的开销。这也是为什么内部服务间通信很多团队偏好Dubbo而不是直接用HTTP调用的原因。1.3 Dubbo和Spring Cloud不是二选一的关系经常有人问Dubbo和Spring Cloud到底选哪个。我的观点是它们解决的问题有大量重叠但侧重点不太一样。Spring Cloud是约定基于HTTP REST通信的微服务全家桶生态非常全面网关、配置中心、链路追踪都有配套实现和Spring Boot无缝集成。而Dubbo是更高性能的RPC方案只专注服务框架本身的注册发现、远程调用、负载均衡和容错它允许你自由搭配各种生态组件比如注册中心可以选Nacos或Zookeeper不绑定全家桶。国内很多互联网公司的内部服务调用链路用Dubbo因为它快而面向外部、需要跨语言互操作的接口往往走Spring Cloud或者网关层。Dubbo 3.x之后也引入了Triple协议基于HTTP/2能和gRPC互通云原生适应性大大增强。所以理解它们各自的适用场景比二选一更重要。2. 动手前先搞定环境版本选型和注册中心启动2.1 版本对应关系别上来就被一堆数字劝退Dubbo的版本演进对新手来说确实有点绕。目前线上主流有两代Dubbo 2.7.x和Dubbo 3.x。如果你用的是Spring Boot 2.x可以比较顺畅地用Dubbo 3.x如果你还在老项目里用XML配置方式可能碰到的还是2.7.x时代的写法。版本上最大的一个注意点是注解的变化Dubbo 2.7.7及之前暴露服务用的是Service、引入服务用的是Reference从Dubbo 2.7.8开始推荐用DubboService、DubboReference原因很简单——Service和Spring自己的Service重名容易误用。如果项目用Dubbo 3.x直接用新注解就好老的Service虽然还能用但为了不踩坑我建议全项目统一用DubboService和DubboReference。Maven依赖方面Spring Boot项目最直接的方式是引入官方starterdependency groupIdorg.apache.dubbo/groupId artifactIddubbo-spring-boot-starter/artifactId version3.2.4/version /dependency注意这个starter并不会自动带注册中心的客户端你还要根据自己选的注册中心手动补一个nacos-client或者Zookeeper相关的依赖。很多新手在这里栽跟头启动失败提示连不上注册中心就是少引了客户端包。2.2 Nacos还是Zookeeper我建议你选Nacos注册中心目前最常见的两个选择是Nacos和Zookeeper。Zookeeper是老牌分布式协调服务Dubbo早期生态里用得非常多成熟稳定但它本身是CP架构在服务发现的场景下服务注册列表变更需要经过ZAB协议广播网络分区时可能短暂不可用。另外Zookeeper的节点模型和watch机制在服务规模大的时候数据同步压力会比较大。Nacos是阿里巴巴开源的注册中心和配置中心组件具备AP特性更贴合服务注册发现这类可用性优先、短暂不一致可接受的场景而且控制台Web界面很友好服务列表一目了然操作门槛更低。Nacos 2.x还支持gRPC长连接推送服务变更通知的实时性做得很好。如果你是新项目、没什么历史包袱我建议直接上Nacos。理由也很朴素部署简单、界面直观、和Dubbo同为阿里开源配起来少踩很多坑。2.3 一条命令把注册中心跑起来本地开发时最快的方式是用Docker把Nacos跑起来docker run -d --name nacos \ -p 8848:8848 -p 9848:9848 \ -e MODEstandalone \ nacos/nacos-server:v2.2.3启动后访问http://127.0.0.1:8848/nacos默认账号密码是nacos/nacos能看到控制台就算成功了。如果你不想用Docker也可以下载Nacos压缩包直接启动。Windows下运行startup.cmd -m standaloneMac/Linux下运行sh startup.sh -m standalone注意一定带上-m standalone单机模式参数否则默认会以集群模式启动起不来。Zookeeper方式也不复杂去Apache官网下载压缩包解压后执行bin/zkServer.sh start即可默认监听2181端口。两种方式任选一种本文后面都按Nacos的地址来写。2.4 一个最容易忽略的端口问题Nacos 2.x有个非常隐蔽的坑它同时开启了两个端口8848是HTTP/gRPC数据交互端口9848是gRPC请求端口。服务注册、订阅推送如果走的是gRPC通道而你的防火墙只放行了8848就会出现一种很诡异的现象——服务在提供方日志里显示注册成功但Nacos控制台里怎么也看不到服务列表。我排查过一次一顿操作猛如虎最后发现是云安全组没开9848。所以无论是本机还是云服务器只要用了Nacos 2.x务必同时确认8848和9848两个端口都通。这个坑不写出来新手可能会被卡一整天。3. Provider端实操把一个接口变成可被远程调用的服务3.1 工程结构接口一定要单独放从一个简单的例子开始。我们做一个用户服务对外提供一个sayHello方法Consumer远程调用它。工程结构我建议至少拆成三个Maven模块demo-api纯接口模块只放接口类和DTO对象不包含任何实现和Spring依赖demo-provider服务提供方实现接口并暴露服务demo-consumer服务消费方远程调用接口为什么接口要单独放因为Consumer端要拿到接口定义才能写代理调用Provider端要实现这个接口。如果接口和实现放在同一个模块Consumer引入时会把大量无关依赖一起带进来模块之间耦合会很重。把API独立出来相当于定义了一份双方都遵守的契约这是Dubbo项目的基本常识。3.2 写接口和实现类在demo-api模块定义接口public interface GreetingService { String sayHello(String name); }在demo-provider模块实现接口并加上DubboService注解暴露服务import org.apache.dubbo.config.annotation.DubboService; DubboService public class GreetingServiceImpl implements GreetingService { Override public String sayHello(String name) { return Hello name , now is LocalDateTime.now(); } }这里DubboService就是把当前Bean注册成Dubbo服务的关键。它的作用等价于把接口和实现类绑定然后通过协议端口对外暴露并把服务元数据注册到注册中心。注意DubboService本身必须被Spring容器扫描到所以Provider启动类上还得加一个EnableDubbo注解。Provider的启动代码如下import org.apache.dubbo.config.spring.context.annotation.EnableDubbo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication EnableDubbo public class ProviderApplication { public static void main(String[] args) { SpringApplication.run(ProviderApplication.class, args); } }EnableDubbo负责扫描所有标注了DubboService和DubboReference的Bean并完成服务的注册和订阅流程。漏掉这个注解是新手最常见的第一个报错——服务类加了注解但启动起来根本没暴露。3.3 配置文件里的关键参数demo-provider的application.yml配置如下server: port: 8081 dubbo: application: name: demo-provider registry: address: nacos://127.0.0.1:8848 protocol: name: dubbo port: 20880这里几个参数的含义值得展开说。dubbo.application.name是应用名注册中心里服务归属的应用标识dubbo.registry.address指定注册中心地址前缀是Nacos还是ZookeeperDubbo会按对应协议去连接dubbo.protocol.name和dubbo.protocol.port定义服务暴露的网络协议和端口默认是dubbo协议端口默认20880。一台机器如果起了多个Provider应用要保证端口不冲突。比如第二个Provider可以把protocol.port改成20881。端口在注册中心会有记录Consumer调用时就会通过这个地址建立长连接。如果你用的是Zookeeper只需要把registry.address替换成dubbo: registry: address: zookeeper://127.0.0.1:2181其他不用动。3.4 启动注册并验证启动Provider后留意日志里有没有类似这样的输出[ZK] REGISTRY_PROVIDER_REGISTERED: zookeeper://...或者是Nacos客户端连接成功的提示。更直观的方法是去Nacos控制台在服务管理-服务列表里能看到demo-provider应用名下出现了一个服务名org.example.api.GreetingService这就是注册成功了的证据。如果日志提示Registration of service failed优先排查三件事注册中心地址是否正确、Nacos的9848端口是否连通、接口所在包是否在启动类的扫描范围内。其中扫描包的问题也很常见因为SpringBootApplication默认只扫描启动类所在包及其子包如果接口和实现类放在不同的包得用ComponentScan或调整包结构。4. Consumer端调用把远程调用用得跟本地方法一样4.1 消费端代码怎么写对接下来的Consumer端配置就简单多了。demo-consumer的application.ymlserver: port: 8082 dubbo: application: name: demo-consumer registry: address: nacos://127.0.0.1:8848然后写一个启动后自动执行的Runner用DubboReference注入远程接口import org.apache.dubbo.config.annotation.DubboReference; import org.springframework.boot.ApplicationArguments; import org.springframework.boot.ApplicationRunner; import org.springframework.stereotype.Component; Component public class GreetingRunner implements ApplicationRunner { DubboReference private GreetingService greetingService; Override public void run(ApplicationArguments args) { String result greetingService.sayHello(Dubbo); System.out.println(RPC result: result); } }这里DubboReference做的事情很奇妙它在本地生成一个代理对象你调用greetingService.sayHello(Dubbo)时代理会拿到注册中心下发的服务提供者地址选一个节点序列化参数通过网络传输给ProviderProvider执行完把结果序列化回传代理再把结果反序列化返回给调用方。整个流程对业务代码完全透明所以你会有一种我在调用本地方法的错觉。Consumer启动类同样需要EnableDubbo注解负责扫描DubboReference并执行订阅逻辑。缺少它字段注入会一直失败。运行Consumer控制台会打印出RPC result: Hello Dubbo, now is ...。到这一步一次完整的RPC调用已经跑通了。很简单对吧但简单背后是框架帮你扛住了地址寻址、网络传输、序列化、故障转移这些复杂的底层逻辑。4.2 开发期调试三板斧实际开发中Consumer和Provider常常不在同一个环境注册中心里的服务地址是内网IP本地联调就麻烦。这时候有三招非常实用。第一招直连Provider。开发期不想注册中心介入可以在DubboReference上直接指定URLDubboReference(url dubbo://127.0.0.1:20880) private GreetingService greetingService;这样Consumer会绕过注册中心直接连本地Provider。对于本地起多个服务联调非常方便但要注意上线前一定把url去掉否则发到测试环境会一直调本地。第二招关闭启动时注册中心检查。默认情况下Consumer启动时会检查订阅的Provider是否存在注册中心没数据就直接报错。开发联调时可以先启动Consumer再启动Provider这种场景下可以在配置里加一句dubbo: consumer: check: false生产环境我不建议开这个配置因为关掉check相当于掩盖了服务不可用的真实故障。第三招利用Nacos控制台上下线服务。开发联调时想模拟Provider故障可以直接在Nacos控制台找到对应服务实例点击下线然后观察Consumer端的后续调用是否自动感知。这比直接kill进程安全得多也能验证服务发现的动态性。4.3 从日志看一次RPC调用Dubbo的日志信息量挺大但新手往往忽略。调试时把日志级别调到DEBUG能清楚看到一次调用经历了什么Consumer端生成Invoker、选择负载均衡策略、发起网络请求Provider端收到请求、反序列化参数、执行业务逻辑、返回结果。用Nacos作为注册中心时还能看到服务列表变更的推送日志对理解整个调用链路很有帮助。日志里如果出现No provider available for the service意思是Consumer从注册中心拿不到可调用的服务实例。这种报错几乎都是Provider没注册上、注册了但Consumer订阅延迟或者两边的接口全限定名不一致。我建议遇到这类问题先查两件事Provider注册成功了吗Consumer和Provider引用的接口包路径一致吗5. 生产环境必须关注的负载均衡、容错和超时重试5.1 四种负载均衡策略怎么选只跑通了一个Provider的示例只能算Hello World。真实生产环境里一个服务通常会部署多台实例请求进来后谁来选节点、按什么规则选就是负载均衡要做的事。Dubbo内置了四种策略策略算法核心适用场景Random加权随机默认策略无状态服务首选请求分布均匀RoundRobin加权轮询整体更稳定适合各节点处理能力相近的场景LeastActive最少活跃数节点性能和耗时差异大时偏向把新请求分给正在处理任务最少的节点ConsistentHash一致性哈希相同参数请求路由到同一节点适合缓存穿透较敏感的场景默认情况下随机加权分布的调用量最均衡。LeastActive在集群里节点响应速度快慢差距明显时效果更好比如有些机器CPU负载高活跃数就会上去新请求就自动少往那边派。ConsistentHash则适合做有状态的会话保持比如同一个用户ID的请求尽量打在同一台机器上避免每次都要去远端重新加载数据。配置方式很简单在DubboService或DubboReference里指定DubboService(loadbalance leastactive) public class GreetingServiceImpl implements GreetingService { ... }DubboReference(loadbalance consistenthash) private GreetingService greetingService;实际项目中我建议先按默认Random跑线上看监控数据再做微调。负载均衡策略没有绝对的好坏只有合不合适的区分。5.2 五种集群容错模式对照Consumer端从注册中心拿到服务列表后调用如果失败是换个节点重试还是直接报错这个行为由集群容错策略决定。Dubbo内置了五种模式模式失败后的行为适用场景Failover自动切换到其他Provider重试默认读操作、幂等操作Failfast立即失败并抛出异常写操作、非幂等操作避免重复提交Failsafe吞掉异常只记日志非核心业务比如日志上报Failback失败后后台定时重试异步通知类通知结果不保证实时Forking并行调用多个Provider取第一个成功结果对实时性要求极高的读操作代价是消耗更多资源默认的Failover看起来友好但它依赖一个前提操作必须幂等。如果Provider执行过程中改数据库扣了款但响应回传超时Consumer以为失败发起重试就可能重复扣款。所以写操作务必把容错策略改成failfast或者把重试次数设为0。配置方式DubboReference(cluster failfast, retries 0) private OrderService orderService;5.3 超时和重试是双刃剑Dubbo的timeout默认值是1000毫秒retries默认是2表示失败后会再额外重试2次加上首次调用一共最多执行3次。很多新手没意识到的坑是如果下游接口执行时间超过1000毫秒Consumer一次次超时重试请求会像雪崩一样涌向Provider。每积累一批超时Provider线程池就多接一堆请求最终线程池被占满整个服务被打崩。超时和重试的正确配置原则我认为有三点。第一写操作类接口不管默认值多少务必retries0避免重复执行带来的业务脏数据。第二结合业务实际耗时设置timeout不要全部照着默认值走。一个需要处理大文件的接口给2000毫秒对方能完成才怪。第三Provider和Consumer的timeout都配置时Consumer端的配置优先级更高。调试时可以先用Consumer端注解配置观察确认没问题再固化到正式配置里。个人建议的入门配置模板dubbo: consumer: timeout: 3000 retries: 0这样至少能避免默认重试带来的重复执行问题。等对每个接口的耗时特征心里有数之后再逐个细化配置。6. 别让服务裸奔Token鉴权与安全防护6.1 为什么Dubbo默认不带鉴权Dubbo默认不提供用户级别的权限控制。原因也好理解它面向的是内部服务间通信设计上假设内网可信。但内网不等于安全某个服务被其他不相关的消费者绕过注册中心、直接拿着Provider的IP端口发起调用这种场景在大型系统里并不少见。比如你的商品服务只应该被订单服务调用结果某个边缘业务也摸到了地址调用链路一下子就乱了。dubbo token就是Dubbo提供的一道简单防线。它的核心作用是防止未知Consumer绕过注册中心直连Provider相当于给服务加上了一层口令校验。它不是为了替代完整的认证授权体系而是为了堵住最粗鲁的调用入口。6.2 Token机制怎么配置Provider端开启Token校验的方式很简单在DubboService上配DubboService(token true) public class GreetingServiceImpl implements GreetingService { ... }token取值为true时Dubbo启动后会生成一个随机Token并将Token登记到注册中心。Consumer从注册中心拉取服务地址时会拿到这个Token并把它作为Attachments随RPC请求一起发送给Provider。Provider收到请求后会比对Token如果不匹配就直接拒绝调用。也可以配置固定TokenDubboService(token dubbo-token-demo-2024)对应的Consumer端需要配置一致的口令DubboReference(token dubbo-token-demo-2024) private GreetingService greetingService;动态Token和固定Token的区别在于动态Token由Provider生成并分发消费者无需关注具体值固定Token需要两端约定一致校验逻辑更简单直观但要自己维护口令的一致性而且在多个环境复制时容易泄露。我在实际项目里更推荐动态Token因为可以让Dubbo自己去管理Token的生成和注册不用在代码里维护一堆口令常量。不过也要记住Token是放在RPC调用Attachment里随请求传输的如果你自定义了Filter处理请求头注意不要把它弄丢否则会出现明明两边配置正常但一直鉴权失败的怪问题。6.3 生产环境安全建议Token是入门阶段最值得掌握的安全手段但它只是第一道门。生产环境的安全加固我建议按下面几个维度逐步完善服务只在内网互通不要暴露到公网用网络策略限制Provider端口只允许内部服务访问核心业务接口在网关层做统一鉴权和账号体系对接Dubbo层只做框架级校验善用Dubbo的Filter扩展机制自定义鉴权Filter对指定group的业务做细粒度控制敏感数据通信时考虑加解密过滤器避免数据在网络上明文传输定期从Nacos控制台检查服务状态发现没见过的Consumer订阅及时排查安全没有银弹。Dubbo Token帮你挡住最基础的越权直连但完整的微服务安全体系还需要网络策略、网关、运营规范配合起来。7. 我踩过的坑和后续进阶方向7.1 五个真实的坑第一个坑是注册中心依赖缺失。第一次用Nacos做注册中心时我以为只要引入dubbo-spring-boot-starter就完事了结果Provider起半天一直报连不上Nacos。查了项目依赖才发现starter里并没有传递Nacos客户端需要手动引入nacos-client。注册中心客户端依赖这件事建议通过Maven依赖树确认一遍。第二个坑是序列化对象没实现Serializable。Dubbo默认使用Hessian2序列化报错信息往往很隐晦像SerializationException: class not found之类排查了半天才发现是返回的DTO没有实现java.io.Serializable。之后我自己写DTO都会记得继承Serializable并在接口模块统一管理这些对象。第三个坑是Provider地址为内网IP导致局域网外无法调用。本地开发时启动Provider注册到Nacos的IP是192.168.x.xConsumer也在同一台机器没问题。但换个网络环境Consumer就连不上了。这时可以用DUBBO_IP_TO_REGISTRY环境变量指定写入注册中心的IP或者用dubbo.protocol.host显式配置。生产环境通常使用服务所在宿主机的内网IP还涉及多网卡选路的问题注意通过环境变量固定IP。第四个坑是生产机器上同时存在多个Provider时默认的20880端口会冲突。最好每个应用都显式配置不同的protocol.port比如20880、20881、20882。第五个坑是Provider端接口包路径和Consumer端不完全一致。某次升级重构时我把一个接口从com.company.user.api挪到了com.company.user.facadeConsumer那边漏改引用启动直接报No provider。Dubbo精确匹配是服务接口的全限定名改包名相当于换了服务名两边必须同步。7.2 入门之后该往哪儿走跑通了Provider和Consumer掌握了负载均衡、容错、Token这些配置之后你其实已经具备了日常开发Dubbo服务的基本能力。如果还想往深处走我建议按这几个方向继续深入。第一个是SPI扩展机制。Dubbo几乎所有的核心组件都支持SPI扩展负载均衡策略、序列化方式、过滤器都能自己扩展。理解了SPI你就能看懂Dubbo源码里大量扩展点的加载逻辑这是从使用框架走向理解框架的关键一步。第二个是Dubbo 3.x的新特性。比如应用级服务发现注册中心的压力大幅降低Triple协议基于HTTP/2可以和gRPC互调对云原生场景友好得多。身边不少团队在逐步从dubbo协议向Triple迁移主要就是考虑网关互通和长期演进。第三个是Dubbo Admin控制台。本地可以启动一个Dubbo Admin查看服务列表、消费关系、路由规则还能动态调整负载均衡策略和超时配置。对于日常排查线上问题界面化操作比翻日志高效得多。根据我个人的实际体会入门Dubbo最忌讳的就是只跟着文档敲一遍Demo就跑而不理解注册发现和RPC调用的整个链路。建议你在本地把Provider和Consumer都跑起来用Nacos控制台反复上下线服务观察Consumer端的调用变化再尝试自定义一个简单的Filter去打印调用耗时。把这几个动作做下来你对Dubbo的理解会比单纯跑通Hello World扎实得多。希望这篇笔记能帮正在入门Dubbo的朋友少走几步弯路。后面有机会我再单独写写Dubbo 3.x的应用级服务发现迁移和SPI扩展的实战细节。