亲宝软件园·资讯

展开

SpringCloudAlibaba整合Dubbo 使用SpringCloudAlibaba整合Dubbo

user2025 人气:0
想了解使用SpringCloudAlibaba整合Dubbo的相关内容吗,user2025在本文为您仔细讲解SpringCloudAlibaba整合Dubbo的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:SpringCloudAlibaba,SpringCloudAlibaba整合Dubbo,下面大家一起来学习吧。

SpringCloudAlibaba整合Dubbo

Spring Cloud是一套较为完整的架构方案,而Dubbo只是服务治理与RPC实现方案。

Dubbo的注册中心采用了ZooKeeper,而Spring Cloud体系中的注册中心并不支持ZooKeeper。直到Spring Cloud Alibaba的出现,才得以解决这样的问题,Spring Cloud Alibaba中的Nacos来作为服务注册中心,并且在此之下可以如传统的Spring Cloud应用一样地使用Ribbon或Feign来实现服务消费,并提供了Spring Cloud Alibaba下额外支持的RPC方案:Dubbo

构建服务接口

public interface HelloService {
    String hello(String name);
}

构建服务接口提供方

(1)创建一个Spring Boot项目,在pom.xml中引入第一步中构建的API包以及Spring Cloud Alibaba对Nacos和Dubbo的依赖

<dependency>
     <groupId>top.onething</groupId>
     <artifactId>product-api</artifactId>
     <version>1.0-SNAPSHOT</version>
 </dependency>
 <dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
     <version>2.2.1.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-web</artifactId>
     <version>2.2.5.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
     <version>2.2.1.RELEASE</version>
 </dependency>
 <dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-dubbo</artifactId>
     <version>2.2.1.RELEASE</version>
 </dependency>
 <!--Dubbo Spring Cloud基于Spring Cloud Commons开发的,org.apache.http.client.HttpClient类确实存在于旧版本的httpclient中,
 
 但是它使用内部的org.apache.http.impl.client.HttpClientBuilder类在新版本中却不存在-->
 
 <dependency>
     <groupId>org.apache.httpcomponents</groupId>
     <artifactId>httpclient</artifactId>
     <version>4.5.4</version>
     <scope>compile</scope>
 </dependency>

spring-cloud-starter-dubbo基于spring-cloud-starter-commons开发的,org.apache.http.client.HttpClient类确实存在于旧版本的httpclient中,但是它使用内部的org.apache.http.impl.client.HttpClientBuilder类在新版本中却不存在。如果类路径上没有HttpClient,则HttpClientConfiguration自动配置将失败 HttpClientConfiguration的自动配置因对HttpClient的旧依赖性而失败,异常如下所示:

java.lang.IllegalStateException: Error processing condition on org.springframework.cloud.commons.httpclient.HttpClientConfiguration$ApacheHttpClientConfiguration.apacheHttpClientBuilder
Caused by: java.lang.ClassNotFoundException: org.apache.http.impl.client.HttpClientBuilder

(2)实现Dubbo接口

@Service
public class HelloServiceImpl implements HelloService {
    @Override
    public String hello(String name) {
        return "hello " + name;
    }
}

注意:@Service注解不是Spring的,而是dubbo的,完全限定名为:org.apache.dubbo.config.annotation.Service

(3)配置Dubbo服务相关的信息

配置说明如下:

spring:
  application:
    name: dubbo-consumer
  cloud:
    nacos:
      discovery:
        server-addr: www.onething.top:8848  # nacos服务注册中心的地址
        cluster-name: consumer-cluster  #集群名称
        namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a  #命名空间
      config:
        server-addr: www.onething.top:8848  # nacos配置中心地址
        namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a
        file-extension: yaml  #配置文件的后缀名
        refresh-enabled: true  #默认true:自动刷新
dubbo:
  protocol:    #Dubbo 服务暴露的协议配置,其中子属性 name 为协议名称,port 为协议端口( -1 表示自增端口,从 20880 开始)
    name: dubbo
    port: -1  #dubbo协议缺省端口为20880,rmi协议缺省端口为1099,http和hessian协议缺省端口为80;如果没有配置port,则自动采用默认端口,如果配置为-1,则会分配一个没有被占用的端口。Dubbo 2.4.0+,分配的端口在协议缺省端口的基础上增长,确保端口段可控
  registry:
    #dubbo服务注册端口,注册中心服务器地址,如果地址没有端口缺省为9090,同一集群内的多个地址用逗号分隔,如:ip:port,ip:port
    #其中前缀spring-cloud说明:挂载到 Spring Cloud注册中心
    address: spring-cloud://www.onething.top:8848
    #check: false  #关闭注册中心是否启动的相关检查,false表示不检查注册中心是否启动,就不会报错
  cloud:
    subscribed-services: dubbo-product
  consumer:
    check: false  #关闭订阅服务是否启动的检查【检查时,没有服务提供者会报错】

