Midnight ·

Soul源码阅读系列（七）Spring Cloud插件

17 May 2021 | Soul |

本篇文章主要介绍学习使用Spring Cloud插件，如何将Spring Cloud服务接入到Soul网关。主要内容如下：

在Soul中使用Spring Cloud服务
- 查看官方样例
- 引入依赖
- 注册Spring Cloud服务
- 运行Spring Cloud服务
- 启动Soul Admin和Soul Bootstrap
- 体验Spring Cloud服务
SpringCloudPlugin 源码解析

在前面几篇文章中，已经体验过了Soul中divide插件，apache dubbo插件和sofa插件，今天的Spring Cloud插件大体逻辑和之前的一致，接入和实现还会简单一些。

1. 在`Soul`中使用`spring cloud`服务

1.1 查看官方样例

Soul官方在soul-examples模块提供了测试样例，其中的soul-examples-springcloud模块演示的是Soul网关对springcloud服务的支持。模块目录及配置信息如下：

有关的配置信息还是和之前一样。在本项目中Spring Cloud的注册中心使用的是nacos。

nacos可以在官网直接下载，然后解压，在bin目录下使用命令startup.cmd -m standalone就能启动成功。

server:
  port: 8884
  address: 0.0.0.0

spring:
  application:
    name: springCloud-test
  cloud: 
    nacos:
      discovery:
          server-addr: 127.0.0.1:8848 # 注册中心nacos的地址


springCloud-test:
  ribbon.NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

soul:
  springcloud:
    admin-url: http://localhost:9095 # soul-admin的地址
    context-path: /springcloud

logging:
  level:
    root: info
    org.dromara.soul: debug
  path: "./logs"

1.2 引入依赖

在spring cloud服务的pom文件中引入soul相关依赖，当前版本是2.2.1。

	  <dependency>
            <groupId>org.dromara</groupId>
            <artifactId>soul-spring-boot-starter-client-springcloud</artifactId>
            <version>${soul.version}</version>
        </dependency>

	<!--使用nacos作为注册中心-->
       <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
            <version>2.1.0.RELEASE</version>
        </dependency>

1.3 注册`spring cloud`服务

在需要被代理的接口上使用注解@SoulSpringCloudClient，@SoulSpringCloudClient注解会把当前接口注册到soul网关中。使用方式如下：

如果其他接口也想被网关代理，使用方式是一样的。在@SoulSpringCloudClient注解中，指定path即可。

1.4 运行`spring cloud`服务

运行SoulTestSpringCloudApplication，启动soul-examples-springcloud项目。成功启动后，可以在控制台看见接口被成功注册到soul网关中。

1.5 启动`Soul Admin`和`Soul Bootstrap`

参考之前的文章，启动Soul Admin和Soul Bootstrap。Soul的后台界面如下：

如果spring cloud插件没有开启，需要手动在管理界面开启一下。

在Soul Bootstrap中，加入相关依赖：

         <dependency>
            <groupId>org.dromara</groupId>
            <artifactId>soul-spring-boot-starter-plugin-httpclient</artifactId>
            <version>${project.version}</version>
        </dependency>
	 <!--soul springCloud plugin start-->
        <dependency>
            <groupId>org.dromara</groupId>
            <artifactId>soul-spring-boot-starter-plugin-springcloud</artifactId>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-commons</artifactId>
            <version>2.2.0.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
            <version>2.2.0.RELEASE</version>
        </dependency>

        <!--soul springCloud plugin start end-->

httpclient插件也是需要的，在soul网关将http协议转换为spring cloud协议后，还需要通过httpclient插件发起web mvc请求。

提一句，当spring cloud服务和soul-bootstrap等启动成功后，可以在注册中心看到这两个服务实例。

1.6 体验`spring cloud`服务

三个系统（本身的业务系统(这里就是soul-examples-sofa)，Soul后台管理系统Soul Admin，Soul核心网关Soul Bootstrap）都启动成功后，就能够体验到sofa服务在网关soul中的接入。

先直连spring cloud服务

再通过Soul网关请求spring cloud服务

	 //实际spring cloud提供的服务
    @GetMapping("/findById")
    @SoulSpringCloudClient(path = "/findById")
    public OrderDTO findById(@RequestParam("id") final String id) {
        OrderDTO orderDTO = new OrderDTO();
        orderDTO.setId(id);
        orderDTO.setName("hello world spring cloud findById");
        return orderDTO;
    }

上面演示的是先通过请求http://localhost:8884/order/findById?id=99直连spring cloud服务。再通过Soul网关发起请求http://localhost:9195/springcloud/order/findById?id=99，实际被调用的是spring cloud的服务。

SpringCloudPlugin 源码解析

