Soul网关源码分析-6期

最新推荐文章于 2021-02-19 21:29:17 发布
最新推荐文章于 2021-02-19 21:29:17 发布
阅读量266 收藏 1
点赞数
文章标签： 网关 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zm469568595/article/details/112855720
版权

文章目录


今日任务

  • AlibabaDubboPlugin 研究
  • ApacheDubboPlugin 研究



AlibabaDubboPlugin

将该启动的都开启, Mysql、Zookeeper、AlibabaDubbo服务、Soul-admin、Soul-bootstrap.

值得注意的是, 启动网关时打印了这几行日志:

2021-01-19 19:56:44.680  INFO 1623 --- [ctReadThread-37] o.d.s.p.a.d.c.ApplicationConfigCache     : init aliaba dubbo reference success there meteData is :MetaData(id=1350474912353136640, appName=dubbo, contextPath=null, path=/dubbo/insert, rpcType=dubbo, serviceName=org.dromara.soul.test.dubbo.api.service.DubboTestService, methodName=insert, parameterTypes=org.dromara.soul.test.dubbo.api.entity.DubboTest, rpcExt={"timeout":10000}, enabled=true)
2021-01-19 19:56:44.829  INFO 1623 --- [ctReadThread-37] o.d.s.p.a.d.c.ApplicationConfigCache     : init aliaba dubbo reference success there meteData is :MetaData(id=1350474914580312064, appName=dubbo, contextPath=null, path=/dubbo/findByIdsAndName, rpcType=dubbo, serviceName=org.dromara.soul.test.dubbo.api.service.DubboMultiParamService, methodName=findByIdsAndName, parameterTypes=java.util.List,java.lang.String, rpcExt={"timeout":10000}, enabled=true)

看着像服务信息缓存相关, 先记下 `ApplicationConfigCache` 这个类.

这次我们有了以前的经验, 直接找到 SoulWebHandler 的 execute() 方法, 看看调用的插件链长啥样:

plugins = {ArrayList@8953}  size = 12
 0 = {GlobalPlugin@8537} 
 1 = {WafPlugin@9085} 
 2 = {RateLimiterPlugin@9086} 
 3 = {HystrixPlugin@9087} 
 4 = {DividePlugin@9088} 
 5 = {WebClientPlugin@9089} 
 6 = {WebSocketPlugin@9090} 
 7 = {BodyParamPlugin@9091} 
 8 = {AlibabaDubboPlugin@9092} 
 9 = {MonitorPlugin@9093} 
 10 = {WebClientResponsePlugin@9094} 
 11 = {DubboResponsePlugin@9095}

比起简单的HTTP调用, 多了两个插件 BodyParamPlugin 、AlibabaDubboPlugin 、DubboResponsePlugin, 这两个应该就是 Dubbo 服务相关的插件了.

继续跑跑链调用, 像之前的老熟人 DividePlugin 、WebClientPlugin 、WebClientResponsePlugin 和 WebSocketPlugin 都直接跳过了, 能理解, 毕竟走的 RpcType 类型为 dubbo.


最后再关注下线程变动信息, 因为有服务调用肯定应该是要异步的, 这里不是在调用服务就是准备调用, 总之它不老实就是了:

在这里插入图片描述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CuZozXme-1611073192284)(images/image-20210119200644944.png)]

可以从以下截图看到, 插件调用在 BodyParamPlugin 到 AlibabaDubboPlugin 间线程发生变动, 看来 BodyParamPlugin 是关键的请求转发插件, 我们从它来开刀, 跟踪它的代码.

PS: 这里注意下, 此处 BodyParamPlugin 完整路径为: org.dromara.soul.plugin.alibaba.dubbo.param


public class BodyParamPlugin implements SoulPlugin {
	@Override
  public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
    final ServerHttpRequest request = exchange.getRequest();
    final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
    if (Objects.nonNull(soulContext) && RpcTypeEnum.DUBBO.getName().equals(soulContext.getRpcType())) {
      // 获取请求头的 contentType
      MediaType mediaType = request.getHeaders().getContentType();
      ServerRequest serverRequest = ServerRequest.create(exchange, messageReaders);
      return serverRequest.bodyToMono(String.class)
        .switchIfEmpty(Mono.defer(() ->
                                  // 切换线程了
                                  Mono.just(""))
                      )
        .flatMap(body -> {
          // 判断 contentType 是否 json, 是则将 body 信息注入上下文, 用 key 标识是 dubbo参数
          if (MediaType.APPLICATION_JSON.isCompatibleWith(mediaType)) {
            exchange.getAttributes().put(Constants.DUBBO_PARAMS, body);
          }
          // 继续链调用
          return chain.execute(exchange);
        });
    }
    return chain.execute(exchange);
  }
}

