Dubbo

小曹爱编程！

已于 2023-02-18 17:56:19 修改

阅读量444

点赞数 1

分类专栏：微服务开发与中间键文章标签： dubbo java-zookeeper zookeeper

于 2022-12-25 21:54:01 首次发布

本文链接：https://blog.csdn.net/weixin_62993347/article/details/128421022

版权

微服务开发与中间键专栏收录该内容

13 篇文章 1 订阅

订阅专栏

1、分布式系统里的相关概念

1.1、大型互联网项目的架构目标

传统项目和互联网项目

传统项目

HR系统、OA系统（例：员工请假系统）、CRM系统等等

传统项目面对的用户群体是企业员工

互联网项目

天猫、微信、百度等等

互联网项目面对的用户群体是网民（形形色色的人）

用户体验

美观、功能完善、速度快、稳定性好

衡量一个网站速度是否快：

打开一个新页面一瞬间完成、页面内跳转一刹那间完成。

互联网项目特点：

用户多
流量大
并发高
海量数据
易受攻击
功能繁琐
变更快

高性能：

提供快速的访问体验。

衡量网站的性能指标：

响应时间：

指执行一个请求从开始到最后收到响应数据所花费的总体时间。

并发数：

指系统同时能处理的请求数量。

并发连接数：指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量
请求数：也称为QPS(Query Per Second) 指每秒多少请求.
并发用户数：单位时间内有多少用户

吞吐量：

指单位时间内系统能处理的请求数量。

QPS：Query Per Second 每秒查询数。
TPS：Transactions Per Second 每秒事务数。
一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
一个页面的一次访问，只会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，就会有多个QPS

注意：QPS >= 并发连接数 >= TPS

高性能：

提供快速的访问体验。

高可用：

网站服务一直可以正常访问。

可伸缩：

通过硬件增加/减少，提高/降低处理能力。

高可扩展：

系统间耦合低，方便的通过新增/移除方式，增加/减少新的功能/模块。

安全性：

提供网站安全访问和数据加密，安全存储等策略。

敏捷性：

随需应变，快速响应。

1.2、集群和分布式

集群：

很多“人”一起，干一样的事。
一个业务模块，部署在多台服务器上。
解决了高性能、高可用

分布式：

很多“人”一起，干不一样的事。这些不一样的事，合起来是一件大事。
一个大的业务系统，拆分为小的业务模块，分别部署在不同的机器上。
解决了可伸缩、高可扩展

好处：

高性能
高可用
可伸缩
高可扩展

1.3、架构演进

单体架构

优点：简单：开发部署都很方便，小型项目首选
缺点：项目启动慢可靠性差可伸缩性差扩展性和可维护性差性能低

垂直架构

垂直架构是指将单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。

单体架构存在的问题：项目启动慢可靠性差可伸缩性差扩展性和可维护性差性能低
垂直架构可解决单体架构存在的问题
垂直架构存在的问题：重复功能太多

分布式架构

分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务，供其他调用者消费，以实现服务的共享和重用。

RPC： Remote Procedure Call

远程过程调用。有非常多的协议和技术来都实现了RPC的过程。比如：HTTP REST风格，Java RMI规范、WebService SOAP协议、Hession等等。

垂直架构存在的问题：重复功能太多
分布式架构存在的问题：服务提供方一旦产生变更，所有消费方都需要变更。比如服务提供方更改了ip、端口号，服务消费方也需要去更改。

SOA架构

SOA：（Service-Oriented Architecture，面向服务的架构）

是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。

ESB：(Enterparise Servce Bus) 企业服务总线，服务中介。

主要是提供了一个服务于服务之间的交互。ESB 包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。

分布式架构存在的问题：服务提供方一旦产生变更，所有消费方都需要变更

微服务架构

微服务架构是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想。

有ABC三个微服务，每个ABC都访问自己的数据库，他们相互之间是独立的、相互隔离的，（A访问B的数据库是不行的，只能访问自己的数据库），客户端通过统一组件网关来访问ABC这些微服务。

特点：