// org.dromara.soul.plugin.springcloud.SpringCloudPlugin#doExecute    
protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
       //是否匹配上规则    
       if (Objects.isNull(rule)) {
            return Mono.empty();
        }
        final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
        assert soulContext != null;
    //从缓存中获取选择器和规则信息
        final SpringCloudRuleHandle ruleHandle = SpringCloudRuleHandleCache.getInstance().obtainHandle(SpringCloudPluginDataHandler.getRuleCacheKey(rule));
        final SpringCloudSelectorHandle selectorHandle = SpringCloudSelectorHandleCache.getInstance().obtainHandle(selector.getId());
        if (StringUtils.isBlank(selectorHandle.getServiceId()) || StringUtils.isBlank(ruleHandle.getPath())) {
            Object error = SoulResultWrap.error(SoulResultEnum.CANNOT_CONFIG_SPRINGCLOUD_SERVICEID.getCode(), SoulResultEnum.CANNOT_CONFIG_SPRINGCLOUD_SERVICEID.getMsg(), null);
            return WebFluxResultUtils.result(exchange, error);
        }

    // 负载均衡选择实例
        final ServiceInstance serviceInstance = loadBalancer.choose(selectorHandle.getServiceId());
        if (Objects.isNull(serviceInstance)) {
            Object error = SoulResultWrap.error(SoulResultEnum.SPRINGCLOUD_SERVICEID_IS_ERROR.getCode(), SoulResultEnum.SPRINGCLOUD_SERVICEID_IS_ERROR.getMsg(), null);
            return WebFluxResultUtils.result(exchange, error);
        }
    //构建请求url
        final URI uri = loadBalancer.reconstructURI(serviceInstance, URI.create(soulContext.getRealUrl()));

        String realURL = buildRealURL(uri.toASCIIString(), soulContext.getHttpMethod(), exchange.getRequest().getURI().getQuery());

    //设置请求信息
        exchange.getAttributes().put(Constants.HTTP_URL, realURL);
        //set time out.
        exchange.getAttributes().put(Constants.HTTP_TIME_OUT, ruleHandle.getTimeout());
    //处理下一个插件   
    return chain.execute(exchange);
    }

由Spring Cloud构建的微服务是支持RESTful，可以通过http请求发起调用。

在SpringCloudPlugin中设置好请求信息后，就交给后续的插件处理的，是需要要开启divide插件。

小结，这篇文章主要介绍了Soul对spring cloud提供的支持，结合实际案例进行了演示，简单跟读了下源码。

Soul源码阅读系列（六）Sofa插件

15 May 2021 | Soul |

本篇文章主要介绍学习使用sofa插件，如何将sofa服务接入到Soul网关，以及sofa的简单介绍。主要内容如下：

在Soul中使用sofa服务
- 查看官方样例
- 引入依赖
- 注册sofa服务
- 运行sofa服务
- 启动Soul Admin和Soul Bootstrap
- 体验sofa服务
关于sofa
- sofa是什么
- sofa基本原理
Sofa插件执行原理
- BodyParamPlugin插件
- SofaPlugin插件
- SofaResponsePlugin插件
Sofa服务及代理对象的生成

今天体验的是Soul中sofa插件，如果业务系统是由sofa构建而成的，当需要Soul网关的支持时，可以将自己的sofa服务接入soul网关。

1. 在`Soul`中使用`sofa`服务

1.1 查看官方样例

Soul官方在soul-examples模块提供了测试样例，其中的soul-examples-sofa模块演示的是Soul网关对sofa服务的支持。模块目录及配置信息如下：

soul.sofa是有关Soul对sofa插件支持的配置，adminUrl是Soul的后台管理地址，contextPath是业务系统的请求路径上下文。

1.2 引入依赖

在sofa服务的pom文件中引入soul相关依赖，当前版本是2.2.1。

        <properties>
            <rpc-sofa-boot-starter.version>6.0.4</rpc-sofa-boot-starter.version>
        </properties>       
		<dependency>
            <groupId>com.alipay.sofa</groupId>
            <artifactId>rpc-sofa-boot-starter</artifactId>
            <version>${rpc-sofa-boot-starter.version}</version>
        </dependency>
 		<dependency>
            <groupId>org.dromara</groupId>
            <artifactId>soul-spring-boot-starter-client-sofa</artifactId>
            <version>${soul.version}</version>
            <exclusions>
                <exclusion>
                    <artifactId>guava</artifactId>
                    <groupId>com.google.guava</groupId>
                </exclusion>
            </exclusions>
        </dependency>

1.3 注册`sofa`服务

在需要被代理的接口上使用注解@SoulSofaClient，@SoulSofaClient注解会把当前接口注册到soul网关中。使用方式如下：

如果其他接口也想被网关代理，使用方式是一样的。在@SoulSofaClient注解中，指定path即可。

1.4 运行`sofa`服务

运行TestSofaApplication，启动soul-examples-sofa项目。sofa是需要注册中心的。本文使用的是zookeeper，启动也很简单。在官网下载，然后解压，直接运行zkServer.cmd就可以运行。

1.5 启动`Soul Admin`和`Soul Bootstrap`

参考上一篇的Soul入门，启动Soul Admin和Soul Bootstrap。Soul的后台界面如下：

如果sofa插件没有开启，需要手动在管理界面开启一下。

