Dubbo的呈现背景

Dubbo从开源到当初,曾经呈现了靠近10年工夫,在国内各大企业被广泛应用。 它到底有什么魔力值得大家去追捧呢?本篇文章给大家做一个具体的阐明。

大规模服务化对于服务治理的要求

当企业开始大规模的服务化当前,近程通信带来的弊病就越来越显著了。比如说

  1. 服务链路变长了,如何实现对服务链路的跟踪和监控呢?
  2. 服务的大规模集群使得服务之间须要依赖第三方注册核心来解决服务的发现和服务的感知问题
  3. 服务通信之间的异样,须要有一种爱护机制避免一个节点故障引发大规模的系统故障,所以要有容错机制
  4. 服务大规模集群会是的客户端须要引入负载平衡机制实现申请散发

而这些对于服务治理的要求,传统的RPC技术在这样的场景中显得有点力不从心,因而很多企业开始研发本人的RPC框架,比方阿里的HSF、Dubbo;京东的JSF框架、当当的dubbox、新浪的motan、蚂蚁金服的sofa等等

有技术输入能力的公司,都会研发适宜本人场景的rpc框架,要么是从0到1开发,要么是基于现有的思维联合公司业务特色进行革新。而没有技术输入能力的公司,遇到服务治理的需要时,会优先选择那些比拟成熟的开源框架。而Dubbo就是其中一个

dubbo次要是一个分布式服务治理解决方案,那么什么是服务治理?服务治理次要是针对大规模服务化当前,服务之间的路由、负载平衡、容错机制、服务降级这些问题的解决方案,而Dubbo实现的不仅仅是近程服务通信,并且还解决了服务路由、负载、降级、容错等性能。

Dubbo的倒退历史

Dubbo是阿里巴巴外部应用的一个分布式服务治理框架,2012年开源,因为Dubbo在公司外部通过了很多的验证相对来说比拟成熟,所以在很短的的还是件就被很多互联网公司应用,再加上阿里进去的很多技术大牛进入各个守业公司负责技术架构当前,都以Dubbo作为主推的RPC框架使得dubbo很快成为了很多互联网公司的首要抉择。并且很多公司在利用dubbo时,会基于本身业务个性进行优化和改良,所以也衍生了很多版本,比方京东的JSF、比方新浪的Motan、比方当当的dubbox.

在2014年10月份,Dubbo进行了保护。起初在2017年的9月份,阿里发表重启Dubbo,并且对于Dubbo做好了长期投入的筹备,并且在这段时间Dubbo进行了十分多的更新,目前的版本曾经到了2.7.

2018年1月8日,Dubbo创始人之一梁飞在Dubbo交换群里走漏了Dubbo 3.0正在动工的音讯。Dubbo 3.0内核与Dubbo2.0齐全不同,但兼容Dubbo 2.0。Dubbo 3.0将反对可选Service Mesh

2018年2月份, Dubbo捐给了Apache。另外,阿里巴巴对于Spring Cloud Alibaba生态的欠缺,以及Spring Cloud团队对于alibaba整个服务治理生态的反对,所以Dubbo将来仍然是国内绝大部分公司的首要抉择。

Dubbo的整体架构

Dubbo的应用

首先,构建两个maven我的项目

  • user-service

    • user-service-api
    • user-service-provider
  • user-service-consumer

user-service-api

user-service提供服务的公共契约,外面提供了user-service对外的服务。

public interface ILoginService {    String login(String username,String password);}

user-service-provider

在user-service-provider服务中,提供ILoginService的实现

public class LoginServiceImpl implements ILoginService{    @Override    public String login(String username, String password) {        if(username.equals("admin")&&password.equals("admin")){            return "SUCCESS";        }        return "FAILED";    }}

user-service-consumer

public class App {    public static void main( String[] args ){        ILoginService loginService=null;        System.out.println(loginService.login("admin","admin"));    }}

问题来了,当初user-service-consumer作为服务消费者,如何去调用近程服务user-service-provider呢?

依照后面对于服务近程通信的原理来说,服务提供方必然须要将服务公布到网络上,并且提供对应的拜访协定。而服务生产端必然须要基于这个协定来进行拜访。