注意:如果使用Spring Boot 2.1及更高版本时候,需要增加配置spring.main.allow-bean-definition-overriding=true

(4)创建应用主类

@EnableDiscoveryClient【此注解可以省略】
@SpringBootApplication
public class DubboServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(DubboServerApplication.class, args);
    }
}

构建服务接口消费方法

(1)创建一个Spring Boot项目,在pom.xml中引入第一步中构建的API包以及Spring Cloud Alibaba对Nacos和Dubbo的依赖,具体内容与服务提供方一致

 <dependencies>
   <dependency>
        <groupId>top.onething</groupId>
        <artifactId>product-api</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        <version>2.2.1.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.2.5.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        <version>2.2.1.RELEASE</version>
    </dependency>
    <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
        <version>2.2.1.RELEASE</version>
    </dependency>
</dependencies>

(2)配置Dubbo服务相关的信息

spring:
  application:
    name: dubbo-consumer
  cloud:
    nacos:
      discovery:
        server-addr: www.onething.top:8848  # nacos服务注册中心的地址
        cluster-name: consumer-cluster  #集群名称
        namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a  #命名空间
      config:
        server-addr: www.onething.top:8848  # nacos配置中心地址
        namespace: b7ef9579-df75-41c2-8a95-e04aa03c273a
        group: test-group
        file-extension: yaml  #配置文件的后缀名
dubbo:
  protocol:    #Dubbo 服务暴露的协议配置,其中子属性 name 为协议名称,port 为协议端口( -1 表示自增端口,从 20880 开始)
    name: dubbo
    port: -1  #dubbo协议缺省端口为20880,rmi协议缺省端口为1099,http和hessian协议缺省端口为80;如果没有配置port,则自动采用默认端口,如果配置为-1,则会分配一个没有被占用的端口。Dubbo 2.4.0+,分配的端口在协议缺省端口的基础上增长,确保端口段可控
  registry:
    #其中前缀spring-cloud说明:挂载到 Spring Cloud注册中心
    address: spring-cloud://www.onething.top:8848  #dubbo服务注册端口,注册中心服务器地址,如果地址没有端口缺省为9090,同一集群内的多个地址用逗号分隔,如:ip:port,ip:port
  cloud:
    subscribed-services: dubbo-product

(3)创建应用主类,并实现一个接口,在这个接口中调用Dubbo服务

@EnableDiscoveryClient
@SpringBootApplication
@RestController
public class DubboClientApplication {
 @Reference
 HelloService helloService;
   
    public static void main(String[] args) {
        SpringApplication.run(DubboClientApplication.class, args);
    }
    @GetMapping("/test")
    public String test() {
        return helloService.hello("didispace.com");
    }
}

注意:这里的@Reference注解是org.apache.dubbo.config.annotation.Reference

SpringCloudAlibaba之Dubbo总结

GitHub地址:https://github.com/apache/dubbo

Dubbo的故事比较长了,Demo中也有调用的示例,所以示例就不补充了,我的gitee仓库上也有一些可参考的示例。目前在这里就只针对目前的最新版本2.7.7,做一点总结把。

另外,关于Dubbo,出来这么多年了,很多人更关注Dubbo的动态代理、底层Netty协议等一些问题。但是我觉得,其实更应该关注的是Dubbo在服务调用这个场景中做到了哪些,想到了哪些,这些应该是比手写Dubbo更有价值的地方。这中间的关系就像架构师跟程序员之间的差距,并不是架构师代码就写得就比程序员好,而是架构师能考虑到各种情况,组合成系统化解决实际问题的解决方案。

Dubbo概述

官网的特性描述:

Dubbo架构图

这个图可以看到Dubbo的各角色职责,Registery负责服务发现与注册,Provider往Registry上注册服务信息,Consumer订阅Registry上的服务信息,Registry会及时向Consumer进行推送。然后Consumer从服务列表中选择一个Provider,进行服务调用。

Dubbo配置方式

Dubbo的服务有三种配置方式,API方式、基于Spring的XML方式和基于SpringBoot的Properties方式。三种方式的服务配置在Demo工程中都有实现,就不多说了。这里要记录一下的,是各种配置的优先级。

三种配置方式之间的关系

显而易见,API方式其实已经不是服务化的配置方式了,是底层的实现方式,展示的是如何将Dubbo的几个核心对象组装成服务。正常情况下也是不太会用得到的,只是在一些脱离Spring的环境中可以偶尔强行用一下,比如MapReduce、spark计算等一些情况可以强行用上一点。