在Soul Bootstrap中，加入相关依赖：

 	<!--soul sofa plugin start-->
        <dependency>
           <groupId>com.alipay.sofa</groupId>
           <artifactId>sofa-rpc-all</artifactId>
           <version>5.7.6</version>
       </dependency>
       <dependency>
           <groupId>org.apache.curator</groupId>
           <artifactId>curator-client</artifactId>
           <version>4.0.1</version>
       </dependency>
       <dependency>
           <groupId>org.apache.curator</groupId>
           <artifactId>curator-framework</artifactId>
           <version>4.0.1</version>
       </dependency>
       <dependency>
           <groupId>org.apache.curator</groupId>
           <artifactId>curator-recipes</artifactId>
           <version>4.0.1</version>
       </dependency>
       <dependency>
           <groupId>org.dromara</groupId>
           <artifactId>soul-spring-boot-starter-plugin-sofa</artifactId>
                <!-- 当前版本是2.2.1-->
           <version>${project.version}</version>
       </dependency>
     <!-- soul  sofa plugin end-->

1.6 体验`sofa`服务

	 //实际sofa提供的服务
    @SoulSofaClient(path = "/findAll", desc = "Get all data")
    public DubboTest findAll() {
        DubboTest dubboTest = new DubboTest();
        dubboTest.setName("hello world Soul Sofa , findAll");
        dubboTest.setId(String.valueOf(new Random().nextInt()));
        return dubboTest;
    }

上面向网关发起了一个请求http://localhost:9195/sofa/findAll，实际被调用的是sofa的服务。

2. 关于`sofa`

2.1 sofa是什么

在之前，我还没有使用过sofa，这里直接引用了官方的介绍：

SOFARPC 是蚂蚁金服开源的一款基于 Java 实现的 RPC 服务框架，为应用之间提供远程服务调用能力，具有高可伸缩性，高容错性，目前蚂蚁金服所有的业务的相互间的 RPC 调用都是采用 SOFARPC。SOFARPC 为用户提供了负载均衡，流量转发，链路追踪，链路数据透传，故障剔除等功能。

SOFARPC 还支持不同的协议，目前包括 bolt，RESTful，dubbo，H2C 协议进行通信。其中 bolt 是蚂蚁金融服务集团开放的基于 Netty 开发的网络通信框架。

个人理解：sofa是一个轻量级的dubbo。

2.2 `sofa`基本原理

1. 当一个 SOFARPC 的应用启动的时候，如果发现当前应用需要发布 RPC 服务的话，那么 SOFARPC 会将这些服务注册到服务注册中心上。如图中 Service 指向 Registry。
1. 当引用这个服务的 SOFARPC 应用启动时，会从服务注册中心订阅到相应服务的元数据信息。服务注册中心收到订阅请求后，会将发布方的元数据列表实时推送给服务引用方。如图中 Registry 指向 Reference。
1. 当服务引用方拿到地址以后，就可以从中选取地址发起调用了。如图中 Reference 指向 Service。

上面主要内容是介绍了Soul对sofa提供的支持，结合实际案例进行了演示。给出了sofa的简单介绍。

3. `Sofa`插件执行原理

接下来就通过跟踪源码的方式来理解其中的执行原理。

在Soul网关中，Sofa插件负责将http协议转换成sofa协议，涉及到的插件有：BodyParamPlugin，SofaPlugin和SofaResponsePlugin。

BodyParamPlugin：负责将请求的json放到exchange属性中；
SofaPlugin：使用Sofa进行请求的泛化调用并返回响应结果；
SofaResponsePlugin：包装响应结果。

3.1 `BodyParamPlugin`插件

该插件在执行链路中是先执行的，负责处理请求类型，比如带有参数的application/json，不带参数的查询请求。

//org.dromara.soul.plugin.sofa.param.BodyParamPlugin#execute  
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
		//省略了其他代码
        if (Objects.nonNull(soulContext) && RpcTypeEnum.SOFA.getName().equals(soulContext.getRpcType())) {

            //处理json
            if (MediaType.APPLICATION_JSON.isCompatibleWith(mediaType)) {
                return body(exchange, serverRequest, chain);
            }
            //处理x-www-form-urlencoded
            if (MediaType.APPLICATION_FORM_URLENCODED.isCompatibleWith(mediaType)) {
                return formData(exchange, serverRequest, chain);
            }
            //处理查询
            return query(exchange, serverRequest, chain);
        }
        return chain.execute(exchange);
    }

3.2 `SofaPlugin`插件

完成SofaDubbo插件的核心处理逻辑：检查元数据 -->检查参数类型-->泛化调用。

//org.dromara.soul.plugin.sofa.SofaPlugin#doExecute
@Override
    protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
		//省略了其他代码
        //检查元数据
        if (!checkMetaData(metaData)) {
			//省略了其他代码
        }
        //检查参数类型
        if (StringUtils.isNoneBlank(metaData.getParameterTypes()) && StringUtils.isBlank(body)) {
           //省略了其他代码
        }
        //泛化调用
        final Mono<Object> result = sofaProxyService.genericInvoker(body, metaData, exchange);
        return result.then(chain.execute(exchange));
    }

genericInvoker()方法中参数分别是请求参数body，有关服务信息的metaData，包含web信息的exchange。这里面的主要操作是：

根据请求路径从缓存获取服务配置信息；
获取代理对象；
请求参数转化为sofa泛化参数；
sofa真正的泛化调用；
返回结果。

