微服务一旦拆起来第一个躲不开的问题就是Service A 到底怎么调到 Service B在这个Java微服务系列第三篇里我专门聊聊“基于服务发现的服务调用”核心就是Feign和Dubbo这两条主流路线。先说结论现在做微服务基本都要接注册中心Nacos是国产项目里最常用的服务提供者把地址注册上去消费者拿着“服务名”就能找到对方至于找到以后是走HTTP还是走RPC那就是Feign和Dubbo的差别了。这篇文章适合刚开始做微服务拆分、正在纠结服务间调用方式选型的Java工程师我会把原理、可复制的配置、还有我踩过的坑一次说清楚读完你就知道怎么搭一条完整可用的调用链。1. 喊了这么久服务发现它到底在解决什么问题很多新手把“服务发现”当作一个玄乎的概念其实它就是微服务拆完之后的刚需。在一个稍微复杂点的业务里拆出来的服务可能有十几个每个服务还不止一台实例——上线的、扩缩容的、故障下线的随时在变。这时候如果还用单体时代“写死IP”那套根本撑不住。1.1 从写死IP到按名字找服务想想看单体应用里模块之间互相调用最直接的写法就是// 以前这么干还凑合微服务这么干就是找死 String userUrl http://192.168.1.10:8080/user/getById;单体时代模块都在一个进程里同一份配置IP和端口基本不动写死问题不大。可微服务拆开以后呢每个服务可能有多个实例你写死其中一个扩容的实例等于白扩。实例宕机、下线、重新发布IP和端口都会变写死的地址马上就失效了。没有一个统一的“负载均衡入口”请求全打在一台机器上高并发一来直接压垮。这就好比以前你找朋友玩记的是他家门牌号结果他搬了好几次家你还拿着旧地址跑当然次次扑空。服务发现要解决的就是这件事把“记门牌号”换成“查通讯录”你不需要知道朋友现在住哪只要叫他的名字通讯录会告诉你他当前的实时位置。映射到技术上“名字”就是服务名“通讯录”就是注册中心实时位置就是当前存活的实例IP和端口。1.2 服务发现背后的四步核心机制注册中心看着简单但要支撑生产环境的动态变化内部其实有一套完整机制我拆开讲服务注册服务提供者在启动时把“服务名 IP 端口 元数据”写到注册中心。比如user-service在192.168.1.10:8080启动注册中心里就多了一条实例记录。心跳续约服务提供者要定期向注册中心发心跳证明自己还活着。Nacos里临时实例默认5秒发一次心跳如果超过一定时间没收到心跳这个实例就会被标记为不健康最终被剔除。服务订阅与变更通知服务消费者启动时向注册中心订阅它关心的服务名注册中心把当前实例列表推给消费者。实例列表发生变化新增、减少、不健康注册中心会实时通知消费者消费者本地维护一份缓存。负载均衡消费者发起调用前从本地缓存的实例列表里按轮询、随机或者权重策略选出一台实例拼出目标地址发起真正的网络请求。这里有个细节值得注意消费者本地是有缓存列表的并不是每次调用都去查注册中心。这么做的好处是性能好不依赖注册中心的实时网络代价是实例变更后配置有短暂延迟。所以生产上部署新实例后有时会发现旧实例还在被调用——这不是玄学是缓存和心跳机制的正常表现。1.3 为什么现在Nacos成了主流选择服务发现这概念最早不是Nacos先做的早年Spring Cloud生态里大家用Eureka、Zookeeper但现在国内新项目基本默认Nacos原因很实际Eureka 2.0停更了老项目维护成本高没人敢在新项目里引它。Zookeeper本身是CP模型在注册这个场景下节点之间要强一致网络抖动时会出现“宁可不可用也不给你错误数据”的情况而注册中心这种场景更适合AP模型保证可用性优先容忍短暂的数据不一致。Nacos默认支持AP模式临时实例同时也支持切换CP模式持久实例还能当配置中心用注册中心和配置中心二合一少维护一套中间件。和Spring Cloud Alibaba、Dubbo的整合都是原生的国内文档和资料也多。所以下面我讲的Feign和Dubbo两种调用方式注册中心我都会用Nacos来做演示。这不是唯一答案但绝对是当前最省心的答案。2. Feign把HTTP调用写成本地接口的声明式玩法Feign是Spring Cloud生态里标准的声明式HTTP客户端。它的特点是“像调本地接口一样调远程服务”对开发者来说几乎没有学习成本。我第一次接触的时候也觉得神奇——一个接口上加几个注解Spring就自动帮你生成了实现你不用关心URL怎么拼、HTTP请求怎么发。2.1 Feign的完整调用链路拆解先看Feign从“接口定义”到“真实请求”之间发生了什么我按顺序拉一条链路你写了一个FeignClient标注的接口定义了方法、请求路径、参数。Spring在启动时对这个接口做动态代理生成一个代理实现类。调用方法时代理把方法签名翻译成一个HTTP请求请求方法GET/POST、路径、请求体、请求头。关键一步Feign把URL中的服务名交给Spring Cloud LoadBalancer新版里替代了老Ribbon由它去注册中心按服务名拉取实例列表。LoadBalancer从实例列表中按负载均衡策略选一台拼出真实的http://ip:port/请求路径。发起真正的HTTP调用拿到响应后把JSON反序列化成方法返回的类型。所以Feign管的是“请求怎么拼”LoadBalancer管的是“请求发给谁”注册中心管的是“谁还活着”。三者配合才是完整的服务发现调用。2.2 Nacos Feign 的最小可用配置说再多不如直接给一份能跑的配置。我假设你有一个user-service服务提供方和一个order-service服务调用方都注册到同一个Nacos。我先给调用方接Feign。第一步引入依赖这里注意版本配套。我以Spring Boot 2.6.x Spring Cloud 2021.x Spring Cloud Alibaba 2021.x为例dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-openfeign/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency !-- 新版没有Ribbon了必须手动引LoadBalancer不然Feign起不来 -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-loadbalancer/artifactId /dependency注意很多人只引了Nacos和OpenFeign启动时还报No Feign Client for loadBalancing defined或者服务名解析不了就是因为漏了LoadBalancer。这是Spring Cloud新版迁移后最常见的一个坑。第二步启动类上打开Feign开关SpringBootApplication EnableFeignClients public class OrderServiceApplication { public static void main(String[] args) { SpringApplication.run(OrderServiceApplication.class, args); } }第三步在order-service里定义一个调用user-service的接口FeignClient(name user-service, fallback UserClientFallback.class) public interface UserClient { GetMapping(/user/{id}) User getById(PathVariable(id) Long id); }这里有两个最容易错的地方name必须和对方在Nacos注册的服务名完全一致RequestMapping的路径必须和对方实际接口路径完全一致猜错一个就是404。服务提供方那边就正常写Spring MVC接口服务名在application.yml里配置spring: application: name: user-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848第四步在调用方业务代码里直接注入UserClient使用Service public class OrderService { private final UserClient userClient; public OrderService(UserClient userClient) { this.userClient userClient; } public User getUser(Long id) { return userClient.getById(id); } }你在这个业务方法里完全感觉不到远程请求的存在它就像调本地方法一样。但背后已经走完了“注册中心拉实例 → 负载均衡选实例 → HTTP调用”一整条链路。2.3 Feign的超时、重试与降级配置接口能跑通只是第一步生产环境必须处理超时和异常。我给一段常用的配置feign: client: config: default: connectTimeout: 5000 readTimeout: 5000 user-service: readTimeout: 10000 circuitbreaker: enabled: trueconnectTimeout建立连接的超时时间我一般给3秒到5秒。如果目标服务一连就卡住5秒足够暴露问题了。readTimeout等待响应体返回的超时这个要看业务。如果对方接口内部查库调第三方耗时本来就长你给得太短就会频繁超时这里我给的是5秒实际要按最慢的响应时间留余量。局部配置上面写了user-service单独覆盖了readTimeout为10秒这比配置全局值更方便——不是所有服务的耗时都一样逐个服务调优才是生产级做法。降级加fallback要打开feign.circuitbreaker.enabledtrue然后写一个实现UserClient的类被Spring容器接管Component public class UserClientFallback implements UserClient { Override public User getById(Long id) { return User.empty(); // 返回兜底空对象别让上游调用报错 } }重试这块我要多说一句Spring Cloud OpenFeign默认不重试。我见过有人自己配了重试一个请求下游已经执行成功但响应超时了重试又把请求打了一遍——如果接口不幂等就产生了两份订单。我的原则是默认不重试如果要重试必须是查询类幂等接口且重试次数控制在1次。Feign还有一个非常反直觉的坑GET方法传对象参数会直接报错。Feign对GET的Query参数解析有限你如果写GetMapping(/user) User getByCondition(UserCondition condition)启动不会报错调用时大概率拼不出正确参数。常规做法是用SpringQueryMap或者把参数拆开一个个传。3. Dubbo高性能RPC调用的另一种打开方式如果你的服务间调用很频繁、对性能敏感或者需要更细粒度的治理能力Dubbo是比Feign更硬核的方案。Dubbo是阿里开源的RPC框架后来捐给了Apache到现在国内大量核心业务还在用它。3.1 Dubbo为什么比HTTP调用更快Feign走的是HTTP JSONDubbo默认走的是TCP 自定义二进制协议。两者的性能差距主要来自这三个点协议层开销HTTP协议本身有大量头信息Method、Headers、Cookies等即使没有业务数据也得带上而Dubbo协议的请求头紧凑得多传输体积明显更小。连接复用Feign每次调用一般都要建立一次TCP连接除非开启了HTTP连接池但很多项目默认没配Dubbo则维护长连接和连接池消费者和提供者之间保持常驻连接省去反复建连、断连的开销。序列化Feign常用JSON序列化可读性好但体积大Dubbo默认Hessian2还有Kryo、Protobuf等更高性能的选择序列化出来的字节更小反序列化也更快。我并不是说Feign就一定慢得不能用绝大多数业务场景HTTP的几百毫秒延迟都不是瓶颈。但如果你有那种单块业务里几十万、上百万次服务间调用、对TPS有硬性要求的时候Dubbo的路由效率、连接复用、更细的线程模型优势就体现出来了。3.2 基于Nacos的Dubbo配置示例Dubbo的整合思路和Feign有个本质区别它要求把接口单独抽到一个公共Jar包里。比如我把UserService接口放到一个user-api模块提供方user-service依赖并在实现类上加DubboService调用方order-service依赖并在字段上注入DubboReference。为什么这样设计因为RPC需要“强类型”——调用方拿到的代理对象要实现同一个接口类型接口都不一致代理压根没法生成。先看公共接口模块public interface UserService { User getById(Long id); }服务提供方DubboService public class UserServiceImpl implements UserService { Override public User getById(Long id) { return new User(id, 张三); } }dubbo: application: name: user-service registry: address: nacos://127.0.0.1:8848 protocol: name: dubbo port: -1这里protocol.port: -1表示每个实例随机分配一个端口适合多实例部署在主机的情况避免端口冲突。默认dubbo协议端口是20880如果两台实例在同一台机器上不配置随机端口就会撞。服务调用方Service public class OrderService { DubboReference private UserService userService; public User getUser(Long id) { return userService.getById(id); } }dubbo: application: name: order-service registry: address: nacos://127.0.0.1:8848 consumer: timeout: 5000 retries: 0消费者这边不用配置DubboService思路非常清晰提供方“暴露服务”消费方“引用服务”中间的“谁在哪儿”全部交给Nacos。Dubbo的调用流程大致是消费者启动时从注册中心订阅接口拿到提供者的地址列表然后按负载均衡策略选出地址走长连接发起RPC请求。3.3 Dubbo的负载均衡、超时与集群容错配置Dubbo的强大之处在治理我挑几个生产上一定会用到的配置说明。负载均衡在DubboReference上可以指定负载均衡策略DubboReference(loadbalance roundrobin, timeout 3000, retries 0) private UserService userService;策略有四种我实际用下来这么选策略英文名适用场景随机random默认适合各实例性能差异不大的情况轮询roundrobin希望请求均匀分配避免热点实例压力过大最少活跃调用leastactive慢实例会被动减少流量适合性能参差不齐的环境一致性哈希consistenthash希望相同参数请求打到同一实例适合有状态服务或缓存友好场景超时配置的优先级我要特别强调下方法级配置 接口级配置 消费方全局配置 提供方配置。很多人只在消费方配了全局5秒结果某个方法实际要8秒接口直接超时失败。建议精确到方法或者接口配。重试Dubbo默认retries2意思是除了第一次请求失败后还会额外重试2次最多发起3次。这个默认值对非幂等接口非常危险比如扣库存、创建订单一旦下游执行成功但响应丢失重试就会造成重复扣减。我的一般建议是写操作必须显式配retries0读操作可以保留重试但也要保证接口幂等。集群容错默认failover失败自动切换其他实例还有failfast、failsafe、forking等。这里我提醒一点failover配合retries会让一个请求在多个实例上执行只适合读操作写操作建议failfast快速失败让上游感知后自己处理或者retries0的failover。服务分组与版本接口上可以加version比如DubboService(version 1.0.0)、DubboReference(version 1.0.0)。做灰度发布、AB测试、多版本共存时这是标配——老版本服务不上线新版本消费者仍能通过version把流量区分开这就弥补了服务拆分后经常遇到的“接口升级不敢动”的困境。4. Feign和Dubbo到底怎么选这个问题我几乎每做一个微服务项目都会被问到。与其给一个“XX更好”的结论我更愿意把决策维度摊开让团队自己看图说话。4.1 六维核心对比我从协议、性能、治理、生态、调试、门槛六个角度做了一张表对比维度FeignSpring Cloud OpenFeignDubbo通信协议HTTP/1.1REST风格天然适合对外开放接口默认Dubbo自定义TCP协议Dubbo 3也支持TripleHTTP/2序列化方式JSON为主可读性强、跨语言友好Hessian2、Kryo、Protobuf体积小、速度快网络开销每次请求携带完整HTTP头若无连接池则频繁建连长连接复用紧凑协议头高并发下优势明显性能表现中规中矩绝大多数业务足够相同硬件下吞吐量更高延迟更稳定服务治理需配合Spring Cloud Sentinal/Hystrix等配置较分散自带负载均衡、容错、降级、路由、隐式传参、泛化调用体系完整可调试性直接curl、Postman、浏览器就能测直观需要依赖telnet、QOS命令或专门的测试工具门槛高跨语言支持只要提供HTTP接口什么语言都能调多语言支持有但生态远不如Java生态成熟学习成本低写接口注解就能上手中高涉及协议、注册模型、插件体系、注册中心概念4.2 我的选型建议基于以上对比我给出几条实际经验不教条但大概率不会错对外接口、跨团队联调多、需要给第三方提供REST API优先Feign。因为HTTP接口谁都能看、谁都能测你不必指望所有对接方都懂Dubbo。内部核心链路、调用频繁、对性能和稳定性要求高优先Dubbo。尤其是那些后台异步任务、核心交易链路上服务间调用特别密集的场景Dubbo的长连接和紧凑协议能省下不少资源。团队刚转型微服务成员普遍不熟悉RPC先Feign。项目能快速跑起来比什么都重要不要一开始为了“性能优势”上一套复杂体系把自己搞崩。Spring Cloud 和 Dubbo 可以共存很多人以为选了Dubbo就不能用Feign实际上两者可以同时存在于一个项目里。对外暴露API走Feign内部服务间核心调用走Dubbo这个混合模式在大型项目里很常见。Dubbo 3出来以后原来“Dubbo不够云原生”的短板也在补Triple协议基于HTTP/2兼容gRPC跨语言能力大幅增强应用级服务发现模型也让它在Kubernetes环境更顺畅。所以我的判断是短中期内Feign各自有明确场景不存在谁取代谁。你的选择本质上是“想让团队用什么级别的抽象去管理服务间通信”。5. 常见问题与排查实战最后这部分我把自己和身边同事在Nacos Feign/Dubbo调用上踩过的坑、排查思路全部整理出来。这些东西你刷文档刷不到但生产环境一定会遇到。5.1 服务调通之前先确认的3件事所有调用失败问题都可以先自查这三项Nacos服务列表里有没有注册上登录Nacos控制台找到“服务管理”页确认服务名、IP、端口都在。如果控制台里压根没有问题在提供方别在消费方瞎调参。服务名和命名空间/分组是否匹配Feign的FeignClient(name...)、Dubbo的注册地址、Nacos的namespace三个地方必须对齐。我见过一个项目开发环境用namespace: dev消费方忘了配结果一直拿不到实例查了很久才发现是命名空间隔离了。消费方能访问到提供方的IP和端口吗注册中心显示实例是内网IP消费方在容器或跨网段环境网络不通调用一样会失败。这个用Postman或telnet直接测那个IP:端口就能定位。5.2 Feign报“Load balancer does not have available server for client: xxx”这个报错我想单独拿出来讲因为它出现的频率实在太高了。它翻译过来就是Feign知道要调xxx服务但LoadBalancer从注册中心拿不到任何可用实例。排查步骤看提供方是否注册成功Nacos控制台确认。看消费方是否引了spring-cloud-starter-loadbalancer新版Spring Cloud必引。看两者是否在同一个Nacos namespace/group前面已经提醒过。看提供方是否被保护阈值“屏蔽”了如果提供方实例很少健康比例低于保护阈值Nacos会不进健康实例列表这种情况在控制台能看到实例状态异常。还有一个多网卡导致的人身坑服务主机有多个网卡注册到Nacos的IP是内网的管理网段消费者在业务网段访问不到。解决方式是显式指定注册IPspring: cloud: nacos: discovery: ip: 192.168.10.1005.3 Dubbo接口忽好忽坏一会超时一会正常这是Dubbo环境很典型的问题。症状是调用偶尔报Read timed out但过一会又好了。常见原因有三个提供方线程池被打满Dubbo默认的线程池大小固定如果某个慢接口拖住了所有线程新请求只能排队等待时间超过消费方timeout就报超时。解决方向是给慢接口单独配线程池、调大线程数、或者让消费方超时更宽容。消费者超时设置太激进DubboReference上的timeout如果小于提供方实际处理时间就会偶发超时。把timeout调大观察是否能改善。服务实例之间存在严重性能差异比如新旧两个版本同时部署新实例是新的物理机性能好旧实例是共享虚拟机响应慢。用leastactive负载均衡策略可以让慢实例少接流量或者直接把慢实例下线。定位的时候不要只看日志里的异常要连着看提供方的线程池活跃度、GC情况、和网络链路一起查。5.4 版本兼容性坑位速查场景坑点建议Spring Boot 2.4 搭配 Spring Cloud 2020Ribbon被移除Feign若没引LoadBalancer会挂引入spring-cloud-starter-loadbalancerNacos 1.x 与 Nacos 2.x2.x默认gRPC端口9848防火墙忘开实例注册不上服务器需要同时开放8848和9848端口Dubbo 2.7 与 Dubbo 3注册模型从接口级改为应用级老消费者可能找不到新提供者升级时配置register-modeinstance兼容或一起升级Spring Cloud Alibaba 版本与Spring Boot不对应版本错配启动就报NoClassDefFoundError对照官方版本说明选配套版本不要最新打架5.5 一张配置速查表我把Feign和Dubbo的核心配置点整理成一张表方便你抄作业配置项FeignDubbo注册中心地址spring.cloud.nacos.discovery.server-addrdubbo.registry.addressnacos://127.0.0.1:8848服务名配置spring.application.namedubbo.application.name远程接口声明FeignClient(name服务名)DubboReference超时配置feign.client.config.default.readTimeoutdubbo.consumer.timeout或DubboReference(timeout...)重试控制默认不重试可自定义RetryerDubboReference(retries0)写操作必须配负载均衡LoadBalancer默认轮询可配LoadBalanced或自定义DubboReference(loadbalanceroundrobin)四种策略降级/容错Feign fallback类集群容错模式clusterfailover/failfast/failsafe启动开关启动类加EnableFeignClients不需要额外开关引入starter即可我个人的习惯是能用Feign先跑通的项目不要一上来就上Dubbo但要上Dubbo的项目一定要安排人把服务治理玩明白再铺开。服务调用从来不是“通”就完了超时、重试、容错、隔离、观测这些才是生产环境真正考验人的地方。你可以在实际项目里先小范围验证跑一两个核心接口对比一下两种方式在你业务下的表现再决定要不要把整套调用方式统一掉。毕竟架构选型最终还是要为业务和团队的长期维护服务。