而后两种配置方式,其实效果是等价的。例如 dubbo.application.name=foo和<dubbo:registry name=“foo” />是等价的,而dubbo.registry.address=nacos://localhost:8848和<dubbo:registry address="nacos://localhost:8848"这两个也是等价的。而在多配置的时候,需要用ID进行区分时,dubbo.protocol.rmi.port=1099 equals to <dubbo:protocol id=“rmi” name=“rmi” port=“1099” />这两种方式也是等价的。而且实际上,在SpringBoot工程中,也是可以通过引入@ImportResource注解,来指定dubbo的服务配置XML的。

而如果在一个SpringBoot工程中,将两种配置方式整合在一起,那配置的优先级又是怎样的呢?这时的优先级是{java -D}>{xml}>{properties}。并且,如果一个项目中有多个dubbo.properties(例如多个jar包中都有配置文件),那么,dubbo会随机的读取一个配置文件,同时会抛出异常信息。官方的建议也是多使用xml方式进行配置。

另外,基于SpringCloud的properties配置,其实还有另一种基于注解的服务声明方式,@Service暴露服务,@Reference调用服务,而这种方式,其实跟xml配置的方式也是等价的。

服务端与消费端的配置优先级

有很多服务属性如retris(重试次数)、timeout(超时时间)、loadbalance(负载方法)等属性,在服务提供端和服务消费端都可以进行配置。此时,服务消费端的配置是优先于服务提供端的。服务提供端的配置相当于是服务的默认属性,因此,官方建议要在服务提供端尽量多的配置这些服务属性。另外,官方还建议,在服务端尽量提供更详细的服务配置,例如在配置服务时,如果可以的话,对每个method提供详细的配置。例如:

<dubbo:protocol threads="200" /> 
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
    executes="200" >
    <dubbo:method name="findAllPerson" executes="50" />
</dubbo:service>

这样指定了线程池200,而findAllPerson的线程池为50.

指定dubbo的Cache File

官方建议要在registry中指定file。例如<dubbo:registry file=”${user.home}/output/dubbo.cache” />。这个Cache File可以缓存服务注册信息,这样,在注册中心停止服务后,消费端依然可以进行服务调用。由于这个文件很重要,虽然不指定也会默认生成到本地,但是官方建议是要单独指定缓存文件,并且注意不要有多个工程指定同一个缓存文件的情况,这样会造成文件写入权限竞争以及服务注册信息被覆盖的情况。

这个CacheFile机制可以允许消费者绕过注册中心访问服务提供者,而如果需要防止这种情况,可以使用dubbo的令牌验证机制,这样需要在注册中心进行权限验证才可以访问。开启方式也很简单,在provider或者service指定token属性即可:

<!--随机token令牌,使用UUID生成-->
<dubbo:provider interface="com.foo.BarService" token="true" />
<!--固定token令牌,相当于密码-->
<dubbo:provider interface="com.foo.BarService" token="123456" />

其他一些有意思的地方

官方的文档中很详细的说明了dubbo的许多特性,这里挑一些有意思的特性。其他可以多参考官方文档。

服务集群容错机制

可以在service中指定集群容错机制,例如 <dubbo:service cluster=“failsafe” />

本地服务存根与本地伪装 local stub, local mock

1、通常情况下,服务消费端只有一个接口,对服务的调用实现全部依赖服务提供端。但是,有时候,服务提供端希望在服务消费端也做一些本地操作,例如做ThreadLocal缓存、参数检查、调用失败后返回Mock假数据等。这样,有些在SpringCloud中需要在消费端用Hystrix做的事情,就可以用这个本地服务存根,在服务端直接帮消费端处理完了,这样可以让消费端更进一步忽略服务调用细节。例如,在服务提供端做如下配置:

<dubbo:service interface="com.foo.BarService" stub="true" /> or
<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />

然后服务提供端就可以通过提供一个本地存根方法,这样BarServiceStub的sayHello方法会在消费端的本地执行,让消费端在服务调用失败后返回容错数据。

public class BarServiceStub implements BarService {
    private final BarService barService;
    // 构造函数传入真正的远程代理对象
    public BarServiceStub(BarService barService){
        this.barService = barService;
    }
    public String sayHello(String name) {
        // 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存,或预先验证参数是否合法,等等
        try {
            return barService.sayHello(name);
        } catch (Exception e) {
            // 你可以容错,可以做任何AOP拦截事项
            return "容错数据";
        }
    }
}

2、针对Mock这种容错场景,dubbo可以使用mock属性进行更简单的配置;