public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
    
    	//获取服务信息
        ConsumerConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
		//获取代理对象
        GenericService genericService = reference.refer();
   		 //请求参数转化为泛化调用的参数
        Pair<String[], Object[]> pair;
        if (null == body || "".equals(body) || "{}".equals(body) || "null".equals(body)) {
            pair = new ImmutablePair<>(new String[]{}, new Object[]{});
        } else {
            pair = sofaParamResolveService.buildParameter(body, metaData.getParameterTypes());
        }
    	//异步返回结果
        CompletableFuture<Object> future = new CompletableFuture<>();
    	//响应回调
        RpcInvokeContext.getContext().setResponseCallback(new SofaResponseCallback<Object>() {
            @Override
            public void onAppResponse(final Object o, final String s, final RequestBase requestBase) {
                future.complete(o);
            }

            @Override
            public void onAppException(final Throwable throwable, final String s, final RequestBase requestBase) {
                future.completeExceptionally(throwable);
            }

            @Override
            public void onSofaException(final SofaRpcException e, final String s, final RequestBase requestBase) {
                future.completeExceptionally(e);
            }
        });
    
    //真正的泛化调用
        genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
    //返回结果    
    return Mono.fromFuture(future.thenApply(ret -> {
            if (Objects.isNull(ret)) {
                ret = Constants.SOFA_RPC_RESULT_EMPTY;
            }
            exchange.getAttributes().put(Constants.SOFA_RPC_RESULT, ret);
            exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.SUCCESS.getName());
            return ret;
        })).onErrorMap(SoulException::new);
    }

真正的sofa泛化调用是genericService.$invoke()。到这里，SofaPlugin插件的主要工作就完了，后面就是返回结果。

3.3 `SofaResponsePlugin`插件

这个插件就是对结果再一次包装，处理错误信息和成功的结果信息。

//org.dromara.soul.plugin.sofa.response.SofaResponsePlugin#execute   
    @Override
    public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
        return chain.execute(exchange).then(Mono.defer(() -> {
            final Object result = exchange.getAttribute(Constants.SOFA_RPC_RESULT);
            //处理错误的信息
            if (Objects.isNull(result)) {
                Object error = SoulResultWrap.error(SoulResultEnum.SERVICE_RESULT_ERROR.getCode(), SoulResultEnum.SERVICE_RESULT_ERROR.getMsg(), null);
                return WebFluxResultUtils.result(exchange, error);
            }
            //处理成功的信息
            Object success = SoulResultWrap.success(SoulResultEnum.SUCCESS.getCode(), SoulResultEnum.SUCCESS.getMsg(), JsonUtils.removeClass(result));
            return WebFluxResultUtils.result(exchange, success);
        }));
    }

至此，就跟踪完了Soul网关中对Sofa插件处理的核心操作：接入sofa服务，将http访问协议转化为sofa协议，通过sofa的泛化调用获取真正的接口服务信息。

4. `Sofa`服务及代理对象的生成

最后，我们还需要想到的是：服务的配置信息是怎么来的？以及代理对象是怎么得到的？

本文的分析思路和之前的Apache Dubbo是一样的。

 public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
     //获取服务
        ConsumerConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
        if (Objects.isNull(reference) || StringUtils.isEmpty(reference.getInterfaceId())) {
            ApplicationConfigCache.getInstance().invalidate(metaData.getServiceName());
            reference = ApplicationConfigCache.getInstance().initRef(metaData);
        }
     	//获取代理对象
     GenericService genericService = reference.refer();
     
     //省略了其他代码
     
        genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
        return Mono.fromFuture(future.thenApply(ret -> {
            //省略了其他代码
        })).onErrorMap(SoulException::new);
    }

先说结论：服务配置信息的来源是soul-admin同步到网关。

整个流程涉及到的类和方法如下：

soul-admin端：

WebsocketCollector:onMessage()；
SyncDataServiceImpl:syncAll();
MetaDataService:syncData();

soul-bootstrap网关端：

SoulWebsocketClient: onMessage(),handleResult();
WebsocketDataHandler:executor();
AbstractDataHandler:handle();
MetaDataHandler:doRefresh();
SofaMetaDataSubscriber:onSubscribe();
ApplicationConfigCache:initRef(),build();

在本文的测试中，soul-admin端和soul-bootstrap网关端之间的数据同步是通过websocket进行。所以在网关启动的时候会进行数据同步操作。

在soul-bootstrap网关端前面几个类主要处理同步的数据类型，最终流转到ApplicationConfigCache，在这里面进行构建服务build()。

