dubbo：虽然Protocol的@SPI指定了‘dubbo’却执行先RegistryProtocol后DubboProtocol

已于 2023-06-08 18:02:04 修改
阅读量873 收藏 1
点赞数
分类专栏： dubbo spring 技能 文章标签： spring rpc 网络
于 2022-06-08 18:54:50 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/noob_can/article/details/125180669
版权
spring 同时被 3 个专栏收录
9 篇文章 1 订阅
订阅专栏
技能
9 篇文章 0 订阅
订阅专栏
dubbo
3 篇文章 0 订阅
订阅专栏

目录

总结

Invoker

Protocol

@Adaptive修饰方法来指明需要动态生成代码类来增强指定方法

#export 服务发布过程

#loadRegistries 将协议从'dubbo' 改为'registry'

#doExportUrlsFor1Protocol 执行发布

 #exportLocal 提前生成 'Injvm' 协议发布Local服务供优先本地调用

Protocol$Adaptive#export 增强发布逻辑

RegistryProtocol#export 发布过程

 RegistryProtocol#doLocalExport： 从'registry'协议URL的‘export’部分拿到源'dubbo'协议URL，回调DubboProtocol

DubboProtocol#export 开启网络通信：以[serviceGroup + serviceName + serviceVersion + port] 缓存了Invoker， 以[host:post]为Key缓存了服务端HeaderExchangeServer

总结

  1.  提前默认'Injvm' 协议会发布Local服务，优先访问本地提供的服务；由URL显示申明'scope = remote'来关闭。
  2. 在DubboProtocol里
    1. Provider侧：
          以[host:post]为Key缓存了服务端HeaderExchangeServer(NettyServer) (这里只可能协议端口port会变，所以通常只有1个NettyServer)；以[serviceGroup + serviceName + serviceVersion + port] 缓存Invoker(DubboExporter)。
    2. Consumer侧：单一长连接Rpc客户端
         实际的provider提供的服务地址URL
      1. 没有配置‘connections’ 或 (默认)是0:  将以[host:post]为Key创建并缓存唯一的共享连接客户端ReferenceCountExchangeClient(封装了HeaderExchangeClient，内部引用计数)，相同的服务端Provider( host+port )下同此配置的所有服务接口都共用一个客户端连接！
      2. URL配置‘connections’ > 0 , 即使配置为1，该Provider提供的服务接口(service interface)单独有‘connections’个连接客户端HeaderExchangeClient，当dubbo消费者发送请求路由到该Provider时DubboInvoker#doInvoke将轮询使用。
      3. 客户端底层的NettyClient会设置keepAlive。URL有指定'lazy'，则延迟创建及connect remote。
  • @SPI：注解指定名称匹配接口的使用实现类。在接口的配置文件里不仅有最终要使用的target对象类，还把【有该接口类型作为入参的构造器】的实现类在创建target对象时当做wrapper裹在外层。
  • @Adaptive: 运行时，对含有被该注解修饰方法的类，用javassist生成并编译增强代码。只有被修饰的方法才被增强！ 

所以Protocol实际上是Protocol$Adaptive，在创建target实例时外层用wrapper包裹。最重要的是ProtocolFilterWrapper， 它对DubboProtocol订阅和发布过程的Invoker筛选出合适的Filter来创建过滤器链（以@Activate来指定group是provider | consumer），eg. MonitorFilter、TPSLimiter、ExecuteLimitFilter...

target按逻辑处理先后顺序如下：

  • InjvmProtocol：服务调用会优先走本地
  • RegistryProtocol：管理与注册中心的相关操作。 如发布、订阅...   ZookeeperRegistry 向zookeeper写入path
  • DubboProtocol：核心底层。开启Provider的NettyServer及Consumer端NettyClient双向通信...

Invoker

Provider侧： Invoker的底层是真实服务的业务处理者。

