在 Spring Cloud 的地盘上我为什么把 RPC 交给 DubboDubbo 3.3 · TRI · 一个内部调用到底该长什么样先花两分钟科普再聊选型 · 附 MateCloud 真实配置与代码几乎所有 Spring Cloud 教程都默认一件事服务间调用 OpenFeign。MateCloud 偏偏没这么做它把服务间调用交给了 Dubbo。这不是念旧也不是为了简历上多写一行。它背后是一个我想认真聊聊的问题——两个服务之间的一次调用到底该长什么样。不过在聊选型之前得先把 Dubbo 是什么说清楚。01先花两分钟Dubbo 到底是个啥已经熟 Dubbo 的朋友可以直接跳到第 02 节。这里只给还不熟的读者铺个底。一句话Dubbo 是一个 RPC 框架。RPC 是 Remote Procedure Call远程过程调用的缩写说人话就是——让你「调用另一台机器上的一个方法」写起来跟「调用本地的一个方法」几乎一样。你只管写userService.getById(id)它在背后帮你把参数打包、找到对方机器、发过去、再把结果拿回来。一次 Dubbo 调用里有三个角色记住它们后面就好懂了Provider提供者真正干活、对外提供服务的一方。Consumer消费者发起调用、要结果的一方。Registry注册中心一本「服务通讯录」。Provider 启动时把「我是谁、我在哪」登记进去Consumer 要调用前先来这儿查到地址再直连过去。MateCloud 用 Nacos 兼任这个角色。那它和 Spring Cloud 里最常见的 OpenFeign 是什么关系先说个很多人没留意的出身问题——它俩其实来自两个不同的「家族」。组件出身 · 所属家族OpenFeign源自 Netflix OSS后由 Spring 官方接手如今是Spring Cloud 官方全家桶的一员spring-cloud-openfeignDubbo阿里巴巴开源2018 年捐给 Apache、2019 年成为Apache 顶级项目在 Spring Cloud 世界里经Spring Cloud Alibaba融入这点值得多说一句MateCloud 整套走的是Spring Cloud Alibaba这一系——Nacos 管注册与配置、Dubbo 管 RPC、Sentinel 管限流、Seata 管事务。Dubbo 本就是这个家族的正式成员所以「在 Spring Cloud 的地盘上用 Dubbo」一点都不违和它俩本来就是同门反倒是 Netflix 那套老全家桶Eureka / Feign / Ribbon / Hystrix如今大多进了维护期。所以标题那句「Spring Cloud 的地盘」其实是句玩笑话——Dubbo 是这地盘上的正牌住户。抛开出身两者解决的是同一个问题——服务之间怎么互相调用。区别在「用什么姿势」Feign 本质是发一个 HTTP 请求REST 风格Dubbo 走的是 RPC。这就引出了本文真正想聊的——同样是服务间调用这两种姿势差在哪为什么 MateCloud 选了后者。02先亮观点内部调用不该拿 REST 的账单来结Feign 的做法是把一次内部调用包装成一次 HTTP 请求拼 URL、塞 header、发出去、再按状态码解释结果。REST 这套东西是给「谁都能调、跨团队、跨公网」的开放接口设计的它的复杂度换来的是通用性、可缓存、无状态这些好处。可服务和服务之间的调用不是这种场景。它是东西向流量双方同属一个系统、共享一套版本、跑在同一张内网里。你付了 REST 的税却几乎享受不到 REST 的任何红利。Dubbo 的思路正相反一次远程调用就该像一次本地方法调用。先把话说在前面免得你以为我要吹性能——性能不是我选 Dubbo 的理由。TRI 协议确实比 HTTP/1.1 JSON 快但在大多数团队的真实流量下这点差距淹没在数据库和网络抖动里属于基准测试上好看、生产环境无感的那类优势。真正让我下决心的是另一件更朴素的事——契约。03契约这件事Feign 输在起跑线Feign 的契约本质是注解里的一个 URL 字符串。provider 悄悄把返回体删了个字段、改了个路径consumer 这边照样编译通过、照样打包上线——直到某个请求真的打过去才在生产环境里 404 或反序列化失败。错误被推迟到了运行时而且是别人的运行时。MateCloud 把所有跨服务接口收在一个独立模块mate-api里provider 和 consumer 都编译期依赖它provider 用DubboService实现它consumer 用DubboReference引用它两边带上同一个 version group。现在provider 改一个方法签名consumer 立刻编译不过——CI 上一个红叉比 Grafana 上一条变红的曲线便宜太多了。顺带说个细节接口上那个CrossTenantRpc不是装饰。多租户系统里跨租户查询是危险动作MateCloud 要求你在契约上就把它标出来没标的调用默认按「带租户」处理。契约不只描述形状也顺手把安全语义钉死了。04TRIDubbo 甩掉「Java 孤岛」那顶帽子很多人对 Dubbo 的印象还停在老版本一个私有的二进制协议抓包看不懂、跨语言费劲活脱脱一座 Java 孤岛。这个印象该更新了。MateCloud 用的是 Dubbo 3 的TRITriple协议——本质就是 gRPC over HTTP/2。这一步的意义被严重低估了你不用写一行.proto直接用 Java 接口定义服务却拿到了 gRPC 的整套生态——HTTP/2 多路复用、标准化的流式、跨语言互通、以及那些成熟的可观测工具。历史上「Dubbo 只能 Java 玩」这条最大的劝退理由就这么悄悄没了。序列化选的是fastjson2不是 Hessian也不是 protobuf。我知道有人一看到 fastjson 就想起当年的 autotype 漏洞——这个担心我得认但也得说清楚fastjson2 默认关闭了 autotype无需 schema、速度也够。它能安心用有个前提Dubbo 端口只在内网、绝不暴露公网。而这正好和上一篇讲的网关 HMAC 签名接上了——网关到下游的每一跳都签名验身Dubbo 网格活在一个可信内网里。安全从来不是单点是一整条链一起兜。05最好的 Dubbo是你看不见的 Dubbo这是我在 MateCloud 里最欣赏的一个克制整个 domain 和 application 层你搜不到一个 Dubbo 的 import。DubboReference只被允许出现在一个地方——infrastructure 层的适配器里而且这个适配器实现的是 domain 自己定义的端口接口。这不是架构洁癖。正因为 Dubbo 被关进了这个小盒子MateCloud 才能靠一个属性mate.rpc.modelocal把它整个换成进程内直调的LocalAdapter把三个微服务打成一个单体 JAR——上一篇讲的「双形态」落点就在这里。反过来说句得罪人的如果 DubboReference 出现在你的 Service 里、Controller 里你其实已经悄悄失去了变回单体的能力只是很多团队要到上线半年、想合并服务省成本时才发现。顺便一提MateCloud 全项目只有一处EnableDubbo就在那个受 mode 开关控制的自动配置类上——单体模式下Dubbo 连启动都不启动。06分布式上下文不会自己跟过来一次本地方法调用里有四样东西是白送的当前线程上的用户身份、一个事务、一条完整的异常栈、一条贯穿的 traceId。它们都躺在 ThreadLocal 里你不用管。可 RPC 调过去provider 是另一个进程里的另一个线程。ThreadLocal 一个字都不会跟过来。traceId 断了、tenantId 没了日志对不上、租户还可能串。MateCloud 的做法是在 Dubbo 的 consumer / provider 过滤器里把这些上下文塞进调用的 attachment 随请求过网provider 侧取出来重建处理完在 finally 里清干净——防止线程池复用时上一条请求的身份残留串味。这套逻辑和异步队列、线程池要处理的其实是同一课凡是「换了线程」的地方上下文都得手动搬运不搬就丢。而我最想让你留意的是藏在配置注释里的两个默认值——判断一个脚手架成不成熟看的往往不是它有多少功能而是它的默认值有没有把踩过的坑写进去provider 侧 retries 0。Dubbo 默认是 2。可自动重试一个写操作就是重复下单、重复扣款的经典配方。写操作绝不该由框架替你悄悄重放。enable-empty-protection true。注册中心在某个 provider 重启的瞬间可能推来一个空列表关掉这个保护缓存地址会被清空且不再恢复直接 No provider available。这行配置不在任何入门教程里它是重启竞态踩出来的疤。07什么时候别用 Dubbo聊了半天 Dubbo 的好也得把边界划清楚。同步 RPC 有个天然的代价——它把两个服务的生命周期绑在了一起。provider 挂了正在等它返回的 consumer 当场跟着挂超时、重试、降级一样都不能少全得你自己兜。所以判断标准其实很简单一个问题就能分开这次跨服务交互调用方需要「立刻拿到返回值」吗认证要查用户、鉴权要查权限——要结果、要一致、要立刻这是 Dubbo 的主场。用户注册完发条通知、写条审计、加点积分——不该阻塞主流程provider 一时不在也无所谓这是领域事件MQ的主场。MateCloud 两个都用各归各位。把什么都塞进 RPC就是把微服务重新拼回一个「分布式单体」——还倒贴上了网络的不可靠。08写在最后回到最初那个问题两个服务之间的一次调用该长什么样。我的答案是——它该是一次有编译期契约、能一键退回单体、上下文不会中途丢失的方法调用。MateCloud 选 Dubbo不是为了炫技是为了让「跨服务调用」这件事回到它本该有的朴素样子。你当然可以不同意。Feign 的 REST 语义在对外开放、多语言异构的场景里依然是更好的选择。但在一套边界清晰、同构演进的微服务底座里我更愿意把这份「像方法调用一样」的确定性握在编译器手里