public ConsumerConfig<GenericService> build(final MetaData metaData) {
        ConsumerConfig<GenericService> reference = new ConsumerConfig<>();
        reference.setGeneric(true);
        reference.setApplication(applicationConfig);
        reference.setRegistry(registryConfig); //注册中心地址
        reference.setInterfaceId(metaData.getServiceName());
        reference.setProtocol(RpcConstants.PROTOCOL_TYPE_BOLT);
        reference.setInvokeType(RpcConstants.INVOKER_TYPE_CALLBACK);
        reference.setRepeatedReferLimit(-1);
        String rpcExt = metaData.getRpcExt();//元数据信息
        SofaParamExtInfo sofaParamExtInfo = GsonUtils.getInstance().fromJson(rpcExt, SofaParamExtInfo.class);
        if (Objects.nonNull(sofaParamExtInfo)) {
            if (StringUtils.isNoneBlank(sofaParamExtInfo.getLoadbalance())) {
                final String loadBalance = sofaParamExtInfo.getLoadbalance();
                reference.setLoadBalancer(buildLoadBalanceName(loadBalance));
            }
            Optional.ofNullable(sofaParamExtInfo.getTimeout()).ifPresent(reference::setTimeout);
            Optional.ofNullable(sofaParamExtInfo.getRetries()).ifPresent(reference::setRetries);
        }
  	  //从注册中心获取代理服务
        Object obj = reference.refer();
        if (obj != null) {
            log.info("init sofa reference success there meteData is :{}", metaData.toString());
            cache.put(metaData.getPath(), reference);//将服务信息放到cache中去
        }
        return reference;
    }

在同步过程中，将所有的元数据信息及注册中心的服务放到了cache中，在使用的时候，就会到这个cache中去拿。就是在文章开始的地方提到的泛化调用。

 public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
     //从缓存的cache中获取服务
        ConsumerConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
        if (Objects.isNull(reference) || StringUtils.isEmpty(reference.getInterfaceId())) {
            ApplicationConfigCache.getInstance().invalidate(metaData.getServiceName());
            reference = ApplicationConfigCache.getInstance().initRef(metaData);
        }
     	//获取代理对象
     GenericService genericService = reference.refer();
     
     //省略了其他代码
     
        genericService.$invoke(metaData.getMethodName(), pair.getLeft(), pair.getRight());
        return Mono.fromFuture(future.thenApply(ret -> {
            //省略了其他代码
        })).onErrorMap(SoulException::new);
    }

总结：本文结合实际案例演示了Soul网关是如何接入sofa服务，然后通过源码跟踪的方式分析了sofa泛化服务的调用流程，最后分析了Sofa插件里面的服务是如何被加载，包括服务的配置信息和代理对象的生成。

Soul源码阅读系列（五）Apache Dubbo插件

06 Apr 2021 | Soul |

今天体验的是Soul中apache dubbo插件，如果你的业务系统是由apache dubbo构建而成的，又需要网关的支持，那么可以直接使用Soul接入。

Apache Dubbo 插件的案例演示

Soul官方在soul-examples模块提供了测试样例，其中的soul-examples-apache-dubbo-service模块演示的是Soul网关对apache dubbo 系统的支持。模块目录及配置信息如下：

soul.dubbo是有关Soul对dubbo插件支持的配置，adminUrl是Soul的后台管理地址，contextPath是业务系统的请求路径。

在项目的pom文件中引入soul相关依赖，当前版本是2.2.1。

        <dependency>
            <groupId>org.dromara</groupId>
            <artifactId>soul-spring-boot-starter-client-apache-dubbo</artifactId>
            <version>${soul.version}</version>
        </dependency>

在需要被代理的接口上使用注解@SoulDubboClient，@SoulDubboClient注解会把当前接口注册到soul网关中。使用方式如下：

如果其他接口也想被网关代理，使用方式是一样的。在@SoulDubboClient注解中，指定path即可。

运行TestApacheDubboApplication，启动soul-examples-apache-dubbo-service项目。Dubbo是需要注册中心的，可以使用zookeeper或者nacos。本文使用的是zookeeper，启动也很简单。在官网下载，然后解压，直接运行zkServer.cmd就可以运行。

参考之前的文章，启动Soul Admin和Soul Bootstrap。Soul的后台界面如下：

如果dubbo插件没有开启，那就需要手动去开启。

