哎小伙伴们有没有遇到过这种情况？用Dubbo老版本的时候啊,一个应用曝露十几个接口,注册中心里就会有十几个/dubbo/xxxService/providers 的节点…害别提了,运维kan了dou头疼!Zui近好多人问Dubbo 3.x怎么从接口级转到应用级发现,今天咱就唠唠这个事,保证用Zui接地气的话讲明白～

先说说:以前那个"坑死人"的接口级发现

顾名思义嘛,旧版本Dubbo是按"接口"来存服务地址嘅—比如你写个UserService和OrderService两个接口,那ZooKeeper里就得建俩目录:/dubbo/com.yourcompany.UserService/providers和/dubbo/com.yourcompany.OrderService/providers.

要是一个胖子 application 曝露50个 interface?那就是50个节点蹲在注册中心里!geng蛋疼嘅系,只要 application 挂一台实例,这50个节点dou要挨个删一遍 Provider URL…你懂嘅嘛,凌晨三点改配置改到想吐嘅滋味!

而且数据量还呈平方增长—2000台实例×500个 interface=1e6条记录?注册中心分分钟卡成PPT!并发高嘅时候Consumer订阅超时?简直家常便饭.

再kan:新玩法"应用级发现"到底香在哪?

简单粗暴一句话: 一个application只注册一次!

不管你 application 裏面塞瞭UserService、OrderService还是PaymentService几十个 interface,dou只在Nacos/ZK裏存一个以"application name"为键嘅条目—比如/services/UserApp底下挂著所有 interface 的元数据:"这个app提供User/Order/Pay三个interface哦~".

Consumer要调用UserService嘅时候?不再傻乎乎去/dubbo/UserService找瞭—而是先查: "谁提供UserService?"哦系UserApp!那直接订阅/UserApp嘅实例列表就行了!是不是瞬间清爽一万倍?!

关键还对齐瞭云原生:K8s裏面 Service 本来就是按"工作负载" 来管理嘅,Dubbo这波直接跟上时代节奏—以后对接k8s service mesh还怕啥?

但问题来瞭:老系统咋平滑过渡?总不Neng一刀切掉吧?

害~ Dubbo早料到这点瞭!整瞭套"灰度迁移策略",分成三步阶梯式推进,稳得一批:

.第一步: FORCE_INTERFACE

"我就不用新东西,全部走原来嘅interface订阅!"适合刚开始试点,或者新系统想先稳定跑一阵嘅情况.这时候MigrationInvoker裏面嘅currentAvailableInvoker直接指向interface级别嘅invoker—跟旧版本完全一样,零风险.

.第二步: APPLICATION_FIRST

"大部分流量走application发现,小部分留着回退到interface."比如promotion=80—意思系80%请求走UserApp实例列表,20%随机切回/dubbo/UserService路径.就算application那边出瞭小故障,还有20%流量兜底呢!超贴心有没有~

.第三步: FORCE_APPLICATION

"老子全量上application发现!"等试点跑瞭一两个月确认没问题,直接一刀切掉interface订阅—完美!

.MigrationInvoker:双invoker开关の幕后英雄

public class MigrationInvokert implements MigrationClusterInovker { Clusterlnvokert invokert; //老掉牙のinterface invokert Clusterlnvokert serviceDiscoverylnvokert; //新潮のapplication invokert Clusterlnvokert currentAvailablelnvokert; //当前在用の家伙 MigrationStep step; //当前迁移阶段 }

Migrationlnvokert才是过渡の核心!它同时hold住俩invokert::

- invokert:传统のRegistryDirectory+Cluster搞出来のinterface级别订阅器—连ZooKeeper那种;

- serviceDiscoverylnvokert: ServiceDiscoveryRegistryDirectory+Cluster搞出来のapplication级别订阅器—连Nacos/K8s那种;

- currentAvailablelnvokert:每次RPC调用dou走这家伙,

- step决定它指向谁.

::

public Result invoke { if { if .nextDouble) { return invokert.invoke; //按比例回退 } return decideInvokert.invoke; //检查后选可用の } return currentAvailablelnvokert.invoke; }

:"decideInvokert"又是啥?::它会Zuo阈值检查:public boolean shouldMigrate { return appAddressSize / interfaceAddressSize>= threshold; }:只有当application实例数≥interface实例数×阈值时才敢切过去!不然直接回退到interface invokert—安全第一!.