这个时候,dubbo这个中间件就派上用场了,它的最根本作用就是提供服务的公布和服务的近程拜访。

引入Dubbo公布服务

  • 引入dubbo依赖包

    <dependency>    <groupId>org.apache.dubbo</groupId>    <artifactId>dubbo</artifactId>    <version>2.7.8</version></dependency>
  • 在/src/main/resource/META-INF/spring目录下增加application.xml文件

    <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"       xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">    <!-- 提供方利用信息,用于计算依赖关系 -->    <dubbo:application name="user-service"/>    <!-- 应用multicast播送注册核心裸露服务地址 -->    <dubbo:registry address="N/A" />    <!-- 用dubbo协定在20880端口裸露服务 -->    <dubbo:protocol name="dubbo" port="20880" />    <!-- 申明须要裸露的服务接口 -->    <dubbo:service interface="com.gupaoedu.demo.ILoginService" ref="loginService" />    <!-- 和本地bean一样实现服务 -->    <bean id="loginService" class="com.gupaoedu.demo.LoginServiceImpl" /></beans>
  • 启动服务

    public class App {    public static void main( String[] args ){        Main.main(args);    }}
  • 启动胜利后,会在控制台看到如下日志

    信息:  [DUBBO] Export dubbo service com.gupaoedu.demo.ILoginService to url dubbo://192.168.1.104:20880/com.gupaoedu.demo.ILoginService?anyhost=true&application=user-service&bind.ip=192.168.1.104&bind.port=20880&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.gupaoedu.demo.ILoginService&methods=login&pid=24280&release=2.7.8&side=provider&timestamp=1596550697070, dubbo version: 2.7.8, current host: 192.168.152.1八月 04, 2020 10:18:17 下午 org.apache.dubbo.remoting.transport.AbstractServer info信息:  [DUBBO] Start NettyServer bind /0.0.0.0:20880, export /192.168.1.104:20880, dubbo version: 2.7.8, current host: 192.168.152.1

通过上述步骤,就示意ILoginService曾经公布到了网络上,基于NettyServer的模式,默认监听20880端口

服务消费者引入dubbo

  • 增加jar包依赖

    <dependency>    <groupId>org.apache.dubbo</groupId>    <artifactId>dubbo</artifactId>    <version>2.7.8</version></dependency>
  • 在/src/main/resources/META-INF/spring目录下增加application.xml文件

    <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"       xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">    <!-- 提供方利用信息,用于计算依赖关系 -->    <dubbo:application name="user-service-consumer"/>    <!-- 应用multicast播送注册核心裸露服务地址 -->    <dubbo:registry address="N/A" />    <dubbo:reference id="loginService" interface="com.gupaoedu.demo.ILoginService"/></beans>
  • 批改main办法

    • 通过ApplicationContext加载spring的配置文件
    • 从容器中取得一个ILoginService的bean
    public class App {    public static void main( String[] args ){        ILoginService loginService=null;        ApplicationContext applicationContext=new ClassPathXmlApplicationContext("classpath:META-INF/spring/application.xml");        loginService=applicationContext.getBean(ILoginService.class);        System.out.println(loginService.login("admin","admin"));    }}

指定服务提供端的url

在上述的配置实现之后,运行我的项目后发现会提醒如下谬误

IllegalStateException: No such any registry to reference com.gupaoedu.demo.ILoginService on the consumer 192.168.152.1 use dubbo version 2.7.8, please config <dubbo:registry address="..." /> to your spring config.

起因是,咱们配置的dubbo:registry指定的注册核心是N/A,示意没有配置注册核心。

其次,咱们也没有明确的指明服务提供者在什么地位。因而解决这个问题的办法有两种

  • 指向服务提供者的地址
  • 配置服务注册核心,把服务提供者注册到注册核心,而后服务消费者指向注册核心从注册核心获取服务地址

批改形式如下,批改服务消费者中application.xml中的dubbo:reference。

 <dubbo:reference id="loginService" interface="com.gupaoedu.demo.ILoginService"     url="dubbo://192.168.1.104:20880/com.gupaoedu.demo.ILoginService"/>

总结

