搞Java后端的人迟早要面对这么一个问题服务一多地址靠配置文件根本管不过来。我在某公司参与一个电商类系统X的服务化改造时第一套真正落地跑起来的组合就是Dubbo加Zookeeper。这篇文章就是当时那套入门笔记的整理版适合还没接触过分布式服务框架、想快速把Dubbo和Zookeeper跑通的人。写之前先把话说清楚这篇文章不聊太多空泛的分布式理论只把三件事讲透——Zookeeper在Dubbo体系里到底扮演什么角色、环境怎么搭、一个Provider和一个Consumer怎么在本机跑通。跑通之后你再回头去看那堆概念会轻松很多。后面我还会把我实际踩过的坑一并写出来这些是文档里一般不写的。1. 先从场景说起为什么需要Dubbo和Zookeeper1.1 从一个单体应用的服务化改造说起假设你有一个电商类的单体系统用户管理和订单管理都打包在同一个应用里。订单模块要查用户信息直接本地调用一个类方法就行不需要纠结网络、协议、地址。但业务大了以后系统必然面临拆分用户模块单独部署成一个服务订单模块也单独部署成一个服务。这个时候订单服务要调用用户服务就变成了跨进程、跨网络的远程调用。最原始的办法是对方给你一个HTTP接口地址你在配置文件里写死这个IP端口然后调用。问题马上就来了。某公司这个系统X当时有将近二十个服务每个服务的IP地址散落在各个调用方的配置文件里。每次发版换IP运维要通知所有相关方改配置漏改一个就线上故障。服务多了以后调用方的配置里维护着一长串URL谁也不敢随便动。更麻烦的是如果某个服务有两台机器做负载均衡调用方得自己在配置里配一组地址还要自己写轮询逻辑。这套模式在服务数量少的时候勉强能用服务一多配置管理、故障转移、负载均衡全乱套。当时我们急需一个东西能让服务启动时自动把地址报上去其他服务需要的时候自动拿到可用列表服务挂了能自动感知并剔除。这个需求专业点说就是服务注册与发现。1.2 Dubbo和Zookeeper在体系里的分工很多人第一次听到Dubbo和Zookeeper会以为它们是一个东西。实际上是两个定位完全不同的组件配合起来才形成一套完整方案。Dubbo是一个高性能的Java RPC框架负责解决服务之间“怎么调用”的问题。它封装了网络通信、序列化、负载均衡、集群容错、超时控制这些细节。你只需要定义一个接口然后像调用本地方法一样调用远程服务剩下的Dubbo替你处理。早期由国内电商公司孵化并开源后来捐献给Apache基金会现在是一个成熟的Apache顶级项目。Zookeeper则是一个分布式协调服务负责解决服务之间“怎么找到对方”的问题。在Dubbo这套体系里它充当注册中心的角色Provider启动时把服务地址注册到ZookeeperConsumer启动时从Zookeeper拉取服务地址并且订阅变化。它就像一个大通讯录谁上线了就把名字加进去谁下线了就划掉所有调用方都看这份通讯录。两个组件解决的问题不一样但合在一起才是一个完整的服务体系。我刚接触的时候也犯过迷糊总是把“Dubbo加Zookeeper”当成一个整体来理解结果遇到问题不知道怎么定位。实际上绝大多数入门报错要么是Zookeeper没起来或者地址不对要么是Dubbo的Provider或者Consumer配置有问题把责任边界分清楚以后排查效率会高很多。2. Zookeeper注册中心的核心机制2.1 数据模型、临时节点和Watcher机制Zookeeper本质上是一个分布式的文件系统它用一棵树来管理数据树上的每个节点叫作znode。znode可以存数据也可以挂子节点。比如/dubbo下面挂着服务名服务名下面再挂providers、consumers这些目录。znode有几种类型最需要记住的是持久节点和临时节点。持久节点创建后一直存在除非主动删除。临时节点就不一样它跟创建它的会话绑定如果客户端和Zookeeper之间的会话断开临时节点会被自动删除。这个特性太适合做服务注册了——Provider一上线就创建临时节点表示自己还活着Provider挂了或者网络断了Zookeeper会自动把这个节点删掉表示这个地址不可用了。配合临时节点还有一个Watcher监听机制。客户端可以监听某个znode的变化比如监听providers目录下的子节点列表。一旦目录里新增或删除了子节点Zookeeper会主动通知所有监听的客户端。这样Consumer就能实时感知Provider列表的变化不用一遍遍去轮询查询效率高很多。把这三样东西拼起来就是一个可用的服务注册中心。当时我把这个概念反复咀嚼了很久最后用一句话总结临时节点负责自动上报和自动剔除Watcher负责广播变化持久节点负责保存稳定的目录结构。理解这三点Zookeeper在Dubbo里干的事就清楚了。2.2 一次RPC调用的完整链路写代码之前先在脑子里把一次调用的全过程走一遍。这个流程理解了后面配置错了你都能自己推断出问题在哪。Provider启动时连接Zookeeper在/dubbo/com.example.dubbodemo.api.UserService/providers下创建临时节点节点数据里写的是自己暴露的地址和协议信息。Consumer启动时连接同一个Zookeeper在同样的服务目录下订阅拿到当前所有可用的Provider地址列表并且监听后续变化。调用发生时Consumer不再经过Zookeeper而是直接根据本地缓存的地址列表选一个Provider发起真正的RPC网络请求。这里一定要建立一个概念Zookeeper只在服务注册和变更通知这两个时间点参与工作业务数据是不经过它的。它就像一个信号灯系统告诉你有哪些车可以坐但真正载客的是Dubbo本身。如果某个Provider挂了Zookeeper的临时节点超时被删除Watcher机制触发Consumer收到通知后把本地缓存列表里这个地址去掉后续调用自动转向其他健康的Provider。整个过程不用人工改任何配置。这套机制的价值在于地址的管理从静态配置变成了动态发现。我在实际项目里体会很深以前上线新服务实例要通知所有调用方改配置有了注册中心之后新实例一启动所有Consumer立刻就在列表里看到它流量自动分过去这就是服务发现带来的核心收益。说到这我想起一个很多人容易想歪的点Zookeeper的一致性模型是CP模型也就是偏重一致性在分区时可能短暂不可用。有些文章会讲Zookeeper不适合做注册中心因为服务发现对一致性要求没那么高而网络分区时宁可要可用性。这个观点有它的道理Nacos、Consul等也在提供注册中心方案。但对绝大多数中小团队来说Zookeeper足够用而且Dubbo和它的整合非常成熟入门和学习成本都低。先把这套跑通再谈架构演进比一开始就纠结分布式理论的选型问题实际得多。3. 环境准备Zookeeper安装与Dubbo依赖引入3.1 5分钟搞定Zookeeper单机安装下载、配置、启动先准备Zookeeper。我用的版本是3.7.1这个版本在稳定性上和Dubbo 2.7.x配合没问题。如果你手头上有3.4或者3.5的老版本也能跑通但建议新环境直接上3.6以上。下载还是去Apache官网找官方压缩包这里不多说。解压之后进入目录看一眼结构最关键的是conf和bin两个目录。conf是配置目录bin是启动脚本目录。Zookeeper启动前需要先准备配置文件。它默认读conf/zoo.cfg但官方压缩包里只有zoo_sample.cfg这个示例文件直接复制一份过去就行cd /opt wget https://downloads.apache.org/zookeeper/zookeeper-3.7.1/apache-zookeeper-3.7.1-bin.tar.gz tar -zxvf apache-zookeeper-3.7.1-bin.tar.gz cd apache-zookeeper-3.7.1 cp conf/zoo_sample.cfg conf/zoo.cfgzoo.cfg里最核心的配置是dataDir它指定数据文件和事务日志的存储目录。默认值是/tmp/zookeeper这个默认值在开发环境能跑但重启机器数据就没了建议改成自己的目录dataDir/opt/zookeeper-data改完之后启动进入bin目录执行脚本cd /opt/apache-zookeeper-3.7.1/bin ./zkServer.sh start ./zkServer.sh statuszkServer.sh status如果输出Mode: standalone说明单机模式启动成功。再用客户端连上去验证一下./zkCli.sh -server 127.0.0.1:2181进入客户端命令行后执行ls /能看到一个空的根节点列表这就说明Zookeeper已经在正常工作了。后面Dubbo的Provider注册成功后你再来看这个目录就能看到dubbo节点那种直观感是看日志比不了的。有一点值得注意Zookeeper默认监听2181端口启动失败最常见的原因就是忘了写zoo.cfg或者dataDir指向了一个不存在的路径。日志在zookeeper.out文件里排查问题优先看这个文件。3.2 Dubbo依赖引入与版本匹配Zookeeper起来了下一步搭建一个Spring Boot工程引入Dubbo依赖。这里版本匹配是整个入门过程中最容易翻车的地方我专门说几个经验。我推荐的入门组合JDK 8 Spring Boot 2.7.x Dubbo 2.7.15 Zookeeper 3.7.1。这个组合在大量项目里验证过文档齐全出问题能搜到答案。Maven工程里需要引入两个关键依赖。第一个是Dubbo的Spring Boot Starterdependency groupIdorg.apache.dubbo/groupId artifactIddubbo-spring-boot-starter/artifactId version2.7.15/version /dependency第二个是Zookeeper客户端相关依赖。Dubbo自己不直接连Zookeeper它通过Curator这个客户端框架来操作Zookeeper。官方为了方便提供了一个dubbo-dependencies-zookeeper依赖类型是pom会把Curator和Zookeeper客户端相关依赖一起带进来dependency groupIdorg.apache.dubbo/groupId artifactIddubbo-dependencies-zookeeper/artifactId version2.7.15/version typepom/type /dependency这里有一个很多人踩过的坑dubbo-dependencies-zookeeper传递依赖的Zookeeper客户端版本比较老。如果你的Zookeeper服务端是3.7老客户端理论上是兼容的但为了稳妥建议显式排除掉老版本换成新版本同时把Curator也对应升级dependency groupIdorg.apache.dubbo/groupId artifactIddubbo-dependencies-zookeeper/artifactId version2.7.15/version typepom/type exclusions exclusion groupIdorg.apache.zookeeper/groupId artifactIdzookeeper/artifactId /exclusion /exclusions /dependency dependency groupIdorg.apache.zookeeper/groupId artifactIdzookeeper/artifactId version3.7.1/version /dependency如果懒得折腾直接不排除、就用传递依赖的默认版本大多数情况下也能跑通。但如果你遇到Zookeeper连接方面的诡异问题优先往客户端版本兼容方向查。顺便说一句如果你用的是Dubbo 3.x注解名称会有变化文章后面我会在Demo代码里再提醒一次。版本这个东西适合的才是最好的不建议上来就追新。3.3 工程结构设计为什么要把接口抽成单独模块依赖搞定了但先别急着写业务代码。救命的一个设计细节是Dubbo的Provider和Consumer必须依赖同一个接口定义才能在网络通信时识别对方。如果两边各写一个同名接口包名不一致或者序列化字段对不上就会出现注册成功但调用失败的问题。所以标准做法是建一个Maven多模块工程把接口单独抽成一个模块。我用三个模块搭建Demodubbo-demo-api只放接口定义和传输实体不依赖任何Spring和Dubbo的东西保持干净dubbo-demo-provider实现接口启动后注册到Zookeeperdubbo-demo-consumer靠Dubbo引用远程服务启动后订阅服务对外提供HTTP入口接口模块干净这一点很多人不重视。我曾经见过把Spring的注解依赖混进API模块的情况结果Consumer引入API模块时连带引了一堆不必要的依赖启动变慢还容易冲突。正确姿势是API模块里除了接口和DTO什么都不放传输实体也要实现Serializable接口因为要跨网络序列化传输。4. 手写一个入门DemoProvider和Consumer跑起来4.1 定义API模块的接口先写API模块定义用户服务接口。我这里拿电商系统里最典型的“订单查用户”场景举例package com.example.dubbodemo.api; public interface UserService { String getUserName(Long userId); }这里有个细节Dubbo的接口方法参数和返回值在Provider和Consumer之间要完全一致包括全限定类名。如果Consumer引用的包名和Provider实现时接口的包名不一致Consumer会报找不到服务或者类型转换异常。这也是为什么强调要把API抽成单独模块两边直接引用同一个模块就不存在这种问题。如果传输的数据比较复杂比如要传一个用户对象记得定义一个DTO放在API模块里实现Serializable接口。Dubbo默认的序列化协议是Hessian字段名和类型对不上就会出现反序列化问题这些在入门阶段可以先记住后面踩到坑再深挖。4.2 Provider端暴露服务并注册到ZookeeperProvider模块要做的三件事实现接口、暴露服务、配置注册中心。先写实现类。这里有一个经典大坑给新手提个醒Dubbo暴露服务的注解是org.apache.dubbo.config.annotation.Service非常容易跟Spring的org.springframework.stereotype.Service混淆。两个注解长得一模一样功能完全不一样一个把服务暴露到注册中心一个只是声明一个Spring Bean。如果你用错了服务能启动但Zookeeper里永远没有你的服务。下面的代码注意看import那一行package com.example.dubbodemo.provider.service; import com.example.dubbodemo.api.UserService; import org.apache.dubbo.config.annotation.Service; import org.springframework.beans.factory.annotation.Value; Service public class UserServiceImpl implements UserService { Value(${dubbo.application.name}) private String appName; Override public String getUserName(Long userId) { return user- userId -from- appName; } }这个实现类很简单调用时返回一段带来源的字符串方便我们验证调用是否真的走了远程。Service注解表明这个实现类要作为Dubbo服务对外暴露。然后是Provider的启动类需要在Spring Boot的SpringBootApplication基础上加一个EnableDubbo注解让Dubbo去扫描并处理服务暴露逻辑package com.example.dubbodemo.provider; import org.apache.dubbo.config.spring.context.annotation.EnableDubbo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; EnableDubbo SpringBootApplication public class ProviderApplication { public static void main(String[] args) { SpringApplication.run(ProviderApplication.class, args); } }再配一下application.propertiesserver.port8081 dubbo.application.namedemo-provider dubbo.registry.addresszookeeper://127.0.0.1:2181 dubbo.protocol.namedubbo dubbo.protocol.port20880 dubbo.scan.base-packagescom.example.dubbodemo.provider逐条解释一下。server.port8081是Provider自己内嵌Tomcat的端口如果不需要提供HTTP接口这个端口其实可以不开但加了方便后面调试。dubbo.application.name是服务在注册中心里的应用名日志和监控里会用到。dubbo.registry.address是注册中心地址这里指向本机的Zookeeper。dubbo.protocol.name和dubbo.protocol.port表示Dubbo这个RPC协议暴露在20880端口Consumer会通过这个端口连过来。dubbo.scan.base-packages是让Dubbo扫描哪个包下的Service注解来暴露服务要和实现类所在包对应。启动Provider观察日志看到这样的输出说明注册成功了Registered dubbo service com.example.dubbodemo.api.UserService url: dubbo://192.168.x.x:20880/com.example.dubbodemo.api.UserService这个时候去Zookeeper客户端执行ls /dubbo/com.example.dubbodemo.api.UserService/providers能看到一条以dubbo://开头的节点说明服务地址已经真实写到注册中心了。4.3 Consumer端订阅服务并进行远程调用Consumer模块做的事情正好反过来启动时从Zookeeper订阅服务地址然后像调用本地方法一样调用远程接口。写一个Controller对外暴露一个HTTP接口方便通过浏览器验证package com.example.dubbodemo.consumer.controller; import com.example.dubbodemo.api.UserService; import org.apache.dubbo.config.annotation.Reference; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController public class UserController { Reference private UserService userService; GetMapping(/user) public String getUser(RequestParam Long userId) { return userService.getUserName(userId); } }注意这里的Reference是Dubbo的注解作用是将远程服务的代理注入到这个字段里。它和Spring的Autowired不一样Autowired注入的是本地的BeanReference注入的是远程服务的代理看起来一样背后走的完全是两条路。Consumer的启动类和配置如下package com.example.dubbodemo.consumer; import org.apache.dubbo.config.spring.context.annotation.EnableDubbo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; EnableDubbo SpringBootApplication public class ConsumerApplication { public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } }server.port8082 dubbo.application.namedemo-consumer dubbo.registry.addresszookeeper://127.0.0.1:2181 dubbo.scan.base-packagescom.example.dubbodemo.consumerConsumer端不需要配置dubbo.protocol.name和dubbo.protocol.port因为它不对外提供RPC服务只需要连接注册中心和发起调用。启动顺序有讲究先启动Zookeeper再启动Provider最后启动Consumer。因为Consumer启动时会去注册中心拉服务列表如果Provider还没注册Consumer拿到的是空列表调用时会报No provider available。Consumer启动日志里如果出现订阅成功的记录说明它已经在监听服务变化Subscribe: consumer://192.168.x.x/com.example.dubbodemo.api.UserService然后浏览器访问http://localhost:8082/user?userId1001如果返回user-1001-from-demo-provider恭喜你的第一个Dubbo加Zookeeper调用算是完整跑通了。看到这个结果再回头看文章开头说的服务注册与发现那种感觉会完全不一样。5. 常见问题与排查技巧实录5.1 启动连接阶段的高频故障入门阶段踩过的坑我整理了一张速查表基本覆盖了大部分新人会遇到的问题现象大概率原因排查和解决Zookeeper启动失败/启动后立刻退出没有配置zoo.cfg或dataDir目录不存在复制zoo_sample.cfg为zoo.cfg确保dataDir目录存在Provider/Consumer连接超时报Connection refusedZookeeper没启动或者地址/端口写错./zkServer.sh status查看状态telnet 127.0.0.1 2181测端口日志一直出现重连警告重试Zookeeper客户端版本和服务器不兼容按3.2的方式更新客户端依赖Provider启动成功但Zookeeper里没有服务节点Service引入成了Spring的注解检查import路径是否是org.apache.dubbo.config.annotation.ServiceConsumer报No provider available服务没注册、接口包名不一致、group/version不一致用zkCli查看/dubbo节点对比接口全限定名调用时报Not found exported service协议名或端口配置不一致检查Provider的dubbo.protocol.name和端口确保Consumer能连上20880第2条我想多说一句。Zookeeper启动后看起来没报错但服务就是连不上这种情况我见过很多次。优先检查防火墙本地开发时尤其要注意操作系统是否放行了2181端口。我自己就曾经在一台云服务器上排查了半天最后发现是安全组策略没放开这个细节比代码配置更容易让人抓狂。还有一种查看注册情况的快捷方式直接连上Zookeeper客户端查看节点树./zkCli.sh -server 127.0.0.1:2181 ls /dubbo ls /dubbo/com.example.dubbodemo.api.UserService/providers如果providers目录下有dubbo://开头的临时节点说明Provider注册成功如果目录为空说明Provider没有把服务写进来。这一步能快速定位“服务没注册”和“服务注册了但Consumer连不上”两类不同的问题。5.2 调用失败与配置不一致还有一个很隐蔽的问题就是group和version配置不一致。Dubbo允许同一个接口在不同的分组或者版本下共存比如同一个UserService测试环境用groupdev生产环境用groupprod两边各注册各的。如果Provider配了groupConsumer没配或者配的值不一样Consumer就会在注册中心里找不到对应的服务表现也是No provider available。遇到这种情况检查两边的配置就好// Provider端暴露服务 Service(group demo, version 1.0.0) public class UserServiceImpl implements UserService { ... } // Consumer端引用服务 Reference(group demo, version 1.0.0) private UserService userService;版本不一致还会带来另一个非常烦人的问题两边引用的API模块不是同一个构建版本。比如Provider改过接口重新打包发布了Consumer还是用的旧包运行时就会出现NoSuchMethodError或者序列化异常。解决办法只有一个确保两边引用同一个版本的API模块最好用Maven统一管理版本号。再提醒一个和序列化相关的点。Dubbo默认的序列化方式在不同配置下可能不一样如果你的DTO里有复杂的对象图或者循环引用就很考验序列化框架的能力。处理办法是尽量保持DTO简单、字段类型明确不要塞一些奇怪的三方库对象进去。最后分享一个很实用的排查技巧直连Provider。有时候Consumer连不上服务你想判断问题到底出在注册中心还是出在Provider本身可以绕过注册中心直接用URL直连这样能快速缩小范围Reference(url dubbo://127.0.0.1:20880) private UserService userService;这个配置的意思是Consumer不通过Zookeeper找地址直接连指定的Dubbo服务端口。如果直连能通、通过注册中心不能通说明问题在注册中心那一环如果直连都不通问题就在Provider的暴露配置或者网络链路上。生产环境排查问题时这个技巧非常管用。6. 进阶配置与生产环境的一点建议6.1 几个值得提前掌握的配置参数跑通Demo之后有几个Dubbo的核心配置我建议早点了解它们在实际项目中会频繁用到。第一个是timeout控制一次调用的超时时间默认是1000毫秒。这个值经常被调大但调大之后要注意超时时间不代表远程调用一定执行完Consumer等到超时就会失败所以很多场景下还要配合重试机制理解。第二个是retries默认重试2次。这里有个坑如果写的是非幂等操作比如下单、扣库存重试会导致业务重复执行。所以这类操作建议把retries设为0让失败快速向上抛由业务层面去决定是否重试。这个教训很深刻我们曾经因为一条扣款接口默认重试线上产生了重复扣款排查了半天。第三个是loadbalance也就是负载均衡策略。Dubbo默认是加权随机还支持轮询、最少活跃调用、一致性哈希。如果Provider机器性能不一样可以给性能好的机器设置更大的权重让流量分配更合理。第四个是集群容错模式cluster默认是failover也就是失败了自动切换其他Provider再试一次。还有failfast快速失败、failsafe失败安全出错直接忽略等模式。选择容错模式的核心原则和重试一样先想清楚你的操作是不是幂等的再决定要不要自动切换到其他机器。Reference(timeout 3000, retries 0, loadbalance roundrobin) private UserService userService;这几个参数说难不难但都是生产环境绕不开的基本功。入门阶段不需要全掌握但心里要有数知道Dubbo不止是“调一个远程方法”这么简单。6.2 生产环境Zookeeper集群和监控开发环境一台Zookeeper完全够用但生产环境一定不要单机。Zookeeper单机一旦挂了所有依赖注册中心的Provider和Consumer都会失去地址感知能力整个分布式系统就是裸奔状态。生产上至少搭3台Zookeeper组成一个集群。集群机制会选出一个Leader节点其他节点作为Follower过半机器确认写入才算提交成功这就是它能保证数据一致性的核心逻辑。3台机器允许挂1台5台机器允许挂2台再多意义不大。集群配置不复杂在每台机器的zoo.cfg里加上集群成员列表tickTime2000 initLimit10 syncLimit5 dataDir/opt/zookeeper-data clientPort2181 server.1zk-01:2888:3888 server.2zk-02:2888:3888 server.3zk-03:2888:3888然后在dataDir目录下建一个myid文件里面写对应的数字序号。伪集群也可以用三台不同端口的实例模拟原理一样。2888是集群内部同步数据的端口3888是选举端口生产防火墙要放行这三个端口之间的通信。Dubbo侧还有一个参数值得关注dubbo.registry.timeout默认是3000毫秒这个值控制Consumer连接注册中心的超时时间。生产环境如果网络稍微波动可以适当调大一点。还有dubbo.registry.session.timeout对应Zookeeper会话超时时间如果Provider频繁被“误判下线”通常就是会话超时设置太短或者网络不稳定。监控这一块有条件的话可以部署一个管控台。启动之后能看到哪些服务注册、哪些Consumer在订阅、调用统计是多少对于排查问题非常有帮助。我自己在项目里排查一个“服务时通时不通”的问题时就是通过管控台看到某个Provider的QPS异常高才定位到是负载均衡策略配置不合理。6.3 单机开发时候的一个小技巧最后分享一个小技巧很多人在本地调试多个Provider和Consumer时会用。如果你只想跑一个Consumer调本地Provider不想每次启动都依赖Zookeeper可以用dubbo.registry.addressmulticast://或者直接直连配置。但我不推荐这样写因为绕过了注册中心和真实环境不一致容易引入“本地能跑线上不行”的问题。更稳的做法是本地也启动一个Zookeeper保持和线上一样的架构。做压力测试或者调试负载均衡的时候可以用Zookeeper的客户端脚本手动注册不存在的节点配合Watcher机制观察Consumer的反应比硬改代码方便得多。Zookeeper还有一个很有用的运维命令就是get查看节点的数据内容和状态信息get /dubbo/com.example.dubbodemo.api.UserService/providers/dubbo://127.0.0.1:20880/...节点数据里包含了协议、IP、端口、服务名、序列化方式等一串信息对照着看基本上能判断出Provider暴露的参数对不对。有时候Consumer连不上就是节点数据里显示的端口和实际监听端口不一致一查一个准。我个人在实际操作中的体会是Dubbo和Zookeeper这套组合入门门槛其实不高难的是搞清楚服务注册与发现这件事本身的边界——Zookeeper不是业务流量的通道它只是服务上下线的信号灯。把这个边界想清楚很多配置问题都能自己推导出来。如果你跑通Demo的时候卡住了大概率是版本匹配和注解导入这两个点上回头对照着文章里的表去查基本都能解决。
搞Java后端的人迟早要面对这么一个问题服务一多地址靠配置文件根本管不过来。我在某公司参与一个电商类系统X的服务化改造时第一套真正落地跑起来的组合就是Dubbo加Zookeeper。这篇文章就是当时那套入门笔记的整理版适合还没接触过分布式服务框架、想快速把Dubbo和Zookeeper跑通的人。写之前先把话说清楚这篇文章不聊太多空泛的分布式理论只把三件事讲透——Zookeeper在Dubbo体系里到底扮演什么角色、环境怎么搭、一个Provider和一个Consumer怎么在本机跑通。跑通之后你再回头去看那堆概念会轻松很多。后面我还会把我实际踩过的坑一并写出来这些是文档里一般不写的。1. 先从场景说起为什么需要Dubbo和Zookeeper1.1 从一个单体应用的服务化改造说起假设你有一个电商类的单体系统用户管理和订单管理都打包在同一个应用里。订单模块要查用户信息直接本地调用一个类方法就行不需要纠结网络、协议、地址。但业务大了以后系统必然面临拆分用户模块单独部署成一个服务订单模块也单独部署成一个服务。这个时候订单服务要调用用户服务就变成了跨进程、跨网络的远程调用。最原始的办法是对方给你一个HTTP接口地址你在配置文件里写死这个IP端口然后调用。问题马上就来了。某公司这个系统X当时有将近二十个服务每个服务的IP地址散落在各个调用方的配置文件里。每次发版换IP运维要通知所有相关方改配置漏改一个就线上故障。服务多了以后调用方的配置里维护着一长串URL谁也不敢随便动。更麻烦的是如果某个服务有两台机器做负载均衡调用方得自己在配置里配一组地址还要自己写轮询逻辑。这套模式在服务数量少的时候勉强能用服务一多配置管理、故障转移、负载均衡全乱套。当时我们急需一个东西能让服务启动时自动把地址报上去其他服务需要的时候自动拿到可用列表服务挂了能自动感知并剔除。这个需求专业点说就是服务注册与发现。1.2 Dubbo和Zookeeper在体系里的分工很多人第一次听到Dubbo和Zookeeper会以为它们是一个东西。实际上是两个定位完全不同的组件配合起来才形成一套完整方案。Dubbo是一个高性能的Java RPC框架负责解决服务之间“怎么调用”的问题。它封装了网络通信、序列化、负载均衡、集群容错、超时控制这些细节。你只需要定义一个接口然后像调用本地方法一样调用远程服务剩下的Dubbo替你处理。早期由国内电商公司孵化并开源后来捐献给Apache基金会现在是一个成熟的Apache顶级项目。Zookeeper则是一个分布式协调服务负责解决服务之间“怎么找到对方”的问题。在Dubbo这套体系里它充当注册中心的角色Provider启动时把服务地址注册到ZookeeperConsumer启动时从Zookeeper拉取服务地址并且订阅变化。它就像一个大通讯录谁上线了就把名字加进去谁下线了就划掉所有调用方都看这份通讯录。两个组件解决的问题不一样但合在一起才是一个完整的服务体系。我刚接触的时候也犯过迷糊总是把“Dubbo加Zookeeper”当成一个整体来理解结果遇到问题不知道怎么定位。实际上绝大多数入门报错要么是Zookeeper没起来或者地址不对要么是Dubbo的Provider或者Consumer配置有问题把责任边界分清楚以后排查效率会高很多。2. Zookeeper注册中心的核心机制2.1 数据模型、临时节点和Watcher机制Zookeeper本质上是一个分布式的文件系统它用一棵树来管理数据树上的每个节点叫作znode。znode可以存数据也可以挂子节点。比如/dubbo下面挂着服务名服务名下面再挂providers、consumers这些目录。znode有几种类型最需要记住的是持久节点和临时节点。持久节点创建后一直存在除非主动删除。临时节点就不一样它跟创建它的会话绑定如果客户端和Zookeeper之间的会话断开临时节点会被自动删除。这个特性太适合做服务注册了——Provider一上线就创建临时节点表示自己还活着Provider挂了或者网络断了Zookeeper会自动把这个节点删掉表示这个地址不可用了。配合临时节点还有一个Watcher监听机制。客户端可以监听某个znode的变化比如监听providers目录下的子节点列表。一旦目录里新增或删除了子节点Zookeeper会主动通知所有监听的客户端。这样Consumer就能实时感知Provider列表的变化不用一遍遍去轮询查询效率高很多。把这三样东西拼起来就是一个可用的服务注册中心。当时我把这个概念反复咀嚼了很久最后用一句话总结临时节点负责自动上报和自动剔除Watcher负责广播变化持久节点负责保存稳定的目录结构。理解这三点Zookeeper在Dubbo里干的事就清楚了。2.2 一次RPC调用的完整链路写代码之前先在脑子里把一次调用的全过程走一遍。这个流程理解了后面配置错了你都能自己推断出问题在哪。Provider启动时连接Zookeeper在/dubbo/com.example.dubbodemo.api.UserService/providers下创建临时节点节点数据里写的是自己暴露的地址和协议信息。Consumer启动时连接同一个Zookeeper在同样的服务目录下订阅拿到当前所有可用的Provider地址列表并且监听后续变化。调用发生时Consumer不再经过Zookeeper而是直接根据本地缓存的地址列表选一个Provider发起真正的RPC网络请求。这里一定要建立一个概念Zookeeper只在服务注册和变更通知这两个时间点参与工作业务数据是不经过它的。它就像一个信号灯系统告诉你有哪些车可以坐但真正载客的是Dubbo本身。如果某个Provider挂了Zookeeper的临时节点超时被删除Watcher机制触发Consumer收到通知后把本地缓存列表里这个地址去掉后续调用自动转向其他健康的Provider。整个过程不用人工改任何配置。这套机制的价值在于地址的管理从静态配置变成了动态发现。我在实际项目里体会很深以前上线新服务实例要通知所有调用方改配置有了注册中心之后新实例一启动所有Consumer立刻就在列表里看到它流量自动分过去这就是服务发现带来的核心收益。说到这我想起一个很多人容易想歪的点Zookeeper的一致性模型是CP模型也就是偏重一致性在分区时可能短暂不可用。有些文章会讲Zookeeper不适合做注册中心因为服务发现对一致性要求没那么高而网络分区时宁可要可用性。这个观点有它的道理Nacos、Consul等也在提供注册中心方案。但对绝大多数中小团队来说Zookeeper足够用而且Dubbo和它的整合非常成熟入门和学习成本都低。先把这套跑通再谈架构演进比一开始就纠结分布式理论的选型问题实际得多。3. 环境准备Zookeeper安装与Dubbo依赖引入3.1 5分钟搞定Zookeeper单机安装下载、配置、启动先准备Zookeeper。我用的版本是3.7.1这个版本在稳定性上和Dubbo 2.7.x配合没问题。如果你手头上有3.4或者3.5的老版本也能跑通但建议新环境直接上3.6以上。下载还是去Apache官网找官方压缩包这里不多说。解压之后进入目录看一眼结构最关键的是conf和bin两个目录。conf是配置目录bin是启动脚本目录。Zookeeper启动前需要先准备配置文件。它默认读conf/zoo.cfg但官方压缩包里只有zoo_sample.cfg这个示例文件直接复制一份过去就行cd /opt wget https://downloads.apache.org/zookeeper/zookeeper-3.7.1/apache-zookeeper-3.7.1-bin.tar.gz tar -zxvf apache-zookeeper-3.7.1-bin.tar.gz cd apache-zookeeper-3.7.1 cp conf/zoo_sample.cfg conf/zoo.cfgzoo.cfg里最核心的配置是dataDir它指定数据文件和事务日志的存储目录。默认值是/tmp/zookeeper这个默认值在开发环境能跑但重启机器数据就没了建议改成自己的目录dataDir/opt/zookeeper-data改完之后启动进入bin目录执行脚本cd /opt/apache-zookeeper-3.7.1/bin ./zkServer.sh start ./zkServer.sh statuszkServer.sh status如果输出Mode: standalone说明单机模式启动成功。再用客户端连上去验证一下./zkCli.sh -server 127.0.0.1:2181进入客户端命令行后执行ls /能看到一个空的根节点列表这就说明Zookeeper已经在正常工作了。后面Dubbo的Provider注册成功后你再来看这个目录就能看到dubbo节点那种直观感是看日志比不了的。有一点值得注意Zookeeper默认监听2181端口启动失败最常见的原因就是忘了写zoo.cfg或者dataDir指向了一个不存在的路径。日志在zookeeper.out文件里排查问题优先看这个文件。3.2 Dubbo依赖引入与版本匹配Zookeeper起来了下一步搭建一个Spring Boot工程引入Dubbo依赖。这里版本匹配是整个入门过程中最容易翻车的地方我专门说几个经验。我推荐的入门组合JDK 8 Spring Boot 2.7.x Dubbo 2.7.15 Zookeeper 3.7.1。这个组合在大量项目里验证过文档齐全出问题能搜到答案。Maven工程里需要引入两个关键依赖。第一个是Dubbo的Spring Boot Starterdependency groupIdorg.apache.dubbo/groupId artifactIddubbo-spring-boot-starter/artifactId version2.7.15/version /dependency第二个是Zookeeper客户端相关依赖。Dubbo自己不直接连Zookeeper它通过Curator这个客户端框架来操作Zookeeper。官方为了方便提供了一个dubbo-dependencies-zookeeper依赖类型是pom会把Curator和Zookeeper客户端相关依赖一起带进来dependency groupIdorg.apache.dubbo/groupId artifactIddubbo-dependencies-zookeeper/artifactId version2.7.15/version typepom/type /dependency这里有一个很多人踩过的坑dubbo-dependencies-zookeeper传递依赖的Zookeeper客户端版本比较老。如果你的Zookeeper服务端是3.7老客户端理论上是兼容的但为了稳妥建议显式排除掉老版本换成新版本同时把Curator也对应升级dependency groupIdorg.apache.dubbo/groupId artifactIddubbo-dependencies-zookeeper/artifactId version2.7.15/version typepom/type exclusions exclusion groupIdorg.apache.zookeeper/groupId artifactIdzookeeper/artifactId /exclusion /exclusions /dependency dependency groupIdorg.apache.zookeeper/groupId artifactIdzookeeper/artifactId version3.7.1/version /dependency如果懒得折腾直接不排除、就用传递依赖的默认版本大多数情况下也能跑通。但如果你遇到Zookeeper连接方面的诡异问题优先往客户端版本兼容方向查。顺便说一句如果你用的是Dubbo 3.x注解名称会有变化文章后面我会在Demo代码里再提醒一次。版本这个东西适合的才是最好的不建议上来就追新。3.3 工程结构设计为什么要把接口抽成单独模块依赖搞定了但先别急着写业务代码。救命的一个设计细节是Dubbo的Provider和Consumer必须依赖同一个接口定义才能在网络通信时识别对方。如果两边各写一个同名接口包名不一致或者序列化字段对不上就会出现注册成功但调用失败的问题。所以标准做法是建一个Maven多模块工程把接口单独抽成一个模块。我用三个模块搭建Demodubbo-demo-api只放接口定义和传输实体不依赖任何Spring和Dubbo的东西保持干净dubbo-demo-provider实现接口启动后注册到Zookeeperdubbo-demo-consumer靠Dubbo引用远程服务启动后订阅服务对外提供HTTP入口接口模块干净这一点很多人不重视。我曾经见过把Spring的注解依赖混进API模块的情况结果Consumer引入API模块时连带引了一堆不必要的依赖启动变慢还容易冲突。正确姿势是API模块里除了接口和DTO什么都不放传输实体也要实现Serializable接口因为要跨网络序列化传输。4. 手写一个入门DemoProvider和Consumer跑起来4.1 定义API模块的接口先写API模块定义用户服务接口。我这里拿电商系统里最典型的“订单查用户”场景举例package com.example.dubbodemo.api; public interface UserService { String getUserName(Long userId); }这里有个细节Dubbo的接口方法参数和返回值在Provider和Consumer之间要完全一致包括全限定类名。如果Consumer引用的包名和Provider实现时接口的包名不一致Consumer会报找不到服务或者类型转换异常。这也是为什么强调要把API抽成单独模块两边直接引用同一个模块就不存在这种问题。如果传输的数据比较复杂比如要传一个用户对象记得定义一个DTO放在API模块里实现Serializable接口。Dubbo默认的序列化协议是Hessian字段名和类型对不上就会出现反序列化问题这些在入门阶段可以先记住后面踩到坑再深挖。4.2 Provider端暴露服务并注册到ZookeeperProvider模块要做的三件事实现接口、暴露服务、配置注册中心。先写实现类。这里有一个经典大坑给新手提个醒Dubbo暴露服务的注解是org.apache.dubbo.config.annotation.Service非常容易跟Spring的org.springframework.stereotype.Service混淆。两个注解长得一模一样功能完全不一样一个把服务暴露到注册中心一个只是声明一个Spring Bean。如果你用错了服务能启动但Zookeeper里永远没有你的服务。下面的代码注意看import那一行package com.example.dubbodemo.provider.service; import com.example.dubbodemo.api.UserService; import org.apache.dubbo.config.annotation.Service; import org.springframework.beans.factory.annotation.Value; Service public class UserServiceImpl implements UserService { Value(${dubbo.application.name}) private String appName; Override public String getUserName(Long userId) { return user- userId -from- appName; } }这个实现类很简单调用时返回一段带来源的字符串方便我们验证调用是否真的走了远程。Service注解表明这个实现类要作为Dubbo服务对外暴露。然后是Provider的启动类需要在Spring Boot的SpringBootApplication基础上加一个EnableDubbo注解让Dubbo去扫描并处理服务暴露逻辑package com.example.dubbodemo.provider; import org.apache.dubbo.config.spring.context.annotation.EnableDubbo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; EnableDubbo SpringBootApplication public class ProviderApplication { public static void main(String[] args) { SpringApplication.run(ProviderApplication.class, args); } }再配一下application.propertiesserver.port8081 dubbo.application.namedemo-provider dubbo.registry.addresszookeeper://127.0.0.1:2181 dubbo.protocol.namedubbo dubbo.protocol.port20880 dubbo.scan.base-packagescom.example.dubbodemo.provider逐条解释一下。server.port8081是Provider自己内嵌Tomcat的端口如果不需要提供HTTP接口这个端口其实可以不开但加了方便后面调试。dubbo.application.name是服务在注册中心里的应用名日志和监控里会用到。dubbo.registry.address是注册中心地址这里指向本机的Zookeeper。dubbo.protocol.name和dubbo.protocol.port表示Dubbo这个RPC协议暴露在20880端口Consumer会通过这个端口连过来。dubbo.scan.base-packages是让Dubbo扫描哪个包下的Service注解来暴露服务要和实现类所在包对应。启动Provider观察日志看到这样的输出说明注册成功了Registered dubbo service com.example.dubbodemo.api.UserService url: dubbo://192.168.x.x:20880/com.example.dubbodemo.api.UserService这个时候去Zookeeper客户端执行ls /dubbo/com.example.dubbodemo.api.UserService/providers能看到一条以dubbo://开头的节点说明服务地址已经真实写到注册中心了。4.3 Consumer端订阅服务并进行远程调用Consumer模块做的事情正好反过来启动时从Zookeeper订阅服务地址然后像调用本地方法一样调用远程接口。写一个Controller对外暴露一个HTTP接口方便通过浏览器验证package com.example.dubbodemo.consumer.controller; import com.example.dubbodemo.api.UserService; import org.apache.dubbo.config.annotation.Reference; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController public class UserController { Reference private UserService userService; GetMapping(/user) public String getUser(RequestParam Long userId) { return userService.getUserName(userId); } }注意这里的Reference是Dubbo的注解作用是将远程服务的代理注入到这个字段里。它和Spring的Autowired不一样Autowired注入的是本地的BeanReference注入的是远程服务的代理看起来一样背后走的完全是两条路。Consumer的启动类和配置如下package com.example.dubbodemo.consumer; import org.apache.dubbo.config.spring.context.annotation.EnableDubbo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; EnableDubbo SpringBootApplication public class ConsumerApplication { public static void main(String[] args) { SpringApplication.run(ConsumerApplication.class, args); } }server.port8082 dubbo.application.namedemo-consumer dubbo.registry.addresszookeeper://127.0.0.1:2181 dubbo.scan.base-packagescom.example.dubbodemo.consumerConsumer端不需要配置dubbo.protocol.name和dubbo.protocol.port因为它不对外提供RPC服务只需要连接注册中心和发起调用。启动顺序有讲究先启动Zookeeper再启动Provider最后启动Consumer。因为Consumer启动时会去注册中心拉服务列表如果Provider还没注册Consumer拿到的是空列表调用时会报No provider available。Consumer启动日志里如果出现订阅成功的记录说明它已经在监听服务变化Subscribe: consumer://192.168.x.x/com.example.dubbodemo.api.UserService然后浏览器访问http://localhost:8082/user?userId1001如果返回user-1001-from-demo-provider恭喜你的第一个Dubbo加Zookeeper调用算是完整跑通了。看到这个结果再回头看文章开头说的服务注册与发现那种感觉会完全不一样。5. 常见问题与排查技巧实录5.1 启动连接阶段的高频故障入门阶段踩过的坑我整理了一张速查表基本覆盖了大部分新人会遇到的问题现象大概率原因排查和解决Zookeeper启动失败/启动后立刻退出没有配置zoo.cfg或dataDir目录不存在复制zoo_sample.cfg为zoo.cfg确保dataDir目录存在Provider/Consumer连接超时报Connection refusedZookeeper没启动或者地址/端口写错./zkServer.sh status查看状态telnet 127.0.0.1 2181测端口日志一直出现重连警告重试Zookeeper客户端版本和服务器不兼容按3.2的方式更新客户端依赖Provider启动成功但Zookeeper里没有服务节点Service引入成了Spring的注解检查import路径是否是org.apache.dubbo.config.annotation.ServiceConsumer报No provider available服务没注册、接口包名不一致、group/version不一致用zkCli查看/dubbo节点对比接口全限定名调用时报Not found exported service协议名或端口配置不一致检查Provider的dubbo.protocol.name和端口确保Consumer能连上20880第2条我想多说一句。Zookeeper启动后看起来没报错但服务就是连不上这种情况我见过很多次。优先检查防火墙本地开发时尤其要注意操作系统是否放行了2181端口。我自己就曾经在一台云服务器上排查了半天最后发现是安全组策略没放开这个细节比代码配置更容易让人抓狂。还有一种查看注册情况的快捷方式直接连上Zookeeper客户端查看节点树./zkCli.sh -server 127.0.0.1:2181 ls /dubbo ls /dubbo/com.example.dubbodemo.api.UserService/providers如果providers目录下有dubbo://开头的临时节点说明Provider注册成功如果目录为空说明Provider没有把服务写进来。这一步能快速定位“服务没注册”和“服务注册了但Consumer连不上”两类不同的问题。5.2 调用失败与配置不一致还有一个很隐蔽的问题就是group和version配置不一致。Dubbo允许同一个接口在不同的分组或者版本下共存比如同一个UserService测试环境用groupdev生产环境用groupprod两边各注册各的。如果Provider配了groupConsumer没配或者配的值不一样Consumer就会在注册中心里找不到对应的服务表现也是No provider available。遇到这种情况检查两边的配置就好// Provider端暴露服务 Service(group demo, version 1.0.0) public class UserServiceImpl implements UserService { ... } // Consumer端引用服务 Reference(group demo, version 1.0.0) private UserService userService;版本不一致还会带来另一个非常烦人的问题两边引用的API模块不是同一个构建版本。比如Provider改过接口重新打包发布了Consumer还是用的旧包运行时就会出现NoSuchMethodError或者序列化异常。解决办法只有一个确保两边引用同一个版本的API模块最好用Maven统一管理版本号。再提醒一个和序列化相关的点。Dubbo默认的序列化方式在不同配置下可能不一样如果你的DTO里有复杂的对象图或者循环引用就很考验序列化框架的能力。处理办法是尽量保持DTO简单、字段类型明确不要塞一些奇怪的三方库对象进去。最后分享一个很实用的排查技巧直连Provider。有时候Consumer连不上服务你想判断问题到底出在注册中心还是出在Provider本身可以绕过注册中心直接用URL直连这样能快速缩小范围Reference(url dubbo://127.0.0.1:20880) private UserService userService;这个配置的意思是Consumer不通过Zookeeper找地址直接连指定的Dubbo服务端口。如果直连能通、通过注册中心不能通说明问题在注册中心那一环如果直连都不通问题就在Provider的暴露配置或者网络链路上。生产环境排查问题时这个技巧非常管用。6. 进阶配置与生产环境的一点建议6.1 几个值得提前掌握的配置参数跑通Demo之后有几个Dubbo的核心配置我建议早点了解它们在实际项目中会频繁用到。第一个是timeout控制一次调用的超时时间默认是1000毫秒。这个值经常被调大但调大之后要注意超时时间不代表远程调用一定执行完Consumer等到超时就会失败所以很多场景下还要配合重试机制理解。第二个是retries默认重试2次。这里有个坑如果写的是非幂等操作比如下单、扣库存重试会导致业务重复执行。所以这类操作建议把retries设为0让失败快速向上抛由业务层面去决定是否重试。这个教训很深刻我们曾经因为一条扣款接口默认重试线上产生了重复扣款排查了半天。第三个是loadbalance也就是负载均衡策略。Dubbo默认是加权随机还支持轮询、最少活跃调用、一致性哈希。如果Provider机器性能不一样可以给性能好的机器设置更大的权重让流量分配更合理。第四个是集群容错模式cluster默认是failover也就是失败了自动切换其他Provider再试一次。还有failfast快速失败、failsafe失败安全出错直接忽略等模式。选择容错模式的核心原则和重试一样先想清楚你的操作是不是幂等的再决定要不要自动切换到其他机器。Reference(timeout 3000, retries 0, loadbalance roundrobin) private UserService userService;这几个参数说难不难但都是生产环境绕不开的基本功。入门阶段不需要全掌握但心里要有数知道Dubbo不止是“调一个远程方法”这么简单。6.2 生产环境Zookeeper集群和监控开发环境一台Zookeeper完全够用但生产环境一定不要单机。Zookeeper单机一旦挂了所有依赖注册中心的Provider和Consumer都会失去地址感知能力整个分布式系统就是裸奔状态。生产上至少搭3台Zookeeper组成一个集群。集群机制会选出一个Leader节点其他节点作为Follower过半机器确认写入才算提交成功这就是它能保证数据一致性的核心逻辑。3台机器允许挂1台5台机器允许挂2台再多意义不大。集群配置不复杂在每台机器的zoo.cfg里加上集群成员列表tickTime2000 initLimit10 syncLimit5 dataDir/opt/zookeeper-data clientPort2181 server.1zk-01:2888:3888 server.2zk-02:2888:3888 server.3zk-03:2888:3888然后在dataDir目录下建一个myid文件里面写对应的数字序号。伪集群也可以用三台不同端口的实例模拟原理一样。2888是集群内部同步数据的端口3888是选举端口生产防火墙要放行这三个端口之间的通信。Dubbo侧还有一个参数值得关注dubbo.registry.timeout默认是3000毫秒这个值控制Consumer连接注册中心的超时时间。生产环境如果网络稍微波动可以适当调大一点。还有dubbo.registry.session.timeout对应Zookeeper会话超时时间如果Provider频繁被“误判下线”通常就是会话超时设置太短或者网络不稳定。监控这一块有条件的话可以部署一个管控台。启动之后能看到哪些服务注册、哪些Consumer在订阅、调用统计是多少对于排查问题非常有帮助。我自己在项目里排查一个“服务时通时不通”的问题时就是通过管控台看到某个Provider的QPS异常高才定位到是负载均衡策略配置不合理。6.3 单机开发时候的一个小技巧最后分享一个小技巧很多人在本地调试多个Provider和Consumer时会用。如果你只想跑一个Consumer调本地Provider不想每次启动都依赖Zookeeper可以用dubbo.registry.addressmulticast://或者直接直连配置。但我不推荐这样写因为绕过了注册中心和真实环境不一致容易引入“本地能跑线上不行”的问题。更稳的做法是本地也启动一个Zookeeper保持和线上一样的架构。做压力测试或者调试负载均衡的时候可以用Zookeeper的客户端脚本手动注册不存在的节点配合Watcher机制观察Consumer的反应比硬改代码方便得多。Zookeeper还有一个很有用的运维命令就是get查看节点的数据内容和状态信息get /dubbo/com.example.dubbodemo.api.UserService/providers/dubbo://127.0.0.1:20880/...节点数据里包含了协议、IP、端口、服务名、序列化方式等一串信息对照着看基本上能判断出Provider暴露的参数对不对。有时候Consumer连不上就是节点数据里显示的端口和实际监听端口不一致一查一个准。我个人在实际操作中的体会是Dubbo和Zookeeper这套组合入门门槛其实不高难的是搞清楚服务注册与发现这件事本身的边界——Zookeeper不是业务流量的通道它只是服务上下线的信号灯。把这个边界想清楚很多配置问题都能自己推导出来。如果你跑通Demo的时候卡住了大概率是版本匹配和注解导入这两个点上回头对照着文章里的表去查基本都能解决。