在Soul Bootstrap中，加入相关依赖：

 <!--soul  apache dubbo plugin start-->
        <dependency>
            <groupId>org.dromara</groupId>
            <artifactId>soul-spring-boot-starter-plugin-apache-dubbo</artifactId>
            <version>${project.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.dubbo</groupId>
            <artifactId>dubbo</artifactId>
            <version>2.7.5</version>
        </dependency>
        <!-- Dubbo zookeeper registry dependency start -->
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-client</artifactId>
            <version>4.0.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>4.0.1</version>
        </dependency>
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>4.0.1</version>
        </dependency>
        <!-- Dubbo zookeeper registry dependency end -->
        <!-- soul  apache dubbo plugin end-->

三个系统（本身的业务系统(这里就是soul-examples-apache-dubbo-service)，Soul后台管理系统Soul Admin，Soul核心网关Soul Bootstrap）都启动成功后，就可以进行测试了。

	 //实际dubbo提供的服务
    @SoulDubboClient(path = "/findAll", desc = "Get all data")
    public DubboTest findAll() {
        DubboTest dubboTest = new DubboTest();
        dubboTest.setName("hello world Soul Apache, findAll");
        dubboTest.setId(String.valueOf(new Random().nextInt()));
        return dubboTest;
    }

上面向网关发起了一个请求http://localhost:9195/dubbo/findAll，实际被调用的是dubbo的服务。

另外也可以发起一个POST请求，下面向网关发起了一个请求http://localhost:9195/dubbo/insert，实际被调用的是dubbo的服务。

//实际dubbo提供的服务
@SoulDubboClient(path = "/insert", desc = "Insert a row of data")
public DubboTest insert(final DubboTest dubboTest) {
    dubboTest.setName("hello world Soul Apache Dubbo: " + dubboTest.getName());
    return dubboTest;
}

到这，就演示完了Soul对Apache Dubbo提供的支持，接下来再看看实际执行的过程。

Apache Dubbo 插件执行原理

在Soul网关中，Apache Dubbo插件负责将http协议转换成dubbo协议，涉及到的插件有：BodyParamPlugin，ApacheDubboPlugin和DubboResponsePlugin。

BodyParamPlugin：负责将请求的json放到exchange属性中；
ApacheDubboPlugin：使用Apache Dubbo进行请求的泛化调用并返回响应结果；
DubboResponsePlugin：包装响应结果。

`BodyParamPlugin`插件

该插件在执行链路中是最先执行的，负责处理请求类型，比如带有参数的application/json，不带参数的查询请求。

//org.dromara.soul.plugin.apache.dubbo.param.BodyParamPlugin#execute   
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
        //省略了其他代码
        if (Objects.nonNull(soulContext) && RpcTypeEnum.DUBBO.getName().equals(soulContext.getRpcType())) {
           //省略了其他代码
            //处理application/json
            if (MediaType.APPLICATION_JSON.isCompatibleWith(mediaType)) {
                return body(exchange, serverRequest, chain);
            }
            //处理application/x-www-form-urlencoded
            if (MediaType.APPLICATION_FORM_URLENCODED.isCompatibleWith(mediaType)) {
                return formData(exchange, serverRequest, chain);
            }
            //处理查询请求
            return query(exchange, serverRequest, chain);
        }
        return chain.execute(exchange);
    }

`ApacheDubboPlugin`插件

完成ApacheDubbo插件的核心处理逻辑：检查元数据 -->检查参数类型-->泛化调用。

//org.dromara.soul.plugin.apache.dubbo.ApacheDubboPlugin#doExecute 
@Override
    protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
        String body = exchange.getAttribute(Constants.DUBBO_PARAMS);
        SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
        assert soulContext != null;
        MetaData metaData = exchange.getAttribute(Constants.META_DATA);
        //检查元数据
        if (!checkMetaData(metaData)) {
			//省略了其他代码
        }
        //检查参数类型
        if (StringUtils.isNoneBlank(metaData.getParameterTypes()) && StringUtils.isBlank(body)) {
            exchange.getResponse().setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR);
            Object error = SoulResultWrap.error(SoulResultEnum.DUBBO_HAVE_BODY_PARAM.getCode(), SoulResultEnum.DUBBO_HAVE_BODY_PARAM.getMsg(), null);
            return WebFluxResultUtils.result(exchange, error);
        }
        //泛化调用
        final Mono<Object> result = dubboProxyService.genericInvoker(body, metaData, exchange);
        //执行下一个插件
        return result.then(chain.execute(exchange));
    }

genericInvoker()方法中参数分别是请求参数body，有关服务信息的metaData，包含web信息的exchange。这里面的主要操作是：

根据请求路径从缓存获取服务配置信息；
获取代理对象；
请求参数转化为dubbo泛化参数；
apache dubbo真正的泛化调用；
返回结果。

public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
		//省略了其他代码
   	   //根据请求路径从缓存获取服务配置信息
        ReferenceConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());

   		 //获取代理对象
        GenericService genericService = reference.get();
    	//请求参数转化为dubbo泛化参数
        Pair<String[], Object[]> pair;
        if (ParamCheckUtils.dubboBodyIsEmpty(body)) {
            pair = new ImmutablePair<>(new String[]{}, new Object[]{});
        } else {
            pair = dubboParamResolveService.buildParameter(body, metaData.getParameterTypes());
        }
     
    	//apache dubbo真正的泛化调用，注意这里是异步的泛化调用
        CompletableFuture<Object> future = genericService.$invokeAsync(metaData.getMethodName(), pair.getLeft(), pair.getRight());
    
    //返回结果
        return Mono.fromFuture(future.thenApply(ret -> {
            if (Objects.isNull(ret)) {
                ret = Constants.DUBBO_RPC_RESULT_EMPTY;
            }
            exchange.getAttributes().put(Constants.DUBBO_RPC_RESULT, ret);
            exchange.getAttributes().put(Constants.CLIENT_RESPONSE_RESULT_TYPE, ResultEnum.SUCCESS.getName());
            return ret;
        }))//省略了其他代码
    }

代码中reference的信息如下，这里明确可以看出是dubbo协议，有接口名称，超时时间，重试次数，负载均衡等信息。

<dubbo:reference protocol="dubbo" prefix="dubbo.reference.org.dromara.soul.examples.dubbo.api.service.DubboTestService" uniqueServiceName="org.dromara.soul.examples.dubbo.api.service.DubboTestService" interface="org.dromara.soul.examples.dubbo.api.service.DubboTestService" generic="true" generic="true" sticky="false" timeout="10000" retries="2" loadbalance="random" id="org.dromara.soul.examples.dubbo.api.service.DubboTestService" valid="true" />

代码中genericService对象信息如下，他是一个代理对象，接口信息是从zookeeper中拿到的（在项目演示时用zookeeper作为注册中心）。