DubboProtocol#export：

 Consumer侧：Invoker底层是通信客户端 HeaderExchangeClient , 它的底层是由NettyTransporter创建的NettyClient。

 DubboProtocol#refer：

 // 这里的url是到接口层面的：dubbo://127.0.0.1:20880/cn.noob.service.RepayPlanService?anyhost=true&application=noob-core&check=false&default.check=false&dubbo=2.6.2&generic=false&group=noob-rest&interface=cn.noob.service.RepayPlanService&logger=slf4j&methods=listOverdueRepayPlan,checkRepayAmountBeforeSettle,listOverdueRepayPlanByChannelForReconcile,checkRepayPlanBeforeSettle,listRepayPlanByLoanNo,saveBatch,settleRepayPlan,getRepayPlanSizeByLoanNo&pid=12268&register.ip=127.0.0.1&remote.timestamp=1679367745765&retries=-1&revision=1.0&side=consumer&timeout=180000&timestamp=1679367784543&version=1.0
    public <T> Invoker<T> refer(Class<T> serviceType, URL url) throws RpcException {
        optimizeSerialization(url);
        // create rpc invoker.
        DubboInvoker<T> invoker = new DubboInvoker<T>(serviceType, url, getClients(url), invokers);
        invokers.add(invoker);
        return invoker;
    }

// 判定URL的connections > 0 , 则以具体provider的接口服务service为维度单独创建'connections'个连接客户端; 
// 未配置或配置为0则以[host:post]provider服务主机创建(或使用缓存中的)单一共享的连接客户端
private ExchangeClient[] getClients(URL url) {
        // whether to share connection
        boolean service_share_connect = false;
        int connections = url.getParameter(Constants.CONNECTIONS_KEY, 0);
        // if not configured, connection is shared, otherwise, one connection for one service
        if (connections == 0) {
            service_share_connect = true;
            connections = 1;
        }

        ExchangeClient[] clients = new ExchangeClient[connections];
        for (int i = 0; i < clients.length; i++) {
            if (service_share_connect) {
                clients[i] = getSharedClient(url);
            } else {
                clients[i] = initClient(url);
            }
        }
        return clients;
    }

Protocol

Protocol提供了服务发布#export 及 服务消费订阅#refer两个操作入口。

以服务发布Protocol#export的过程实现为例，讲讲dubbo对 @SPI（载入的接口实现类由文件配置并指定名称使用）和@Adaptive（动态创建并编译增强代码，增强被修饰的方法）。

/** Protocol. (API/SPI, Singleton, ThreadSafe) */
@SPI("dubbo")
public interface Protocol {
  
    int getDefaultPort();

    //服务提供者发布服务, 这里的invoker是serviceImpl的封装代理
    @Adaptive
    <T> Exporter<T> export(Invoker<T> invoker) throws RpcException;

    // 消费者的订阅服务, 这里会绑定通信Client
    @Adaptive
    <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException;

    void destroy();
}

图里有2个重要的注解：

  1. 类定义上的@SPI("dubbo") ： 结合dubbo对spi的扩展实现，由文件配置的方式来指定加载接口的实体类。 所以是DubboProtocol；
  2. 在#export、#refer方法上使用的@Adaptive ： dubbo对有该注解修饰方法的类动态生成增强代码类，只增强被修饰的方法！ 

在Provider发布服务的过程里，ServiceBean的父类ServiceConfig里有个静态Protocol对象：

private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

配置文件 \META-INF\dubbo\internal\com.alibaba.dubbo.rpc.Protocol：

按常规逻辑这里指定的就该是DubboProtocol，但实际上确如下图所示：Protocol$Adaptive！

这也就引出了本文的主题：dubbo会对有@Adaptive修饰方法的类动态生成代码，来增强方法。具体如下：

package com.alibaba.dubbo.rpc;

import com.alibaba.dubbo.common.extension.ExtensionLoader;

/** 协议自适应类，只增强重写了@Adaptive修饰的方法refer、export */
public class Protocol$Adaptive implements com.alibaba.dubbo.rpc.Protocol {
    public void destroy() {
        throw new UnsupportedOperationException("method public abstract void com.alibaba.dubbo.rpc.Protocol.destroy() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!");
    }