<dubbo:reference interface="com.foo.BarService" mock="true" /> or
<dubbo:reference interface="com.foo.BarService" mock="com.foo.BarServiceMock" />

这样,在barServiceMock中,就不用try cache,而只用关注cache后的处理。

public class BarServiceMock implements BarService {
    public String sayHello(String name) {
        // 你可以伪造容错数据,此方法只在出现RpcException时被执行
        return "容错数据";
    }
}

这样,服务消费者可以省掉很多不必要的try cache操作。

3、在mock属性中,可以直接返回一些指定的对象,从而连实现代码都可以省略调了。例如:

<dubbo:reference interface="com.foo.BarService" mock="return null" />

mock属性可以返回的对象有:

还有, mock属性中,还可以简单的抛出异常

<dubbo:reference interface="com.foo.BarService" mock="throw" /> //抛出一个RPCException异常
<dubbo:reference interface="com.foo.BarService" mock="throw com.foo.MockException" /> //抛出一个指定异常

4、这个版本的dubbo中,mock属性还支持force和fail的mock行为。

fail跟默认流程一致,即表示当消费端远程调用出现异常时才进行。

而force则表示不走远程调用,直接返回mock数据。这在调试时还是有点用的。

force和fail都支持与上面的return或者throw进行组合。、

<dubbo:reference interface="com.foo.BarService" mock="force:return fake" /> or
<dubbo:reference interface="com.foo.BarService" mock="force:throw com.foo.MockException" />

5、这个local mock,在处理服务调用异常时,是挺强大的。官方建议,尽量在方法级别上使用mock,而不要在整个服务上使用。像这样,只在sayHello方法上使用mock.

<dubbo:reference id="demoService" check="false" interface="com.foo.BarService">
    <dubbo:parameter key="sayHello.mock" value="force:return fake"/>
</dubbo:reference>

6、注意下,stub和mock在服务的提供端和消费端都可以指定,应该还是消费端的优先级高于提供端。

泛化服务 GenericService

Dubbo的服务总是面向接口的,意味着服务调用总是需要一个固定的接口对象,这样很安全,但是同时也不够灵活。而Dubbo可以通过GenericService泛华服务来增加服务灵活性。

1、服务提供端:

在服务提供端,可以用org.apache.dubbo.rpc.service.GenericService替代所有的接口实现。 例如,先按如下方式提供一个服务:

<bean id="genericService" class="com.foo.MyGenericService" />
<dubbo:service interface="com.foo.BarService" ref="genericService" />

而指定的MyGenericService,可以通过继承GenericService来实现扩展逻辑:

public class MyGenericService implements GenericService {
    @Override
    public Object $invoke(String methodName, String[] parameterTypes, Object[] args) throws GenericException {
        if ("sayHello".equals(methodName)) {
            return "Welcome " + args[0];
        }
    }
}

这样就可以在不需要接口的情况下,响应服务端的 barService.sayHello(String args)这样的服务请求了。

这种泛化服务方式同样支持API方式的服务暴露,跟xml的配置基本是对等的。

2、泛化服务调用

泛化服务调用,只需要在reference中指定generic为true就行。

<dubbo:reference id="barService" interface="com.foo.BarService" generic="true" />

泛化服务没有了预先定义好的方法,需要使用GenericService的$invoke方法来进行调用

GenericService barService = (GenericService) applicationContext.getBean("barService");
Object result = barService.$invoke("sayHello", new String[] { "java.lang.String" }, new Object[] { "World" });

这种调用方式同样支持API格式的服务调用。

泛化方法的返回对象,如果是个POJO的对象,则会以Map结构返回POJO的信息,类似于下面的结构

Map<String, Object> map = new HashMap<String, Object>(); 
// 注意:如果参数类型是接口,或者List等丢失泛型,可通过class属性指定类型。
map.put("class", "com.xxx.PersonImpl"); 
map.put("name", "xxx");  // Person的属性
map.put("password", "yyy");

服务管理控制台

Dubbo使用Nacos作为注册中心的话,Nacos已经可以充当服务控制台。

而另外有一个项目则可替代原有的Dubbo Admin作为Dubbo的服务管理控制台。github地址:https://github.com/apache/dubbo-admin 一个基于Vue.js和Verify+SpringBoot做的前后端分离的管理控制台。

国人的官网看着舒适,示例丰富,说明也很简单详尽,目前版本的Dubbo还有些如分布式事务之类的功能尚未实现,期待Dubbo更强大把。

以上为个人经验,希望能给大家一个参考,也希望大家多多支持。

加载全部内容

相关教程
猜你喜欢
用户评论