简述Dubbo的概念与如何使用Dubbo

最新推荐文章于 2020-12-03 08:49:12 发布

0oIronhide

最新推荐文章于 2020-12-03 08:49:12 发布

阅读量167

点赞数

文章标签：分布式 java zookeeper

本文链接：https://blog.csdn.net/qq_38599840/article/details/105982705

版权

背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
在这里插入图片描述
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
该应用架构适用于小型网站或小型管理系统，将所有模块都写在一个项目当中然后上线，但是项目维护或更新起来困难。

垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
该架构降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性，但其中的各个模块会存在重复的代码流程，会浪费一定的资源

分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

需求

在这里插入图片描述
在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过 F5 等硬件进行负载均衡。

当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态地注册和发现服务，使服务的位置透明。并通过在消费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，也能减少部分成本。

当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。

接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

以上是 Dubbo 最基本的几个需求。

Dubbo核心概念

Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

Dubbo基本概念

在这里插入图片描述
这也是官方的图，dubbo由 服务提供者、服务消费者、注册中心、监控中心 四大部分组成

服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
注册中心（Registry）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
监控中心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

四大部分调用关系：

服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

基于SpringBoot与注册中心zookeeper实现Dubbo的简单demo

首先确定好版本：

<parent>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-parent</artifactId>
    <version>2.0.4.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

zookeeper用的是3.4.11，下载链接：zookeeper下载，解压后进入 bin 文件夹运行 zkServer.cmd 就开启了zookeeper，zookeeper 是 apache Hadoop的子项目，是一个树形目录服务，适合作为dubbo的注册中心。

接下来的 dubbo-admin 是dubbo的管理控制台，能够可视化地管理消费者与服务提供者，运行该控制台不是必要的，运行zookeeper、消费者、提供者项目一样能跑，你可以从GitHub上下载下来并用 mvn package 命令打包，war包就放 tomcat 运行，jar 就 java -jar 命令运行，这里控制台对应的 dubbo 版本为 2.6.2，是用 jar 运行的，链接在我上传的资源 incubator-dubbo-ops-master.rar 里面
解压好后只关注 dubbo-admin 文件夹，如果 zookeeper 不是运行在本机的话要去 src\main\resources\application.properties修改 zookeeper 的ip地址，target 文件夹里面有一个 jar，运行报错的话再重新打个包，命令： mvn clean package -Dmaven.test.skip=true
，然后登录 localhost:7001访问控制台，用户名与密码都是 root 。
在这里插入图片描述
解下来是监控中心，运行监控中心也不是必要的，资源中 dubbo-monitor-simple 里 tartget 已经有一个压缩包了，解压并运行start.bat。如果 zookeeper 不是运行在本机的话要去 dubbo-monitor-simple\src\main\resources\conf修改 zookeeper 的ip地址，mvn clean package -Dmaven.test.skip=true 打包。启动后访问 8080 端口。

接下来就新建 SpringBoot 的项目了，一个消费者一个提供者，消费者与提供者共同引用一个存放 pojo 实体类与接口方法的 maven 项目，消费者请求提供者的 list 方法，返回一个 user 集合，目录如下：
在这里插入图片描述
先定义 user-interface 中的接口方法：

public interface UserService {
    public List<User> list();
}

SpringBoot 依赖，消费者提供者都一样：

	<properties>
        <java.version>1.8</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        
        <dependency>
            <groupId>cn.hp</groupId>
            <artifactId>user-interface</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
        
        <dependency>
            <groupId>com.alibaba.boot</groupId>
            <artifactId>dubbo-spring-boot-starter</artifactId>
            <version>0.2.0</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.junit.vintage</groupId>
                    <artifactId>junit-vintage-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
    </dependencies>

消费者配置：
在这里插入图片描述
主方法中加入注解：

@EnableDubbo
@SpringBootApplication
public class UserCustomerApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserCustomerApplication.class, args);
    }
}

server.port=9002

#服务名，不能跟别的dubbo提供端重复
dubbo.application.name=customer
#指定注册中心协议
dubbo.registry.protocol=zookeeper
#注册中心的地址加端口号
dubbo.registry.address=127.0.0.1:2181

# 以下包扫描与开启注解 @EnableDubbo 选其一配置
#dubbo.scan.base-packages=cn.hp.customer
dubbo.protocol.name=dubbo
#该服务在dubbo暴露的端口，不指定会自动分配
#dubbo.protocol.port=20080

服务提供者配置：
在这里插入图片描述

server.port=9001

dubbo.application.name=provider
dubbo.registry.protocol=zookeeper
dubbo.registry.address=127.0.0.1:2181
#dubbo.scan.base-packages=cn.hp
dubbo.protocol.name=dubbo
#dubbo.protocol.port=20081

主方法中加入注解：

@EnableDubbo
@SpringBootApplication
public class UserProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserProviderApplication.class, args);
    }

}

服务消费者的 service 层代码，@Reference 修饰 user-interface 项目中的接口方法，表示是消费者要远程调用，消费者的 controller 调用该层的 list 方法，最后直接请求消费者的 controller 即可：

@Service
public class CustomerService {

    @Reference
    private UserService service;

    public List<User> list() {
        return service.list();
    }

}

服务提供者的 service 层，该类直接实现 user-interface 中的接口，修饰提供者的 @Service 来源于包com.alibaba.dubbo.config.annotation.Service，不是spring提供的注解，表明向外暴露这个方法。