    public int getDefaultPort() {
        throw new UnsupportedOperationException("method public abstract int com.alibaba.dubbo.rpc.Protocol.getDefaultPort() of interface com.alibaba.dubbo.rpc.Protocol is not adaptive method!");
    }

    /** 服务引用 */
    public com.alibaba.dubbo.rpc.Invoker refer(java.lang.Class arg0, com.alibaba.dubbo.common.URL arg1) throws com.alibaba.dubbo.rpc.RpcException {
        if (arg1 == null) throw new IllegalArgumentException("url == null");
        com.alibaba.dubbo.common.URL url = arg1;
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
        if (extName == null)
            throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");
        // 根据extName找到具体适应类，然后调用方法
        com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.refer(arg0, arg1);
    }

    /**  服务暴露 */
    public com.alibaba.dubbo.rpc.Exporter export(com.alibaba.dubbo.rpc.Invoker arg0) throws com.alibaba.dubbo.rpc.RpcException {
        if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null");
        if (arg0.getUrl() == null)
            throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null");
        com.alibaba.dubbo.common.URL url = arg0.getUrl();
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol()); // 默认是dubboProtocol!
        if (extName == null)
            throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");
        // 根据extName找到具体适应类，然后调用方法
        com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.export(arg0);
    }

@Adaptive修饰方法来指明需要动态生成代码类来增强指定方法

当执行进入 ExtensionLoader#getAdaptiveExtension()  -> #createAdaptiveExtension 动态创建并编译代码的过程里：

首先会从配置文件中装载实现Protocol接口的实现类。

 判定：  [有入参是Protocol.class的构造器] 的实现类将被集中到“cachedWrapperClasses”，在后面对真正使用的Protocol实例进行装饰！

// 构造函数的入参是指定的接口   
 private boolean isWrapperClass(Class<?> clazz) {
        try {
            clazz.getConstructor(type);
            return true;
        } catch (NoSuchMethodException e) {
            return false;
        }
    }

ExtensionLoader#createAdaptiveExtensionClass使用 javassist 字节码编辑技术动态创建并编译了 Protocol$Adaptive !  在文章开头有贴它源码。

#export 服务发布过程

回到入口处:  ServiceBean#export() -> #doExport() ->#doExportUrls

  private void doExportUrls() {
        List<URL> registryURLs = loadRegistries(true); //判定如果有注册中心，重写url协议为register
        for (ProtocolConfig protocolConfig : protocols) {
            doExportUrlsFor1Protocol(protocolConfig, registryURLs);//发布服务
        }
    }

#loadRegistries 将协议从'dubbo' 改为'registry'

原始的URL信息配置如下图：

经过处理后得到'registry协议'的URL：

registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=noob-core&dubbo=2.6.2&logger=slf4j&pid=27468&registry=zookeeper&timestamp=1654680258624

这里如果由多个注册中心地址，会一一匹配生成多个。 

#doExportUrlsFor1Protocol 执行发布

这里会根据原始的配置参数组装dubbo协议头的URL，并在之后创建Invoker代理时，将它拼入registry协议头URL末尾的export部分！

dubbo://139.139.37.184:20880/cn.noob.interf.BuyBackInterface?anyhost=true&application=noob-core&bind.ip=139.139.37.184&bind.port=20880&dubbo=2.6.2&generic=false&group=noob-rest&interface=cn.noob.interf.BuyBackInterface&logger=slf4j&methods=buyBackSendRepayToYcloans,buyBack&pid=25416&retries=-1&revision=1.0&side=provider&threads=1024&timeout=180000&timestamp=1654683368355&version=1.0

 转换成了：

registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=noob-core&dubbo=2.6.2&export=dubbo%3A%2F%2F139.139.37.184%3A20880%2Fcn.noob.interf.BuyBackInterface%3Fanyhost%3Dtrue%26application%3Dnoob-core%26bind.ip%3D139.139.37.184%26bind.port%3D20880%26dubbo%3D2.6.2%26generic%3Dfalse%26group%3Dnoob-rest%26interface%3Dcn.noob.interf.BuyBackInterface%26logger%3Dslf4j%26methods%3DbuyBackSendRepayToYcloans%2CbuyBack%26pid%3D25416%26retries%3D-1%26revision%3D1.0%26side%3Dprovider%26threads%3D1024%26timeout%3D180000%26timestamp%3D1654683368355%26version%3D1.0&logger=slf4j&pid=25416&registry=zookeeper&timestamp=1654683267651

 #exportLocal 提前生成 'Injvm' 协议发布Local服务供优先本地调用

injvm://127.0.0.1/cn.noob.interf.BuyBackInterface?anyhost=true&application=noob-core&bind.ip=139.139.37.184&bind.port=20880&dubbo=2.6.2&generic=false&group=noob-rest&interface=cn.noob.interf.BuyBackInterface&logger=slf4j&methods=buyBackSendRepayToYcloans,buyBack&pid=25708&retries=-1&revision=1.0&side=provider&threads=1024&timeout=180000&timestamp=1655083273825&version=1.0

当应用既是服务的提供者，同时也是这个服务的消费者，可以直接对本机提供的服务发起本地调用。

 如果URL上没有指定'scope = remote'，会先于RegistryProtocol过程使用InjvmProtocol暴露本地服务，不会对外开启端口。

在同一个进程里对该服务的调用会优先走本地，它首先会进入Protocol$Adaptive#export， 所以也会构建invoke的Filter链！

Protocol$Adaptive#export 增强发布逻辑

// Protocol$Adaptive源码
public com.alibaba.dubbo.rpc.Exporter export(com.alibaba.dubbo.rpc.Invoker arg0) throws com.alibaba.dubbo.rpc.RpcException {
        if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null");
        if (arg0.getUrl() == null)
            throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null");
        com.alibaba.dubbo.common.URL url = arg0.getUrl();
        String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol()); // 如果url的protocol为空， 默认走 dubbo
        if (extName == null)
            throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");
        // 根据extName找到具体适应类，然后调用方法
        com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
        return extension.export(arg0);
    }

从上述Protocol$Adaptive源码可知， 这里关键的是： url#getProtocol()决定了下一个要执行的Protocol接口实现类！

 所以此时使用ExtensionLoader#getExtension('registry')去拿registryProtocol的实例：如果没有历史缓存，则#createExtension创建新的实例。

 从上图中可知道： 新建真实对象实例时会使用多个wrapperClass来封装。这几个wrapperClass就是在读配置文件时归集而来[有Protocol为入参构造器]的实现类。

  1. ProtocolFilterWrapper : 对非‘registry’协议头的URL在export、refer时给Invoker绑定过滤器链FilterChain！Filter通过@Activate来指定支持的group:  provider | consumer 及在URL特别指定匹配相应Filter的操作指令：executes、tps、tracing...。 
  2. QosProtocolWrapper : Quality of Service，服务质量。 用来开启一个默认22222端口的服务，用来后台telnet上来online和offline service。
  3. ProtocolListenerWrapper : 通过 ExporterListener、InvokerListener 接口对服务的订阅和消费进行监听。默认看起来没具体实现。

这里还需要关注一下方法ExtensionLoader#injectExtension：

通过反射setter方式执行方法RegistryProtocoL#setProtocol，又把AdaptiveExtensionFactory里缓存的Protocol$Adaptive写回了RegistryProtocol里！