没看到关键的调用服务的信息, 继续看下个插件 AlibabaPlugin (仅保留关键代码).

public class AlibabaDubboPlugin extends AbstractSoulPlugin {

  @Override
  protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
    // 获取 BodyParamPlugin 注入的 body 参数
    String body = exchange.getAttribute(Constants.DUBBO_PARAMS);
    // 获取元数据信息(路径、rpcType等)
    MetaData metaData = exchange.getAttribute(Constants.META_DATA);
    // Dubbo服务调用
    Object result = alibabaDubboProxyService.genericInvoker(body, metaData);
    // ..
    exchange.getAttributes().put(Constants.DUBBO_RPC_RESULT, result);
    return chain.execute(exchange);
  }
}

看来 alibabaDubboProxyService.genericInvoker() 这句就是调用关键了, 追踪被调用的 AlibabaDubboProxyService (仅保留核心代码):

public class AlibabaDubboProxyService {
  
  public Object genericInvoker(final String body, final MetaData metaData) throws SoulException {
    // 这里是关键, 通过服务名在缓存中获得服务信息
    ReferenceConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getServiceName());
    GenericService genericService = reference.get();
    // ...
    return genericService.$invoke(metaData.getMethodName(), new String[]{}, new Object[]{});
  }
}

方法的第一句就是关键, debug看看是什么信息:

<dubbo:reference protocol="dubbo" interface="org.dromara.soul.test.dubbo.api.service.DubboTestService" uniqueServiceName="org.dromara.soul.test.dubbo.api.service.DubboTestService" generic="true" generic="true" timeout="10000" id="org.dromara.soul.test.dubbo.api.service.DubboTestService" />

这里直接从网关缓存里, 获得了dubbo服务的接口相关配置, 那这个缓存的数据又是怎么来的呢? 还记得启动网关时, 打印的日志信息么, 代码里也能看到 ApplicationConfigCache 的存在. 我们通过那个日志, 追溯下这个类的具体生成缓存的方法:

public final class ApplicationConfigCache {
  
	public ReferenceConfig<GenericService> build(final MetaData metaData) {
    ReferenceConfig<GenericService> reference = new ReferenceConfig<>();
    reference.setGeneric(true);
    reference.setApplication(applicationConfig);
    reference.setRegistry(registryConfig);
    reference.setInterface(metaData.getServiceName());
    reference.setProtocol("dubbo");
    // ...
    Object obj = reference.get();
    if (obj != null) {
      // 通过这行日志定位方法
      log.info("init aliaba dubbo reference success there meteData is :{}", metaData.toString());
      // 服务名称与信息放入缓存
      cache.put(metaData.getServiceName(), reference);
    }
    return reference;
  }
}

这里是加载缓存的地方, 那么这个方法是怎么被调用的? 追溯到 AlibabaDubboMetaDataSubscriber :

public class AlibabaDubboMetaDataSubscriber implements MetaDataSubscriber {
  private static final ConcurrentMap<String, MetaData> META_DATA = Maps.newConcurrentMap();

  @Override
  public void onSubscribe(final MetaData metaData) {
    if (RpcTypeEnum.DUBBO.getName().equals(metaData.getRpcType())) {
      // ...
      // 这个方法最终会调到 build()
      ApplicationConfigCache.getInstance().initRef(metaData);
      META_DATA.put(metaData.getPath(), metaData);
    }
  }
}

其实看到它的接口类 MetaDataSubscriber 就能知道个大概了, 这又是个实现了元数据更新订阅的类, 会接收 soul-admin 管理后台推送的元数据信息, 筛选出 RpcType 为 Dubbo 类型的元数据进行缓存更新.

@RequiredArgsConstructor
public class MetaDataHandler extends AbstractDataHandler<MetaData> {
    
  private final List<MetaDataSubscriber> metaDataSubscribers;