@Service
@Component
public class UserServiceImpl implements UserService {

    public List<User> list() {
        return Arrays.asList(new User(1l, "张三", "北京"),
                new User(2l, "李四", "上海"));
    }

}

俩个项目都开启来后，访问你消费者的 controller 方法：
在这里插入图片描述
访问 dubbo-admin 控制器：

以上简单的 dubbo 就配置好了。

Dubbo配置原则

JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。
XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。
Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

重试次数

当请求出现失败重试其它服务器，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。

@Reference(retries = 2)
private UserService service;

@Service(retries = 2)
@Component
public class UserServiceImpl implements UserService{...}

用 xml 配置也可以为：

<dubbo:reference>
    <dubbo:method name="list" retries="2" />
</dubbo:reference>

超时时间

由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。

在消费者端的 properties 中配置：

#配置消费者等待提供者返回的超时时间，默认1000
dubbo.consumer.timeout=2000

用 xml 配置：

<dubbo:reference interface="cn.hp.api" timeout="2000">
    <dubbo:method name="list" timeout="3000" />
</dubbo:reference>

在提供者端的 properties 中配置：

dubbo.provider.timeout=2000

或是：

<dubbo:provider interface="cn.hp.api" timeout="2000">
    <dubbo:method name="list" timeout="3000" />
</dubbo:provider>

配置原则：

作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等
在 Provider 配置后，Consumer 不配置则会使用 Provider 的配置值，即 Provider 配置可以作为 Consumer 的缺省值。否则，Consumer 会使用 Consumer 端的全局设置，这对于 Provider 不可控的，并且往往是不合理的

配置的覆盖规则：

方法级配置别优于接口级别，即小范围优先
Consumer 端配置优于 Provider 配置优于全局配置
消费者的接口级别的配置与提供者方法级别的配置相比较，dubbo会选择后者，相当于当方法精度与两服务端的配置都不相同时，方法精度优先

在这里插入图片描述

版本号

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

可以按照以下的步骤进行版本迁移：

在低压力时间段，先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本

消费者配置：

@Reference(retries = 2, version = "1.0.0")
    private UserService service;

或

老版本服务提供者配置：
<dubbo:service interface="cn.hp.api" version="1.0.0" />

新版本服务提供者配置：
<dubbo:service interface="cn.hp.api" version="2.0.0" />

提供者配置：

@Service(retries = 2, version = "1.0.0")
@Component
public class UserServiceImpl implements UserService{...}

或

老版本服务消费者配置：
<dubbo:reference id="userService" interface="cn.hp.api" version="1.0.0" />

新版本服务消费者配置：
<dubbo:reference id="userService" interface="cn.hp.api" version="2.0.0" />

如果不需要区分版本，可以按照以下的方式配置：
<dubbo:reference id="userService" interface="cn.hp.api" version="*" />

高可用

zookeeper宕机与dubbo直连

当 zookeeper 注册中心宕机，还可以消费 dubbo 暴露的服务。
原因：

监控中心宕掉不影响使用，只是丢失部分采样数据
数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
注册中心对等集群，任意一台宕掉后，将自动切换到另一台
注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
服务提供者无状态，任意一台宕掉后，不影响使用
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

集群下dubbo负载均衡配置

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 random 随机调用。
策略：

Random LoadBalance
随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
RoundRobin LoadBalance
轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
一致性 Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

在 dubbo-admin 控制台中可修改提供者权重
在这里插入图片描述

整合hystrix，服务熔断与降级处理

降级处理也就是服务降级，当一个请求阻塞或等待超时，会返回较为人性化的错误提示，或是当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

hystrix 是 SpringCloud 中的熔断器组件，也适用于 dubbo，Hystrix 旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能

配置 hystrix ，消费者与提供者同时加上依赖：

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
	<version>2.0.0.RELEASE</version>
</dependency>

消费者与提供者主类同时加上注解 @EnableHystrix：

@EnableHystrix
@EnableDubbo
@SpringBootApplication
public class UserProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserProviderApplication.class, args);
    }
}

提供者的 service 层加上注解 @HystrixCommand，方法中睡上3秒，一会测试熔断器的回调机制：

@Service(retries = 2, version = "1.0.0")
@Component
public class UserServiceImpl implements UserService {

    @HystrixCommand
    public List<User> list() {
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return Arrays.asList(new User(1l, "张三", "北京"),
                new User(2l, "李四", "上海"));
    }

}

消费者 service 层，加入了回调方法 fallBack ，方法返回值类型与目标方法一致：

@Service
public class CustomerService {

    @Reference(retries = 2, version = "1.0.0")
    private UserService service;

    @HystrixCommand(fallbackMethod = "fallBack")
    public List<User> list() {
        return service.list();
    }

    public List<User> fallBack() {
        return Arrays.asList(new User(), new User());
    }

}

因为超时缘故回调用回调方法，结果：
在这里插入图片描述

集群容错

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

模式：

Failover Cluster
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)，之前已配置过。
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。
集群模式配置
按照以下示例在服务提供方和消费方配置集群模式

<dubbo:service cluster="failsafe" />
或
<dubbo:reference cluster="failsafe" />

0oIronhide

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
简述Dubbo的概念与如何使用Dubbo

背景随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。单一应用架构当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。该应用架构适用于小型网站或小型管理系统，将所有模块都写在一个项目当中然后上线，但是项...
复制链接

扫一扫