简略总结一下下面的整个过程,其实不难发现,Dubbo这个中间件为咱们提供了服务近程通信的解决方案。通过dubbo这个框架,能够开发者疾速高效的构建微服务架构下的近程通信实现。

不晓得大家是否发现,咱们在应用dubbo公布服务,或者生产服务的时候,全程都是采纳spring的配置来实现的,这样的益处是咱们在学习或者应用dubbo时,如果你用过spring这个框架,那么对于它的学习难度会大大的升高。而且咱们也能够看到,dubbo是齐全集成Spring 的,因而后续咱们去剖析dubbo的源码时,还是会有一些和spring无关的内容。

而且如果大家之前学习过我手写RPC的那节课,也根本能猜测到它的整个实现构造,大家无妨大胆的去猜想dubbo的一些实现细节,以助于后续在深度学习dubbo时更好的了解。

引入注册核心

Dubbo并不仅仅只是一个RPC框架,他还是一个服务治理框架,它提供了对服务的对立治理、以及服务的路由等性能。

在下面的案例中,咱们只是拆穿了Dubbo作为RPC通信的点对点服务,然而就像咱们后面在学习spring cloud的内容一样,服务多了当前,如何治理和保护,以及动静发现呢?

而且,从Dubbo的架构图中能够看到,Dubbo人造就反对服务注册与发现,官网最早举荐的服务注册核心是zookeeper,当然,目前dubbo可能反对的注册核心曾经十分多了,比方

consul、etcd、nacos、sofa、zookeeper、eureka、redis等等,很显然,Dubbo曾经在往一个独立微服务解决方案的生态在倒退。

集成Zookeeper作为服务注册核心

  • 增加zookeeper的jar包依赖

    <dependency>    <groupId>org.apache.dubbo</groupId>    <artifactId>dubbo-dependencies-zookeeper</artifactId>    <version>2.7.8</version></dependency>
  • 批改服务提供者和服务消费者的配置

    <dubbo:registry address="zookeeper://192.168.216.128:2181" />

集成Nacos作为服务注册核心

  • 启动nacos

    docker run --name nacos -d -p 8848:8848 --privileged=true --restart=always -e JVM_XMS=512m -e JVM_XMX=2048m -e MODE=standalone -e PREFER_HOST_MODE=hostname -v /home/nacos/logs:/home/nacos/logs nacos/nacos-server
    • privileged: 应用该参数,container内的root领有真正的root权限。否则,container内的root只是内部的一个普通用户权限。
    • 当 Docker 重启时,容器主动重启
    • PREFER_HOST_MODE: ip #如果反对主机名能够应用hostname,否则应用ip,默认也是ip
  • 增加依赖

    <dependency>    <groupId>com.alibaba.nacos</groupId>    <artifactId>nacos-client</artifactId>    <version>1.2.1</version></dependency>
  • 批改配置

    <dubbo:registry address="nacos://192.168.216.128:8848" timeout="10000" />

Dubbo Spring Cloud

既然咱们讲的是Spring Cloud Alibaba这个专题,那么咱们就有必要去理解一下Dubbo是如何集成Spring Cloud去应用的。

Dubbo Spring Cloud是构建在原生的Spring Cloud之上,涵盖了Spring Cloud原生个性,而且绝对于Spring Cloud原生治理来说,Dubbo Spring Cloud提供了更加稳固和成熟的实现。

具体的个性比照如下:

为什么叫Dubbo Spring Cloud,而不是Spring Cloud Dubbo呢,在我看来,Dubbo自身是自成一个生态体系,并且在自身的服务治理以及成熟度上要比Spring cloud 更加突出。

所以实际上Dubbo整合Spring Cloud,是Dubbo这个成熟的生态去拥抱spring cloud的规范体系。

Dubbo Spring Cloud 基于 Dubbo Spring Boot 2.7.1[1] 和 Spring Cloud 2.x 开发,无论开发人员是 Dubbo 用户还是 Spring Cloud 用户, 都能轻松地驾驭,并以靠近“零”老本的代价使利用向上迁徙

从 2.7.0 开始,Dubbo Spring Boot 与 Dubbo 在版本上保持一致

接下来,咱们能够去利用Dubbo Spring Cloud来做一个简略的案例实现