  @Override
  protected void doRefresh(final List<MetaData> dataList) {
    metaDataSubscribers.forEach(MetaDataSubscriber::refresh);
    // 遍历所有元数据更新订阅类
    dataList.forEach(metaData -> metaDataSubscribers.forEach(metaDataSubscriber -> metaDataSubscriber.onSubscribe(metaData)));
  }

  // ...
}

最终的调用 dubbo 服务的代码这里再贴下, 都是 Alibaba Dubbo 框架的内容了, 不深入分析:

public class AlibabaDubboProxyService {
  
	public Object genericInvoker(final String body, final MetaData metaData) throws SoulException {
  // ...
  GenericService genericService = reference.get();
    if (null == body || "".equals(body) || "{}".equals(body) || "null".equals(body)) {
      return genericService.$invoke(metaData.getMethodName(), new String[]{}, new Object[]{});
    } else {
      Pair<String[], Object[]> pair = dubboParamResolveService.buildParameter(body, metaData.getParameterTypes());
      return genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
    }
	}
}



ApacheDubboPlugin

开始分析 ApacheDubboPlugin 前, 先确认下 soul-bootstrap 网关的 pom.xml 文件, apache-dubbo相关的依赖是否启用, 尤其注意看 soul-spring-boot-starter-plugin-apache-dubbo 是否启用.

启动三个项目 soul-admin 、soul-bootstrap 、soul-test-apache-dubbo-service .


启动时报错 Duplicate key

打脸的是, 网关立马报了个错:

Caused by: java.lang.IllegalStateException: Duplicate key org.dromara.soul.plugin.apache.dubbo.handler.ApacheDubboPluginDataHandler@4e83a98
	...
	at org.dromara.soul.plugin.base.cache.CommonPluginDataSubscriber.<init>(CommonPluginDataSubscriber.java:46) ~[classes/:na]
	at org.dromara.soul.web.configuration.SoulConfiguration.pluginDataSubscriber(SoulConfiguration.java:97) ~[classes/:na]

不要紧张这些情况都是小case, 看到 CommonPluginDataSubscriber 这个类且看过我3期的分析文章 的同学, 应该会有种熟悉感… 不怕, 从头梳理下流程你就懂了.


首先 SoulConfiguration 配置类会加载一个叫做 pluginDataSubscriber 的 Bean, 用作插件数据的订阅, 当然订阅对象是后台管理系统:

public class SoulConfiguration {
	@Bean
  public PluginDataSubscriber pluginDataSubscriber(final ObjectProvider<List<PluginDataHandler>> pluginDataHandlerList) {
    return new CommonPluginDataSubscriber(pluginDataHandlerList.getIfAvailable(Collections::emptyList));
  }
}

这里的入参由来, 会借助 spring4.X 的机制获得所有父类为 PluginDataHandler 的实现类, 自然也会找到 CommonPluginDataSubscriber :

public class CommonPluginDataSubscriber implements PluginDataSubscriber {
	// ...
}

CommonPluginDataSubscriber 的构造器开始工作, 接收 pluginDataHandlerList 入参, 将这些 Bean 对象转换成一个缓存map:

private final Map<String, PluginDataHandler> handlerMap;

public CommonPluginDataSubscriber(final List<PluginDataHandler> pluginDataHandlerList) {
  // 异常问题就是此行
  this.handlerMap = pluginDataHandlerList.stream().collect(Collectors.toConcurrentMap(PluginDataHandler::pluginNamed, e -> e));
}

我们的异常就是在这里了, 构建hash时key重复了, 说明 pluginDataHandlerList 这个入参的 pluginName 属性有重复. 那么这个入参怎么来的呢? 自然是 spring注入的, 找到这些 Bean 即可.


答案就在我们网关中引入的 soul-spring-boot-starter-plugin-xx 项目中, 我现在不仅引入了 alibaba-dubbo , 也引入了 apache-dubbo , 这两个 PluginDataHandler 实现子类冲突了:

public class AlibabaDubboPluginDataHandler implements PluginDataHandler {

  @Override
  public String pluginNamed() {
    return PluginEnum.DUBBO.getName();
  }
}

public class ApacheDubboPluginDataHandler implements PluginDataHandler {
	@Override
  public String pluginNamed() {
    return PluginEnum.DUBBO.getName();
  }
}

怎么解决呢? 在网关中屏蔽调 soul-spring-boot-starter-plugin-alibaba-dubbo 这个依赖即可, 它的 AlibabaDubboPluginConfiguration 配置工厂不工作了自然不会有 AlibabaDubboPluginDataHandler 这个Bean了.