RegistryProtocol#export 发布过程

  public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
        //export invoker   处理dubboProtocol
        final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker);

        URL registryUrl = getRegistryUrl(originInvoker);

        //registry provider
        final Registry registry = getRegistry(originInvoker);
        final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);

        //to judge to delay publish whether or not
        boolean register = registedProviderUrl.getParameter("register", true);

        ProviderConsumerRegTable.registerProvider(originInvoker, registryUrl, registedProviderUrl);

        if (register) {
            // 在zookeeper上发布服务URL
            register(registryUrl, registedProviderUrl);
            ProviderConsumerRegTable.getProviderWrapper(originInvoker).setReg(true);
        }

        // Subscribe the override data
        // FIXME When the provider subscribes, it will affect the scene : a certain JVM exposes the service and call the same service. Because the subscribed is cached key with the name of the service, it causes the subscription information to cover.
        final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
        final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
        overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
        registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener); 
        //Ensure that a new exporter instance is returned every time export
        return new DestroyableExporter<T>(exporter, originInvoker, overrideSubscribeUrl, registedProviderUrl);
    }

这里发布核心过程按先后顺序：

  1. RegistryProtocol#doLocalExport：从'registry'协议URL的‘export’部分拿到源'dubbo'协议URL，进入Protocol$Adaptive#export方法体内后，由此选择了回调DubboProtocol。
  2. ZookeeperRegistry#register：在zookeeper上写入服务地址节点。ZookeeperRegistry的抽象父类是FailbackRegistry，它定义了在发布#register、订阅#subscribe、变化产生的事件通知#notify（eg. AbstractRegistry#notify->#saveProperties缓存文件更新、更新RegistryDirectory里服务提供者Invoker视图） 的 处理逻辑及异常时的补差任务。

 RegistryProtocol#doLocalExport： 从'registry'协议URL的‘export’部分拿到源'dubbo'协议URL，回调DubboProtocol

如下图所示，这里会从入参的'registry'协议URL里拿到‘export’部分，它就是源头的dubbo协议头URL。

从下图中可以看出，又要回到Protocol$Adaptive#export方法体内，只是这次选择执行了DubboProtocol#export

DubboProtocol#export 开启网络通信：以[serviceGroup + serviceName + serviceVersion + port] 缓存了Invoker， 以[host:post]为Key缓存了服务端HeaderExchangeServer

以DubboExporter封装了Invoker，并缓存在'AbstractProtocol.exporterMap'里。key的构建依赖于： 见AbstractProtocol#serviceKey ：serviceGroup + serviceName + serviceVersion + port

noob-rest/cn.noob.interf.BuyBackInterface:1.0:20880

以 [host:post] 为Key，ConcurrentHashMap缓存了HeaderExchangeServer，它实际上是NettyServer, 这里端口默认是20880； 所以一般情况下只有1个Server。

 创建过程如下：

最终的URL: 

dubbo://139.139.37.184:20880/cn.noob.interf.BuyBackInterface?anyhost=true&application=noob-core&bind.ip=139.139.37.184&bind.port=20880&channel.readonly.sent=true&codec=dubbo&dubbo=2.6.2&generic=false&group=noob-rest&heartbeat=60000&interface=cn.noob.interf.BuyBackInterface&logger=slf4j&methods=buyBackSendRepayToYcloans,buyBack&pid=25708&retries=-1&revision=1.0&side=provider&threads=1024&timeout=180000&timestamp=1655083273825&version=1.0
  1. 指定数据报文的(反)序列化方式DubboCodec，实际是Hessian2Serialization。
  2. HeaderExchangeServer里开启消费端Client与服务端Server的心跳检查任务HeartBeatTask的调度器。默认每隔60s检测一次，3分钟内没响应则发起重连（先AbstractClient#disconnect()关闭channel后AbstractClient#connect()再连接）。它的底层核心是通信的NettyServer。
  3. DubboProtocol内自定义实现的ExchangeHandlerAdapter会当作ChannelHandler绑定到NettySever上；NettyHandler定义了各种通信事件的处理方法：messageReceived、writeRequested、channelConnected、channelDisconnected
  4. 当传递的消息RpcInvocation被接收时，ExchangeHandlerAdapter#reply方法解析URL找到缓存的DubboExporter，执行方法Invoker#invoke。