创立一个我的项目

  • 创立一个spring-cloud-dubbo-example的maven工程
  • 别离增加三个模块

    • spring-cloud-dubbo-sample-api
    • spring-cloud-dubbo-sample-provider
    • spring-cloud-dubbo-sample-consumer
其中前面两个模块都是spring boot的利用。

批改spring-cloud-dubbo-sample-provider这个模块中。

  • 将dependencyManagement局部的依赖挪动到parent pom.xml
  • 批改spring-cloud-dubbo-sample-provider中的pom.xml,减少parent模块的依赖

    <parent>    <groupId>com.gupaoedu.dubbo</groupId>    <artifactId>spring-cloud-dubbo-example</artifactId>    <version>1.0-SNAPSHOT</version></parent>
  • 增加maven依赖

    <dependency>    <groupId>com.alibaba.cloud</groupId>    <artifactId>spring-cloud-starter-dubbo</artifactId></dependency><dependency>    <groupId>com.gupaoedu.dubbo</groupId>    <version>1.0-SNAPSHOT</version>    <artifactId>spring-cloud-dubbo-sample-api</artifactId></dependency><dependency>    <groupId>com.alibaba.cloud</groupId>    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>

定义服务接口

在spring-boot-dubbo-sample-api模块中,定义接口

public interface IHelloService {    String sayHello();}

实现服务

在spring-boot-dubbo-sample-provider中,实现IHelloService接口

public class HelloServiceImpl implements IHelloService{    @Override    public String sayHello() {        return "Hello GuPao";    }}

增加@EnableDiscoveryClient注解

@EnableDiscoveryClient@SpringBootApplicationpublic class SpringCloudDubboSampleProviderApplication {    public static void main(String[] args) {        SpringApplication.run(SpringCloudDubboSampleProviderApplication.class, args);    }}

配置dubbo服务公布

  • 在服务实现类中增加@Service注解

    @Servicepublic class HelloServiceImpl implements IHelloService{    @Override    public String sayHello() {        return "Hello GuPao";    }}
  • 配置dubbo提供方信息

    # dubbo 服务扫描根底包门路dubbo.scan.base-packages=com.gupaoedu.dubbo.springclouddubbosampleproviderdubbo.protocol.id=dubbo# Dubbo 服务裸露的协定配置,其中子属性 name 为协定名称,port 为协定端口( -1 示意自增端口,从 20880 开始)dubbo.protocol.name=dubbodubbo.protocol.port=-1spring.cloud.nacos.discovery.server-addr=192.168.216.128:8848
    • dubbo.scan.base-packages : 指定 Dubbo 服务实现类的扫描基准包
    • dubbo.protocol : Dubbo 服务裸露的协定配置,其中子属性 name 为协定名称,port 为协定端口( -1 示意自增端口,从 20880 开始)
    • dubbo.registry : Dubbo 服务注册核心配置,其中子属性 address 的值 "spring-cloud://localhost",阐明挂载到 Spring Cloud 注册核心
    • spring.cloud.nacos.discovery : Nacos 服务发现与注册配置,其中子属性 server-addr 指定 Nacos 服务器主机和端口

版本标准

我的项目的版本号格局为 x.x.x 的模式,其中 x 的数值类型为数字,从 0 开始取值,且不限于 0~9 这个范畴。我的项目处于孵化器阶段时,第一位版本号固定应用 0,即版本号为 0.x.x 的格局。

因为 Spring Boot 1 和 Spring Boot 2 在 Actuator 模块的接口和注解有很大的变更,且 spring-cloud-commons 从 1.x.x 版本升级到 2.0.0 版本也有较大的变更,因而咱们采取跟 SpringBoot 版本号统一的版本:

  • 1.5.x 版本实用于 Spring Boot 1.5.x
  • 2.0.x 版本实用于 Spring Boot 2.0.x
  • 2.1.x 版本实用于 Spring Boot 2.1.x
  • 2.2.x 版本实用于 Spring Boot 2.2.x