PS: 我挺想改了其中一个 pluginNamed() 返回值, 但鬼知道哪里会有这个枚举的使用, 不作死了.



正题

照旧找到 SoulWebHandler 的 execute() 方法, 看看调用的插件链长啥样:

plugins = {ArrayList@8948}  size = 11
 0 = {GlobalPlugin@8947} 
 1 = {WafPlugin@9160} 
 2 = {RateLimiterPlugin@9161} 
 3 = {DividePlugin@9162} 
 4 = {WebClientPlugin@9163} 
 5 = {WebSocketPlugin@9164} 
 6 = {BodyParamPlugin@9165} 
 7 = {ApacheDubboPlugin@9166} 
 8 = {MonitorPlugin@9167} 
 9 = {WebClientResponsePlugin@9168} 
 10 = {DubboResponsePlugin@9169}

注意: 这里的 BodyParamPlugin 完整路径 org.dromara.soul.plugin.apache.dubbo.param


除了把 BodyParamPlugin 、AlibabaDubboPlugin 换成 Apache包里的 BodyParamPlugin 、ApacheDubboPlugin , 就没啥区别了. 再具体看看 BodyParamPlugin 有什么不同:

public class BodyParamPlugin implements SoulPlugin {

  // .. 
  @Override
  public String named() {
    return "apache-dubbo-body-param";
  }
}

除了 named() 方法返回的字符串不一样, 没看出其他区别. 各种变量的类路径也都一样. 看看 ApacheDubboPlugin … 终于看出不一样了, 主要是调用的桩实现上不同 (仅保留核心代码):

public class ApacheDubboProxyService {

  public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
    // ...
    GenericService genericService = reference.get();
    Pair<String[], Object[]> pair = new ImmutablePair<>(new String[]{}, new Object[]{});
    // 使用 apache dubbo 的异步回调
    CompletableFuture<Object> future = genericService.$invokeAsync(metaData.getMethodName(), pair.getLeft(), pair.getRight());
    return Mono.fromFuture(future.thenApply(ret -> {
      if (Objects.nonNull(ret)) {
        exchange.getAttributes().put(Constants.DUBBO_RPC_RESULT, ret);
      } else {
        exchange.getAttributes().put(Constants.DUBBO_RPC_RESULT, Constants.DUBBO_RPC_RESULT_EMPTY);
      }
      exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.SUCCESS.getName());
      return ret;
    }));
  }
}

ApacheDubboPlugin 对服务的调用是异步回调的模型 $invokeAsync(), 不用阻塞线程等待结果. 而 AlibabaDubboPlugin 在这块的调用模型则是同步的 $invoke() .

这块我其实挺有疑惑的, 没研究过 Apache-dubbo 和 Alibaba-dubbo, 不太清楚为什么一个支持$invokeAsync() 而另一个仅支持 $invoke() . 今后会了解一二再出个番外篇.