服务实现组件化：开发者可以自由选择开发技术。也不需要协调其他团队
服务之间交互一般使用REST API
去中心化：每个微服务有自己私有的数据库持久化业务数据
自动化部署：把应用拆分成为一个一个独立的单个服务，方便自动化部署、测试、运维

Dubbo 是 SOA时代的产物，SpringCloud 是微服务时代的产物

2、Dubbo概述

Dubbo 是一款高性能、轻量级的开源Java RPC框架，提供面向接口代理的高性能RPC调用、智能负载均衡、服务自动注册和发现、运行期流量调度、可视化服务治理和运维等功能。
Dubbo是阿里巴巴公司开源的一个高性能、轻量级的 Java RPC 框架。（现已经被apache开源）
致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。
官网：http://dubbo.apache.org
RPC（Remote Procedure Call）叫作远程过程调用，它是利用网络从远程计算机上请求服务，可以理解为把程序的一部分放在其他远程计算机上执行。通过网络通信将调用请求发送至远程计算机后，利用远程计算机的系统资源执行这部分程序，最终返回远程计算机上的执行结果。

过程：

0：start，服务提供者要启动

1：register，服务提供者启动后会将服务注册到注册中心

2：subscribe，服务消费方需要去注册中心发现服务，得到服务提供方注册的服务的ip、端口、服务调用地址。

3：notify机制、要一次给一次

4：invoke，服务消费方已经拿到服务了，rpc过程，去调用服务，dubbo内部自动实现

5：count，管理部署、服务监控、统计服务的调用次数和调用时间的监控中心

不同颜色线的区别：

init：初始化

async：异步

sync：同步

节点角色说明：

Provider：暴露服务的服务提供方
Container：服务运行容器
Consumer：调用远程服务的服务消费方
Registry：服务注册与发现的注册中心
Monitor：统计服务的调用次数和调用时间的监控中心（管理者）

3、Dubbo快速入门

Zookeeper安装

Zookeeper_小曹爱编程！的博客-CSDN博客Zookeeper：1、初识 Zookeeper；2、ZooKeeper 安装与配置；3、ZooKeeper 命令操作；4、ZooKeeper JavaAPI 操作；5、ZooKeeper 集群搭建；6、Zookeeper 核心理论https://blog.csdn.net/weixin_62993347/article/details/128440057?spm=1001.2014.3001.5502

Dubbo官方推荐使用Zookeeper作为注册中心

实现步骤：

创建服务提供者Provider模块
创建服务消费者Consumer模块
在服务提供者模块编写 UserServiceImpl 提供服务
在服务消费者中的 UserController 远程调用UserServiceImpl 提供的服务
分别启动两个服务，测试

依赖：

<!--Dubbo的起步依赖，版本2.7之后统一为rg.apache.dubb -->
        <dependency>
            <groupId>org.apache.dubbo</groupId>
            <artifactId>dubbo</artifactId>
            <version>2.7.4.1</version>
        </dependency>
        <!--ZooKeeper客户端实现 -->
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>4.0.0</version>
        </dependency>
        <!--ZooKeeper客户端实现 -->
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>4.0.0</version>
        </dependency>

UserServiceImpl 提供服务

//springframework包下的service
//@Service//将该类的对象创建出来，放到Spring的IOC容器中  bean定义

//dubbo包下的service
@Service//将这个类提供的方法（服务）对外发布。将访问的地址 ip，端口，路径注册到注册中心中

UserController 远程调用UserServiceImpl 提供的服务

//注入Service
//@Autowired//本地注入

/*
    1. 从zookeeper注册中心获取userService的访问url
    2. 进行远程调用RPC
    3. 将结果封装为一个代理对象。给变量赋值
*/
@Reference//远程注入
private UserService userService;

4、Dubbo高级特性

dubbo-admin

dubbo-admin 管理平台，是图形化的服务管理页面
从注册中心中获取到所有的提供者 / 消费者进行配置管理
路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能
dubbo-admin 是一个前后端分离的项目。前端使用vue，后端使用springboot
安装 dubbo-admin 其实就是部署该项目

dubbo常用高级配置

序列化

两个机器之间传输数据，如何传输Java对象？