noob_can
关注
专栏目录
Dubbo源码解析（七）Dubbo Protocol 之 RegistryProtocol
wuhulala的休息室
06-07 6600
RegistryProtocol 与 DubboProtocol的区别 * RegistryProtocol 可以认为并不是一个真正的协议，他是这些实际的协议（dubbo . rmi）包装者，这样客户端的请求在一开始如果没有服务端的信息，会先从注册中心拉取服务的注册信息，然后再和服务端直连,这个很重要，因为在我司是通过注册中心进行路由转发信息的。 * URL 协议头不同，`RegistryProtocol` 通过 URL 的 `registry://` 协议头标识， DubboProtocol通过
dubbo 协议层【Protocol】分析
俗民·不自扰
09-20 1868
dubbo框架有很多通讯协议可供选择，不同通讯协议相当于实现RPC功能的不同路径 将RPC功能类比成：“从A城市到B城市” 这么一件事情 多种协议 可类比成 从A到B 有多种可选择的交通工具 选择一种具体交通工具 就决定了：买什么票、司机是谁、舒适度、交通线路 ... dubbo的任何一种协议也规定【或默认】了 序列化方式、【长|短】链接、底层协议【http|tcp】、同步或异步、消息处理线程模型 ...
dubbo registry protocol
07-24
dubbo registry protocol
dubbo的服务注册原理分析
最新发布
weixin_44550507的博客
08-26 627
Dubbo的服务注册原理主要基于注册中心来实现服务的动态发布和引用，其中Zookeeper是常用的注册中心之一
Dubbo笔记 ⑨ : 消费者启动流程 - RegistryProtocol#refer
猫吻鱼的博客
05-15 1784
一、前言 本系列为个人Dubbo学习笔记，内容基于《深度剖析Apache Dubbo 核心技术内幕》, 过程参考官方源码分析文章，仅用于个人笔记记录。本文分析基于Dubbo2.7.0版本，由于个人理解的局限性，若文中不免出现错误，感谢指正。 在 Dubbo笔记⑧ : 消费者启动流程 - ReferenceConfig#get 一文中，我们介绍到在存在注册中心的情况下，ReferenceConfig#createProxy 在创建提供者代理的时候，会调用 RegistryProtocol#refer 将 U
Dubbo 源码阅读（八）RegistryProtocol
日有寸进
04-02 1162
RPC过程 源码 @Override @SuppressWarnings("unchecked") public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException { //"registry" "dubbo" url = url.s...
Dubbo注册协议原理以及源码阅读
a1032722788的博客
03-29 438
前言 继上次小编所讲RPC协议暴露服务并且远程调用之后，小编这次给大家带来注册中心协议整体流程原理以及源码精讲，Dubbo的RPC协议服务暴露以及源码分析文章中，远程服务暴露可以只通过RPC协议即可，那为什么要注册中心呢，不知道大家有没有考虑到当多服务多调用的时候，我们的服务端url不可能写死，那么我们的注册中心就上场了。那怎样才可以与RPC协议进行交互并且注册服务到注册中心，这就是本篇小编给大家带来的内容。 注册协议 如上图所示，RegistryProtocol与DubboProtocol都是实现了Pr
深度解析Dubbo的可扩展机制SPI源码：从理论到实践，打造高效、稳定的分布式服务框架
01-11
在Dubbo SPI的实现中，`getExtensionLoader(Class)`方法是获取指定接口的ExtensionLoader实例的关键。一旦获取到ExtensionLoader，就可以通过`getExtension(String name)`方法获取名为"name"的具体扩展点实现。例如...
1.为什么dubbo要自己设计一套SPI.txt
05-25
### 为什么Dubbo要自己设计一套SPI？ #### 一、SPI基本概念 SPI（Service Provider Interface）是一种服务发现机制，允许程序在运行时查找并加载实现特定接口的服务提供者。这种机制广泛应用于Java环境中，其核心...
dubbo的filter和@Activate和@Adaptive和配置优先级
我3的博客
07-30 832
Filter 1、实现Filter接口 2、自定义的在默认的过滤器实现类之后执行 3、添加@Activate注解，会自动激活（与默认过滤器一样？） 4、也可以不添加注解，自己在xml里配置，即自定义过滤器 <dubbo:service filter="aa,cc,vv" />为某个服务设置过滤器 <dubbo:provider filter="qq,ww,ee" />为所有提供者设置过滤器 5、提供端自定义过滤器的 key是service.filter 消...
Dubbo源码解析（六）Dubbo Protocol 以DubboProtocol为例
wuhulala的休息室
05-30 1438
Protocol 包括两个功能，发布服务和引用服务，所以就可以想到，应该是在Service发布和Reference引用的时候调用了此接口。也就是在ServiceBean、ReferenceBean初始化的时候，这一层也不复杂 代码如下 @SPI("dubbo") public interface Protocol { /** * Get default port whe...
Dubbo分析之Registry层
weixin_33800593的博客
12-21 596
前言 紧接上文Dubbo分析之Cluster层，本文继续分析dubbo的register层；此层封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory, Registry, RegistryService； Registry接口 接口定义如下： public interface Registry exten...
dubbo源码分析-dubboProtocol
linyuhe
11-06 1262
dubboProtocol是dubbo中的核心类，具体实现了
Dubbo笔记13——仅订阅，仅注册
占星安啦的博客
11-07 619
1.仅订阅 对于某服务来说，其可以发现和调用注册中心中的其它服务，但不能被其它服务发现和 调用，这种情形称为仅订阅。 简单说就是，仅可去发现，但不能被发现。 其底层的实现是，当前服务可以从注册中心下载注册列表，但其不会将自己的信息写入 到注册列表 <dubbo:registry address="127.0.0.1:8081" register="false"/> 2.仅注册 对于某...
dubbo下Dubbo协议注册中心 生产者暴露出服务 ServiceConfig下export方法理解注释
icool_ali的博客
06-15 2282
ServiceConfigpublic synchronized void export() { if (provider != null) {//生成者配置对象 if (export == null) { export = provider.getExport(); } if (delay == null) {//延...
Dubbo协议详解
Sail__的专栏
08-03 1097
协议的概念 协议是两个网络实体进行通信的基础，数据在网络上从一个实体传输到另一个实体，以字节流的形式传递到对端。在这个字节流的世界里，如果没有协议，就无法将这个一维的字节流重塑成为二维或者多维的数据结构以及领域对象。 协议是什么 协议是双方确定的交流语义，比如：我们设计一个字符串传输的协议，它允许客户端发送一个字符串，服务端接收到对应的字符 串。这个协议很简单，首先发送一个4字节的消息总长度...
服务治理中间件 Dubbo 原理解析(注册中心)读书笔记
icool_ali的博客
08-24 454
服务注册与发现的中心接口及参数介绍 服务的提供者将服务发布到注册中心，服务的使用着到 注册中引用服务。 Dubbo 的注册中心提供了多种实现，其实现是基于 dubbo 的 spi 的扩展机制的， 使用着可以直接实现自己的注册中心。 @SPI("dubbo") public interface RegistryFactory { /** * 连接注册中心. * 连接注册中心需处理契约 * 1. ...
【Dubbo】注册中心及原理
菜鸡也有大佬梦
05-10 1405
1 注册中心概述 在 Dubbo 微服务体系中 ， 注册中心是其核心组件之一 。 Dubbo 通过注册中心实现了分布式 环境中各服务之间的注册与发现 ， 是各个分布式节点之间的纽带 。 其主要作用如下 ： • 动态加入 。 一个服务提供者通过注册中心可以动态地把自己暴露给其他消费者 ， 无须 消费者逐个去更新配置文件 • 动态发现 。 一个消费者可以动态地感知新的配置 、 路由规则和新的服务提供者 ， 无须 重启服务使之生效 。 • 动态调整 。 注册中心支持参数的动态调整 ， 新参数自动更新到所有相关服务
Dubbo分层架构之服务注册中心层的源码分析(下)
吴就业
12-15 400
基于Redis实现的注册中心为什么不被推荐使用，你知道原因吗？由于我在实际项目中并未使用Redis作为服务注册中心，所以一直没有关注这个话题。那么，使用...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值