构建服务消费者

  • 增加jar包依赖

    <dependency>    <groupId>com.alibaba.cloud</groupId>    <artifactId>spring-cloud-starter-dubbo</artifactId></dependency><dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-actuator</artifactId></dependency><dependency>    <groupId>com.gupaoedu.dubbo</groupId>    <version>1.0-SNAPSHOT</version>    <artifactId>spring-cloud-dubbo-sample-api</artifactId></dependency><dependency>    <groupId>com.alibaba.cloud</groupId>    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency><dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-starter-web</artifactId></dependency>
  • 增加配置文件

    spring.application.name=spring-cloud-dubbo-sample-consumerdubbo.application.name=spring-cloud-dubbo-sample-consumerdubbo.cloud.subscribed-services=spring-cloud-dubbo-sample-providerspring.cloud.nacos.discovery.server-addr=192.168.216.128:8848

    除利用名称 spring.application.name 存在差别外,spring-cloud-dubbo-client-sample 新增了属性 dubbo.cloud.subscribed-services 的设置。并且该值为服务提供方利用 "spring-cloud-dubbo-sample-provider"。

    它的次要作用是服务生产方订阅服务提供方的利用名称的列表,若需订阅多利用,应用 "," 宰割。 不举荐应用默认值为 "*",它将订阅所有利用。

  • 编写测试代码

    @RestController@EnableDiscoveryClient@SpringBootApplicationpublic class SpringCloudDubboSampleConsumerApplication {    public static void main(String[] args) {        SpringApplication.run(SpringCloudDubboSampleConsumerApplication.class, args);    }    @Reference    IHelloService helloService;    @GetMapping("/say")    public String say(){        return helloService.sayHello();    }}

    # 多注册核心的反对

dubbo绝对于spring cloud来说,它的弱小之处在于,提供了很多不同场景的性能反对,比方多注册核心的反对。

所谓的多注册核心,就是指dubbo能够同时配置多个注册核心的地址,而后针对于不同类型的服务注册到不同的注册核心上。

Dubbo多注册核心能够反对几种场景

一个服务部署到多个注册核心

基于spring cloud的配置形式

  • 增加jar包依赖

    <dependency>    <groupId>org.apache.dubbo</groupId>    <artifactId>dubbo-dependencies-zookeeper</artifactId>    <version>2.7.8</version>    <exclusions>        <exclusion>            <groupId>org.slf4j</groupId>            <artifactId>slf4j-log4j12</artifactId>        </exclusion>        <exclusion>            <artifactId>log4j</artifactId>            <groupId>log4j</groupId>        </exclusion>    </exclusions></dependency>
  • 批改application配置

    dubbo.registries.registry1.address=nacos://192.168.216.128:8848dubbo.registries.registry1.timeout=10000dubbo.registries.registry2.address=zookeeper://192.168.216.128:2181dubbo.registries.registry2.timeout=10000#spring.cloud.nacos.discovery.server-addr=192.168.216.128:8848spring.cloud.nacos.discovery.register-enabled=falsespring.cloud.nacos.discovery.watch.enabled=falsespring.cloud.service-registry.auto-registration.enabled=false
    • spring.cloud.service-registry.auto-registration.enabled 敞开spring cloud的主动注册
    • spring.cloud.nacos.discovery.watch.enabled/spring.cloud.nacos.discovery.register-enabled敞开nacos的服务注册和监听

    这么做的目标是,躲避spring cloud自身的服务注册发现机制,走dubbo自身的服务注册与发现

  • 批改服务配置

    @Service(registry = {"registry1","registry2"})public class HelloServiceImpl implements IHelloService{    @Override    public String sayHello() {        return "Hello GuPao";    }}

多注册核心的援用

  • 批改生产端的application.properties

    dubbo.registries.registry1.address=nacos://192.168.216.128:8848dubbo.registries.registry1.timeout=10000dubbo.registries.registry2.address=zookeeper://192.168.216.128:2181dubbo.registries.registry2.timeout=10000spring.cloud.nacos.discovery.register-enabled=falsespring.cloud.nacos.discovery.watch.enabled=falsespring.cloud.service-registry.auto-registration.enabled=false
  • 增加jar包依赖

    <dependency>    <groupId>org.apache.dubbo</groupId>    <artifactId>dubbo-dependencies-zookeeper</artifactId>    <version>2.7.8</version>    <exclusions>        <exclusion>            <groupId>org.slf4j</groupId>            <artifactId>slf4j-log4j12</artifactId>        </exclusion>        <exclusion>            <artifactId>log4j</artifactId>            <groupId>log4j</groupId>        </exclusion>    </exclusions></dependency>