使用序列化

将来所有的pojo类都需要实现Serializable接口

在pojo实体类上实现序列化接口 implements Serializable

dubbo 内部已经将序列化和反序列化的过程内部封装了
我们只需要在定义pojo类时实现Serializable接口即可
一般会定义一个公共的pojo模块，让生产者和消费者都依赖该模块。

地址缓存

注册中心挂了，服务是否可以正常访问？

可以，因为dubbo服务消费者在第一次调用时，会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心。
当服务提供者地址发生变化时，注册中心会通知服务消费者。因为有notify机制。

超时与重试

服务消费者在调用服务提供者的时候发生了阻塞、等待的情形，这个时候，服务消费者会一直等待下去。
在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积，势必会造成雪崩。

超时

服务消费者在调用服务提供者的时候发生了阻塞、等待的情形，这个时候，服务消费者会一直等待下去。
在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积，势必会造成雪崩。
dubbo 利用超时机制来解决这个问题，设置一个超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。
使用timeout属性配置超时时间，默认值1000，单位毫秒。
timeout属性即可以配置在服务提供方，也可以设置在服务消费方。
提供方@Service(timeout = 3000,retries = 3)当前服务三秒超时，retries：重试次数
消费方@Reference(timeout = 3000,retries = 3)

重试

设置了超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。
如果出现网络抖动，则这一次请求就会失败。
Dubbo 提供重试机制来避免类似问题的发生。
通过 retries 属性来设置重试次数。默认为 2 次。

注意：

超时与重试常常写在服务提供者，比如：
@Service(timeout = 3000,retries = 2)//当前服务3秒超时,重试2次，一共3次
也可以写在服务消费者的远程注入注解上
@Reference(timeout = 1000)//远程注入
但是写在服务消费者，超时与重试的内容会覆盖服务提供者的内容。即消费者的超时和重试生效。所以超时与重试建议写在服务的提供者！

多版本

灰度发布：当出现新功能时，会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。
dubbo 中使用version 属性来设置和调用同一个接口的不同版本。

服务提供者的版本
@Service(version = "v1.0")
@Service(version = "v2.0")
服务消费者选择使用版本
@Reference(version = "v2.0")//远程注入

负载均衡

负载均衡策略（4种）：

Random ：按权重随机，默认值。按权重设置随机概率。

服务提供者的配置权重
@Service(weight = 100)
服务消费者使用Random方式的负载均衡策略
@Reference(loadbalance = "random")//远程注入
RoundRobin ：按权重轮询
LeastActive：最少活跃调用数，相同活跃数的随机。
ConsistentHash：一致性 Hash，相同参数的请求总是发到同一提供者。（hash算法取余）

集群容错

集群容错模式：

Failover Cluster：失败重试。默认值。当出现失败，重试其它服务器，默认重试2次，使用 retries 配置。一般用于读操作
@Reference(cluster = "failover")//远程注入
Failfast Cluster ：快速失败，只发起一次调用，失败立即报错。通常用于写操作。写是要求幂等性的。
Failsafe Cluster ：失败安全，出现异常时，直接忽略。返回一个空结果。
Failback Cluster ：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster ：并行调用多个服务器，只要一个成功即返回。（耗性能）
Broadcast Cluster ：广播调用所有提供者，逐个调用，任意一台报错则报错。（对数据同步性要求高的）

服务降级

服务降级方式

能够实现服务降级方式很多，常见的有如下几种情况：

部分服务暂停
全部服务暂停
随机拒绝服务
部分服务延迟

Dubbo的服务降级采用的是mock机制。

mock只在出现非业务异常(比如超时，网络异常等)时执行。
mock配置在调用方，服务降级不需要对服务方配置产生修改。

Dubbo服务降级方式：

1、mock=force:return null 表示消费方对该服务的方法调用都直接返回null值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。可以很简单的忽略掉异常。
@Reference(mock = "force:return null")//不再去调用服务提供者提供的服务了
2、mock=fail:return null 表示消费方对该服务的方法调用在失败后，在返回null值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
@Reference(mock = "fail:return null")