Tureen
关注
Soul网关中的Apache Dubbo插件执行原理（一）
子夜的博客
01-29 182
在之前的文章中，我们体验过了Apache Dubbo插件执行流程，本篇文章是通过跟踪源码的方式来理解其中的执行原理。 在Soul网关中，Apache Dubbo插件负责将http协议转换成dubbo协议，设计到的插件有：BodyParamPlugin，ApacheDubboPlugin和DubboResponsePlugin。 BodyParamPlugin：负责将请求的json放到exchange属性中； ApacheDubboPlugin：使用Apache Dubbo进行请求的泛化调用并返回响应结果；
Apache ShenYu源码阅读系列-Dubbo插件
子夜的博客
05-26 1044
Apache ShenYu 是一个异步的，高性能的，跨语言的，响应式的 API 网关。 ShenYu 网关使用 dubbo 插件完成对 dubbo服务的调用。你可以查看官方文档 Dubbo快速开始 了解如何使用该插件。 本文基于shenyu-2.4.3版本进行源码分析，官网的介绍请参考 Dubbo服务接入 。 1. 服务注册 以官网提供的例子为例 shenyu-examples-dubbo 。 假如你的dubbo服务定义如下(spring-dubbo.xml)： <beans xmlns="h.
soul网关学习十之apache-dubbo插件的调用
Bo_java的博客
01-28 307
soul在处理对apache-dubbo的请求处理时会使用dubbo的泛化调用。主要流程如下； 1.在注册ApacheDubboPlugin时会注入ApacheDubboProxyService和DubboMultiParameterResolveServiceImpl ApacheDubboProxyService用于接收网关的请求再进行dubbo的泛化调用 DubboMultiParameterResolveServiceImpl用于处理请求参数，用于dubbo的泛化调用 加载metadata时如果有d
Soul 网关源码阅读之 apache dubbo plugin
rockpigL的博客
01-30 158
Soul 提供了 apache 和 alibaba 两种 dubbo 的支持。本篇先来看 apache dubbo 插件的源码。 ApacheDubboPlugin 插件类本身的代码非常简单，只是判断一些上下文需要的对象是否可以正常使用，又
Soul网关源码学习（8）- 代理转发入口 SoulWebHandler
curePony
01-23 410
前言 在前一篇文章《Soul网关源码学习（7）- 代理转发流程概览2》 中，我们理清楚了不同协议的代理转发流程，知道了每种协议处理的步骤和关键节点在哪里。那么现在就开始对这些节点逐个进入详细的分析，而 SoulWebHandler 作为 Request 的第一站自然就是我们首先要攻克的对象。 WebHandler 简介 在分析 SoulWebHandler 之前，我们需要先了解一下 WebHandler，因为 SoulWebHandler 是 WebHandler 的自定义实现。那 WebHandler
Soul网关源码分析-框架应用初体验
u013540630的博客
01-15 411
在上一篇中，我介绍了soul框架的概述、罗列了支持的功能、使用到的技术，并通过启动soul-admin模块和soul-bootstrap模块，通过管理控制台中展示的功能直观的感受了soul网关自带的丰富功能，这一篇，我们通过运行soul自带的例子程序soul-example模块中的soul-example-http，从使用者的角度体验soul是如何处理并转发http请求的 ...
Soul网关源码分析-http后台应用启动自动注册拦截规则信息到soul-admin
u013540630的博客
01-17 1203
按照计划，今天要从源码的角度分析soul是如何处理浏览器请求并找到真正要访问的后台服务，但计划赶不上变化，作为一名超级奶爸，只有深夜的时间真正属于自己，无法按计划完成今天任务了，但是还是坚持每天有所产出，那么今晚分析soul源码得到的结果是终于弄清楚了接入soul的springBoot应用启动时是如何将url的拦截规则信息注册到soul-admin管理控制台的。 首先将今天分析源码带着的问题先抛出来，我们在上一篇中就以使用者的角度体验了http请求通过soul成功转发到了后台，在后台工程soul-examp
Soul网关源码分析-请求从浏览器端如何通过soul转发到后台
u013540630的博客
01-19 858
在上一篇中，我分析了接入soul的springBoot应用，是如何在启动时将拦截规则同步到soul-admin的，那么在这一讲中，我们一起从源码的角度来看看一个web请求，是如何经过soul转发到后台的。 还是跟上一讲一样，我先把代码跟踪结果发出来，再来看看我是如何一步步得出这个结论的，通过跟踪代码梳理出来的流程如下图所示： ...
Soul网关源码分析-dubbo应用启动自动注册拦截规则信息到soul-admin
u013540630的博客
01-20 294
在上一篇中，我对http请求从浏览器端如何通过soul转发到后台的整个流程从源码的角度做了梳理，今天，将从源码的角度来分析一下，Dubbo应用接入soul后是如何做到在启动时将拦截规则信息自动注册到soul-admin中的。 首先，先大概讲一下一个dubbo应用接入soul应该要做哪些事情： 1、需修改 application.yaml 配置文件，添加 Soul 配置项如下： soul: dubbo: adminUrl: http://localhost:9095 contextPath
Soul网关源码分析-springCloud应用请求如何通过soul转发到后台
u013540630的博客
01-23 389
昨天以使用者的角度体验了springCloud工程接入soul后的转发处理效果，结果最终结果报错了，如下图： 那么今天我们就基于这个报错来分析一下源码，到底是哪个环节导致最终结果出错，从这种图的报错信息可以看到，是无法找到正确的选择器导致的报错，结合之前对http请求以及dubbo请求的分析经验，尝试从插件链的角度分析问题出现的原因，先在soul-admin管理控制台中查看目前的插件列表，因为之前调试过dubbo请求，所以目前dubbo和springCloud插件状态都是开启状态，所以怀疑是否是受到dub
dubbo springboot+dubbo泛化的使用，以及开发时直连本地的dubbo服务（dubbo指定点对点调用服务）
新林的博客
01-04 4094
一般情况我们使用dubbo通过rpc调用dubbo提供方的服务，首先要在消费者的项目中引入接口提供者的jar包（provider端暴露的接口和方法），然后使用jar包里面的类和方法，两端才能正常通信调用。但是如果要调N个不同服务提供者的接口，就要引入N个jar包，这时候消费者项目有N多个dubbo提供者的jar，项目耦合度就会很大。我们可以用dubbo的泛化实现调用dubbo服务，泛化调用不需要引入provider提供的jar即可实现远程调用，降低耦合。区别就在于参数和返回值中所有的POJO都用Map表示。
Dubbo配置引发的一个问题--- Duplicate spring bean id
weixin_33811961的博客
05-08 937
1.原因 因项目业务需要，要调用RPC框架，项目原本已经依赖了很多RPC接口需要启动时加载，所以准备做成启动时不预加载。 就是在配置的时候加上check=false. 官方文档解释的作用，就是Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认check="true"。 2. 好处 首先...
dubbo开发中遇到的坑
Mojito Blogs
03-20 2333
问题一:springaop事务和dubbo冲突解决办法第一步:&lt;dubbo:service interface="cn.yh.dubbo.service.StudentService" ref="studentServiceImpl"&gt;&lt;/dubbo:service&gt; &lt;bean id="studentServiceImpl" class="cn.yh.dubbo..
soul网关源码学习05-dubbo插件流程解析
m0_54065725的博客
01-19 140
soul网关源码学习05-插件源码解析02 目标： 梳理dubbo插件的调用过程 理解dubbo的泛化调用 一、启动项目 启动本地mysql数据库和zookeeper 启动soul-admin、soul-bootstrap、soul-example-apache-dubbo-service 二、源码解析 首先，还是按上一次讲的，在SoulWebHandler的handle方法打上断点。 public Mono<Void> handle(@NonNull final ServerWebEx
dubbo使用GenericService泛化调用
a490789580的博客
03-05 1万+
我们项目中常见场景，java应用内部接口都是使用dubbo，某个非java应用需要调用我们的接口的时候，无法使用dubbo，这是我们需要给它提供其他形式的接口，如restful api等等，这时我们需要为这个接口开发而增加额外的工作量。这时候就可以使用dubbo提供的GenericService来调用dubbo接口了，而使用GenericService调用接口的好处是不需要依赖服务提供方给的int...
java 泛化_Dubbo 泛化引用和泛化实现
weixin_42292855的博客
02-19 997
开篇在Dubbo官方文档中关于泛化调用和泛化实现的说明，这里针对文档的案例做一些简单的说明和解释。例子// 引用远程服务// 该实例很重量，里面封装了所有与注册中心及服务提供方连接，请缓存ReferenceConfig reference = new ReferenceConfig();reference.setApplication(new ApplicationConfig("dubbo-de...
手动调用指定Dubbo接口（三）----GenericService篇
lkforce
06-23 3430
我写了个方法，可以给方法传递指定的Dubbo接口名，方法名，参数值，方法来调用我们指定的Dubbo接口，并返回结果。 这次用的是Dubbo的GenericService。 示例代码： @Controller @RequestMapping("/test") public class TestController { /** * @param interfaceName Dubbo接口名 * @param methodName 方法名 * @para.
Soul网关源码学习（13）- Apache Dubbo 代理转发流程细解
curePony
01-29 407
文章目录前言BodyParamPluginApacheDubboPluginDubboResponsePlugin总结 前言 在前面第 8 ~ 12章中，我们深入分析了 Soul 关于 Http 的代理转发的底层实现，本篇我们开始分析 Apache Dubbo 的代理转发的是如何实现的。由于在前面的文章，我们已经分析了一些公有插件的实现，这里就不重复了，这里只针对 Apache Dubbo 代理的相关插件的实现进行分析。如果有小伙伴不明白不同协议代理之间一些流程上的共性，可以回去参考第6章和第7章。 Bod
SpringBoot整合dubbo详解(阿里官方dubbo-spring-boot-starter)
热门推荐
u011788183的博客
08-12 2万+
Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。 Dubbo 的RPC 调用流程主要涉及到4个模块...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值