invoker :interface org.apache.dubbo.rpc.service.GenericService -> zookeeper://localhost:2181/org.apache.dubbo.registry.RegistryService?anyhost=true&application=soul_proxy&check=false&deprecated=false&dubbo=2.0.2&dynamic=true&generic=true&interface=org.dromara.soul.examples.dubbo.api.service.DubboTestService&loadbalance=random&methods=findById,insert,findAll&pid=22548&protocol=dubbo&register.ip=192.168.236.60&release=2.7.5&remote.application=test-dubbo-service&retries=2&side=consumer&sticky=false&timeout=10000&timestamp=1611918837429,directory: org.apache.dubbo.registry.integration.RegistryDirectory@46066629

真正的apache dubbo泛化调是genericService.$invokeAsync()，注意这里是异步的泛化调用。到这里，ApacheDubboPlugin插件的主要工作就完了，后面就是返回结果。

`DubboResponsePlugin`插件

这个插件就是对结果再一次包装，处理错误信息和成功的结果信息。

//org.dromara.soul.plugin.apache.dubbo.response.DubboResponsePlugin#execute    
@Override
    public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
        return chain.execute(exchange).then(Mono.defer(() -> {
            final Object result = exchange.getAttribute(Constants.DUBBO_RPC_RESULT);
            //错误信息
            if (Objects.isNull(result)) {
                Object error = SoulResultWrap.error(SoulResultEnum.SERVICE_RESULT_ERROR.getCode(), SoulResultEnum.SERVICE_RESULT_ERROR.getMsg(), null);
                return WebFluxResultUtils.result(exchange, error);
            }
            //成功信息
            Object success = SoulResultWrap.success(SoulResultEnum.SUCCESS.getCode(), SoulResultEnum.SUCCESS.getMsg(), JsonUtils.removeClass(result));
            return WebFluxResultUtils.result(exchange, success);
        }));
    }

至此，就跟踪完了Soul网关中对Apache Dubbo插件处理的核心操作：接入dubbo服务，将http访问协议转化为dubbo协议，通过dubbo的泛化调用获取真正的接口服务信息。

Apache Dubbo 服务来源

在前面，我们通过跟踪源码的方式理解了Apache Dubbo插件的执行原理，将发起的http请求转化为dubbo的泛化调用，但是有个关键的地方没有展开讲：就是服务的配置信息是怎么来的？以及代理对象是怎么得到的？

public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
        // 省略了其他代码

    	//获取服务配置
        ReferenceConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
		//获得代理对象
        GenericService genericService = reference.get();

    }

接下来我们就来解决这个问题。先说结论：服务配置信息的来源是soul-admin同步到网关。

整个流程涉及到的类和方法如下：

soul-admin端：

WebsocketCollector:onMessage()；
SyncDataServiceImpl:syncAll();
MetaDataService:syncData();

soul-bootstrap网关端：

SoulWebsocketClient: onMessage(),handleResult();
WebsocketDataHandler:executor();
AbstractDataHandler:handle();
MetaDataHandler:doRefresh();
ApacheDubboMetaDataSubscriber:onSubscribe();
ApplicationConfigCache:initRef(),build();

在接下来的的测试中，soul-admin端和soul-bootstrap网关端之间的数据同步是通过websocket进行。所以在网关启动的时候会进行数据同步操作。

在soul-bootstrap网关端前面几个类主要处理同步的数据类型，最终流转到ApplicationConfigCache，在这里面进行构建服务build()。

public ReferenceConfig<GenericService> build(final MetaData metaData) {
    //构建服务
    ReferenceConfig<GenericService> reference = new ReferenceConfig<>(); 
    //进行泛化调用   
    reference.setGeneric(true);
    //设置应用配置信息
    reference.setApplication(applicationConfig);
    //注册地址，比如zk  
    reference.setRegistry(registryConfig); 
    //接口信息名称
    reference.setInterface(metaData.getServiceName());
    //dubbo协议
    reference.setProtocol("dubbo");
    //其他信息
    String rpcExt = metaData.getRpcExt();
    DubboParamExtInfo dubboParamExtInfo = GsonUtils.getInstance().fromJson(rpcExt, DubboParamExtInfo.class);
        if (Objects.nonNull(dubboParamExtInfo)) {
            //版本
            if (StringUtils.isNoneBlank(dubboParamExtInfo.getVersion())) {
                reference.setVersion(dubboParamExtInfo.getVersion()); 
            }
            //分组
            if (StringUtils.isNoneBlank(dubboParamExtInfo.getGroup())) {
                reference.setGroup(dubboParamExtInfo.getGroup());
            }
            //负载均衡
            if (StringUtils.isNoneBlank(dubboParamExtInfo.getLoadbalance())) {
                final String loadBalance = dubboParamExtInfo.getLoadbalance();
                reference.setLoadbalance(buildLoadBalanceName(loadBalance)); 
            }
            //url
            if (StringUtils.isNoneBlank(dubboParamExtInfo.getUrl())) {
                reference.setUrl(dubboParamExtInfo.getUrl());
            }
            //超时和重试
            Optional.ofNullable(dubboParamExtInfo.getTimeout()).ifPresent(reference::setTimeout);
            Optional.ofNullable(dubboParamExtInfo.getRetries()).ifPresent(reference::setRetries);
        }
        try {
            //从注册中心中获得代理
            Object obj = reference.get(); 
            if (obj != null) {
                log.info("init apache dubbo reference success there meteData is :{}", metaData.toString());
                //放到cache缓存中，后面真正使用的时候就可从缓存中获取，而不是再去通过网络请求信息
                cache.put(metaData.getPath(), reference); 
            }
        } catch (Exception e) {
            log.error("init apache dubbo reference ex:{}", e.getMessage());
        }
        return reference;
    }