基于spring boot集成Dubbo形式

实际上,在dubbo spring cloud的应用形式中,对于配置多个服务注册核心不是很敌对而且还有一些潜在的问题, 毕竟dubbo和spring cloud两个实质上是属于齐全不同的生态耦合在一起,必然会导致一些兼容问题。比方刚刚咱们去配置的这些多注册核心的反对,它须要去敞开spring cloud自身的服务主动注册和发现的反对,实质上就是在两个生态中抉择其中一个生态作为次要形式来应用。

所以,如果是在spring cloud的生态中,能够尽量减少对于dubbo自身灵活性的应用,拥抱spring cloud的规范生态,当然如果心愿以dubbo作为独立的生态来应用,大家能够采纳spring boot+Dubbo来集成,

这里同样也给大家疾速构建一下。

另外,dubbo集成到spring boot中还有一个益处,就是它能够继承spring boot自身的个性

  • 主动拆卸(注解驱动、主动拆卸)
  • production-ready(平安机制、衰弱检测、内部化配置)

创立我的项目构造

创立根底的我的项目构造

  • spring-boot-dubbo-example [maven]

    • spring-boot-dubbo-sample-api [maven]
    • spring-boot-dubbo-sample-provider [spring boot]
    • spring-boot-dubbo-sample-consumerp [spring-boot]

增加jar包依赖

从2.7开始,dubbo的版本和dubbo-spring-boot的版本是保持一致的,所以大家不必再去放心版本的问题。

<dependency>    <groupId>org.apache.dubbo</groupId>    <artifactId>dubbo-spring-boot-starter</artifactId>    <version>2.7.7</version></dependency><dependency>    <groupId>com.alibaba.nacos</groupId>    <artifactId>nacos-client</artifactId>    <version>1.2.1</version></dependency>

增加服务以及公布

@DubboServicepublic class SayHelloServiceImpl implements ISayHelloService{    @Override    public String sayHello() {        return "Hello GuPaoEdu.com";    }}
spring.application.name=spring-boot-dubbo-sample-providerdubbo.registry.address=nacos://192.168.216.128:8848dubbo.scan.base-packages=com.gupaoedu.springboot.dubbo.springbootdubbosampleprovider.servicedubbo.protocol.name=dubbodubbo.protocol.port=-1

编写服务援用代码

  • 增加jar包依赖

    <dependency>    <groupId>org.springframework.boot</groupId>    <artifactId>spring-boot-starter-web</artifactId></dependency><dependency>    <groupId>com.gupaoedu.com</groupId>    <version>1.0-SNAPSHOT</version>    <artifactId>spring-boot-dubbo-sample-api</artifactId></dependency><dependency>    <groupId>org.apache.dubbo</groupId>    <artifactId>dubbo-spring-boot-starter</artifactId>    <version>2.7.7</version></dependency><dependency>    <groupId>com.alibaba.nacos</groupId>    <artifactId>nacos-client</artifactId>    <version>1.2.1</version></dependency>
  • 增加web测试类

    @DubboReferenceISayHelloService sayHelloService;@GetMapping("/get")public String get(){    return sayHelloService.sayHello();}
    dubbo.registry.address=nacos://192.168.216.128:8848

不同服务注册到不同的注册核心

从下面的配置能够发现,咱们开能够针对不同的服务配置到不同的注册核心,这个就不再浪费时间去演示了。

多个注册核心的集群

如果一个服务消费者援用了多个注册核心,那么这个时候服务消费者首先要做的就是先针对注册核心的负载平衡,而后失去一个指标注册核心之后,再从指标注册核心上取得服务提供者的地址列表再进行集群拜访,实现原理如下图所示