一个reference的信息如下：包括协议，服务接口，超时时间，负载均衡算法，重试次数。

<dubbo:reference protocol="dubbo" prefix="dubbo.reference.org.dromara.soul.examples.dubbo.api.service.DubboMultiParamService" uniqueServiceName="org.dromara.soul.examples.dubbo.api.service.DubboMultiParamService" interface="org.dromara.soul.examples.dubbo.api.service.DubboMultiParamService" generic="true" generic="true" sticky="false" loadbalance="random" retries="2" timeout="10000" id="org.dromara.soul.examples.dubbo.api.service.DubboMultiParamService" valid="true" />

一个代理对象信息如下：接口信息，注册中心地址等等其他详细信息。

invoker :interface org.apache.dubbo.rpc.service.GenericService -> zookeeper://localhost:2181/org.apache.dubbo.registry.RegistryService?anyhost=true&application=soul_proxy&check=false&deprecated=false&dubbo=2.0.2&dynamic=true&generic=true&interface=org.dromara.soul.examples.dubbo.api.service.DubboMultiParamService&loadbalance=random&methods=batchSave,findByArrayIdsAndName,findByListId,batchSaveAndNameAndId,findByIdsAndName,saveComplexBeanTestAndName,saveComplexBeanTest,findByStringArray&pid=23576&protocol=dubbo&register.ip=192.168.236.60&release=2.7.5&remote.application=test-dubbo-service&retries=2&side=consumer&sticky=false&timeout=10000&timestamp=1612011330405,directory: org.apache.dubbo.registry.integration.RegistryDirectory@406951e0

//org.dromara.soul.plugin.apache.dubbo.proxy.ApacheDubboProxyService#genericInvoker
public Mono<Object> genericInvoker(final String body, final MetaData metaData, final ServerWebExchange exchange) throws SoulException {
        // 省略了其他代码

    	//从cache中获取服务配置
        ReferenceConfig<GenericService> reference = ApplicationConfigCache.getInstance().get(metaData.getPath());
		//获得代理对象，这个对象就是在同步过程中保存的代理对象
        GenericService genericService = reference.get();

    }

现在就清楚来了Soul网关中Apache Dubbo插件里面的服务是如何被加载的，包括服务的配置信息和代理对象的生成。

小结，本文通过实际的案例演示了Soul网关Apache Dubbo的支持，并且通过跟踪源码的方式明白了Apache Dubbo插件执行的原理以及服务注册和使用的过程。

Older Newer

Midnight

Soul源码阅读系列（七）Spring Cloud插件

1. 在Soul中使用spring cloud服务

1.1 查看官方样例

1.2 引入依赖

1.3 注册spring cloud服务

1.4 运行spring cloud服务

1.5 启动Soul Admin和Soul Bootstrap

1.6 体验spring cloud服务

SpringCloudPlugin 源码解析

Soul源码阅读系列（六）Sofa插件

1. 在Soul中使用sofa服务

1.1 查看官方样例

1.2 引入依赖

1.3 注册sofa服务

1.4 运行sofa服务

1.5 启动Soul Admin和Soul Bootstrap

1.6 体验sofa服务

2. 关于sofa

2.1 sofa是什么

2.2 sofa基本原理

3. Sofa插件执行原理

3.1 BodyParamPlugin插件

3.2 SofaPlugin插件

3.3 SofaResponsePlugin插件

4. Sofa服务及代理对象的生成

Soul源码阅读系列（五）Apache Dubbo插件

Apache Dubbo 插件的案例演示

Apache Dubbo 插件执行原理

BodyParamPlugin插件

ApacheDubboPlugin插件

DubboResponsePlugin插件

Apache Dubbo 服务来源

1. 在`Soul`中使用`spring cloud`服务

1.3 注册`spring cloud`服务

1.4 运行`spring cloud`服务

1.5 启动`Soul Admin`和`Soul Bootstrap`

1.6 体验`spring cloud`服务

1. 在`Soul`中使用`sofa`服务

1.3 注册`sofa`服务

1.4 运行`sofa`服务

1.5 启动`Soul Admin`和`Soul Bootstrap`

1.6 体验`sofa`服务

2. 关于`sofa`

2.2 `sofa`基本原理

3. `Sofa`插件执行原理

3.1 `BodyParamPlugin`插件

3.2 `SofaPlugin`插件

3.3 `SofaResponsePlugin`插件

4. `Sofa`服务及代理对象的生成

`BodyParamPlugin`插件

`ApacheDubboPlugin`插件

`DubboResponsePlugin`插件