当然,有三种形式来指定注册核心的负载平衡配置

  • 指定优先级

    <!-- 来自 preferred=“true” 注册核心的地址将被优先选择,只有该核心无可用地址时才 Fallback 到其余注册核心 --><dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />
  • 同zone优先

    <!-- 选址时会和流量中的 zone key 做匹配,流量会优先派发到雷同 zone 的地址 --><dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />
  • 权重轮询

    <!-- 来自北京和上海集群的地址,将以 10:1 的比例来调配流量 --><dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}" weight=”100“ /><dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}" weight=”10“ />

接口多版本反对

平时咱们在开发接口的时候,可能会面临到一个接口的批改,然而这个时候因为线上会有一些我的项目正在应用这个接口,如果间接批改,很可能会对线上的服务造成比拟大的影响。

因而对于这种状况,dubbo提供了接口版本的反对。

具体的配置形式

  • 服务端针对同一个接口提供不同版本的实现
  • 并在dubboservice注解中配置版本的申明

    @DubboService(registry = {"registry1","registry2"},version = "1.0")
  • 服务生产端指定生产版本号

    @DubboReference(registry = {"registry1","registry2"},version = "2.0")ISayHelloService sayHelloService;

多协定的反对

当公司本来采纳其余的rpc框架,这个时候如果想迁徙到dubbo这个框架上来,那么Dubbo提供的多协定反对就可能提供简直零老本的迁徙。

对于一个服务,能够同时公布多种不同协定的接口,也能够针对不同的接口公布不同的协定类型。并且从2.7开始,dubbo对于一些支流的协定做了反对,目前曾经反对的协定有

dubbo协定、hessian协定、http协定、thrift、rmi、webservice、grpc、rest等。首次之外,dubbo还提供了非常灵活的可扩展性机制,对于有定制化需要或者目前正在应用的协定,dubbo不反对的公司,是能够本人去进行扩大。

整体的灵活性以及可插拔性的个性,相比spring cloud来说,更加弱小。

JAX-RS协定阐明

Dubbo中的REST(表述性资源转移)反对,是基于JAX-RS2.0(Java API for RESTful Web Services)来实现的。

REST是一种架构格调,简略来说就是对于api接口的束缚,基于URL定位资源,应用http动词(GET/POST/DELETE)来形容操作

REST很早就提出来了,在晚期开发人员为了实现REST,会应用各种工具来实现,比方Servlets就常常用来开发RESTful的程序。随着REST被越来越多的开发人员采纳,所以JCP(Java community process)提出了JAX-RS标准,并且提供了一种新的基于注解的形式来开发RESTful服务。有了这样的一个标准,使得开发人员不须要关怀通信层的货色,只须要关注资源以以及数据对象。

JAX-RS标准的实现有:Apache CXF、Jersey(由Sun公司提供的JAX-RS的参考实现)、RESTEasy(jboss实现)等。

而Dubbo外面实现的REST就是基于Jboss提供的RESTEasy框架来实现的

SpringMVC中的RESTful实现咱们用得比拟多,它也是JAX-RS标准的一种实现

增加REST反对

  • 增加jar包依赖

    <dependency>    <groupId>org.jboss.resteasy</groupId>    <artifactId>resteasy-jaxrs</artifactId>    <version>3.13.0.Final</version></dependency><dependency>    <groupId>org.jboss.resteasy</groupId>    <artifactId>resteasy-client</artifactId>    <version>3.13.0.Final</version></dependency><dependency>    <groupId>org.eclipse.jetty</groupId>    <artifactId>jetty-server</artifactId>    <version>9.4.19.v20190610</version></dependency><dependency>    <groupId>org.eclipse.jetty</groupId>    <artifactId>jetty-servlet</artifactId>    <version>9.4.19.v20190610</version></dependency>
  • 批改配置文件

    dubbo.protocols.dubbo.name=dubbodubbo.protocols.dubbo.port=-1dubbo.protocols.rest.name=restdubbo.protocols.rest.port=8888dubbo.protocols.rest.server=jetty
  • 批改api的接口定义

    @Path("/")public interface ISayHelloService {    @GET    @Path("say")    String sayHello();}
版权申明:本博客所有文章除特地申明外,均采纳 CC BY-NC-SA 4.0 许可协定。转载请注明来自 Mic带你学架构
如果本篇文章对您有帮忙,还请帮忙点个关注和赞,您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货!