Chiriri's blog
Iekr
2021-09-14
目录

Dubbo

# Dubbo

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

https://dubbo.apache.org/zh/ 下载

https://dubbo.apache.org/zh/docs/introduction/ 文档

# 集群和分布式

  • 集群 一个业务模块，部署在多台服务器上
  • 分布式 一个大的业务系统，拆分为小的业务模块，分别部署在不同的机器上

# 分布式的演进过程

  • 垂直架构 将多个模块拆分为多个独立项目 形成多个独立的单体架构 存在重复性功能太多
  • 分布式架构 在垂直架构基础上，将公共业务模块抽取出来，作为独立的服务 以实现服务的共享和重用 存在一旦产生变更 所有消费方都需要变更
  • SOA 架构 面向服务架构 是一个组件模型 它将应用程序的不同服务进行拆分 通过 ESB (企业服务总线) 服务中介 来进行服务之间的交互
  • 微服务架构 在 SOA 架构上做的升华 将原有的单个业务拆分为多个可以独立开发 设计 运行的小应用

image-20210914071530602

image-20210914071543680

# Dubbo 核心概念

# RPC

RPC (Remote Procedure Call) 是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。

它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

image-20231119234710197

image-20231119234742269

RPC 两个核心模块：通讯，序列化。

# 基本概念

image-20231119234948223

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

# IDEA 项目

坐标

 <!--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>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

applicationContext.xml 约束定义

xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"

http://dubbo.apache.org/schema/dubbo

http://dubbo.apache.org/schema/dubbo/dubbo.xsd

<?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://dubbo.apache.org/schema/dubbo" xmlns:context="http://www.springframework.org/schema/context"
	   xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd">


	<!--<context:component-scan base-package="com.itheima.service" />-->

	<!--dubbo的配置-->
	<!--1.配置项目的名称,唯一-->
	<dubbo:application name="dubbo-service"/>
	<!--2.配置注册中心的地址-->
	<dubbo:registry address="zookeeper://192.168.149.135:2181"/>
	<!--3.配置dubbo包扫描-->
	<dubbo:annotation package="com.itheima.service.impl" />

</beans>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

将 bean 绑定换成 dubbo 包下的

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

@Service//将这个类提供的方法（服务）对外发布。将访问的地址 ip，端口，路径注册到注册中心中
public class UserServiceImpl implements UserService {

    public String sayHello() {
        return "hello dubbo hello!~";
    }
}
1
2
3
4
5
6
7
8
9

@Autowired 注入换成远程注入 @Reference

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

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

     */

    @Reference//远程注入
    private UserService userService;
1
2
3
4
5
6
7
8
9
10
11
12

远程注入需要提供一个接口

  1. 要么在当前工程下 创建此接口
  2. 要么创建一个公共工程 专门存放远程注入接口的 让所有的工程都继承于公共工程

# Dubbo-admin

https://github.com/apache/dubbo-admin

下载发布版

  • 项目目录下 命令行 mvn clean package 打包完成后在 dubbo-admin-server 的 target 有 jar 包
  • 在 jar 包目录下 java -jar .\dubbo-admin-server-0.1.jar
  • 在 dubbo-admin-ui 先 npm install 或者 cnpm install 然后再 npm run dev

# 序列化

消费者和生产者 之间 传输对象 需要用到序列化和反序列化通过流来传输 实现序列化接口 Serializable

但 Dubbo 帮我们整合了 我们只需将全部 pojp 都实现接口 Serializable 既可

# 地址缓存

dubbo 服务消费者在第一次调用时，会将服务提供方地址缓存到本地，以后调用则不会访问注册中心

# 超时

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

在 @Service 或者 @Reference 中 当两个注解同时拥有 timeout 属性 则 @Reference 权重较高

设置 timeout 属性 值为毫秒数 默认为 1000 毫秒 超时则释放线程

或 xml 配置

消费端配置

<!-- 全局超时配置 -->
<dubbo:consumer timeout="5000" />

<!-- 指定接口以及特定方法超时配置 -->
<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>
1
2
3
4
5
6
7

服务端配置

<!-- 全局超时配置 -->
<dubbo:provider timeout="5000" />

<!-- 指定接口以及特定方法超时配置 -->
<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>
1
2
3
4
5
6
7
8

# 重试

设置了超时时间 在指定时间内 无法完成服务访问 则自动断开连接

如果出现网络抖动 则这一次请求就会失败

与超时设置一致

失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟

通过设置 retries 属性来设置重试次数 默认为 2 即当第一次超时后 重试 2 次如还是失败则断开连接

<!-- 重试次数配置如下： -->
<dubbo:service retries="2" />
<!-- 或 -->
<dubbo:reference retries="2" />
<!-- 或 -->
<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>
1
2
3
4
5
6
7
8

# 多版本

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

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

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

  • 灰度发布：当出现新的功能时，会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能

dubbo 使用 version 属性 设置版本

在 @Service 中设置 version 属性 @Service (version="v2.0")

然后在 @Reference 中设置指定版本号 @Reference (version="v1.0")

xml 版配置

<!-- 老版本服务提供者配置： -->
<dubbo:service interface="com.foo.BarService" version="1.0.0" />

<!-- 新版本服务提供者配置： -->
<dubbo:service interface="com.foo.BarService" version="2.0.0" />

<!-- 老版本服务消费者配置： -->
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />

<!-- 新版本服务消费者配置： -->
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

<!-- 如果不需要区分版本，可以按照以下的方式配置： -->
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 负载均衡

通过 @Reference 中设置属性 loadbalance 属性 @Reference (loadbalance ="random")

  • Random 按权重随机，默认值 按权重设置随机概率 权重通过 @Service (weight = 100) 设置
  • RoundRobin 按权重轮询
  • LeastActiove 最少活跃调用数，相同活跃的随机
  • ConsistentHash 一致性 Hash 相同参数的请求总是发到同一提供者

# 集群容错

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

通过 @Reference 中设置属性 culster 属性 @Reference (cluster = "Failover Cluster")

  • Failover Cluster: 失败重试. , 默认值 当出现失败 重试其他服务器 默认重试 2 此 使用 retries 配置 一般用于读操作

  • Failfast Cluster 快速失败 只发起一次调用 失败立即报错 通常用于写操作

  • Falisafe Cluster 失败安全 出现异常时 直接忽略 返回一个空结果

  • Failback Cluster 失败自动恢复 后台记录失败请求 定时重复

  • Foriking Cluster 并行调用多个服务器 只要一个成功即返回

  • Broadcast Cluster 广播调用所有提供者，逐个调用，任何一台报错则报错

xml 版配置

<dubbo:service cluster="failsafe" />
<!-- 或 -->
<dubbo:reference cluster="failsafe" />
1
2
3
4

# 服务降级

通过 @Reference 中设置属性 mock 属性 @Reference (mock = "")

  • force:return null 表示消费者对该服务的方法调用都直接返回 null 不发起远程调用
  • fail:return null 表示消费者对该服务的方法调用在失败后 再返回 null 值 不抛异常

# 添加事务

如果类添加了事务注解 则 @Service 需要指定实现的是哪个接口

@Service(interfaceClass = CheckItemService.class)
@Transactional
public class CheckItemServiceImpl implements CheckItemService {
}
1
2
3
4

# Dubbo 原理

# RPC 原理

image-20231120000314873

一次完整的 RPC 调用流程（同步调用，异步另说）如下：

  1. 服务消费方（client）调用以本地调用方式调用服务；
  2. client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
  3. client stub 找到服务地址，并将消息发送到服务端；
  4. server stub 收到消息后进行解码；
  5. server stub 根据解码结果调用本地的服务；
  6. 本地服务执行并将结果返回给 server stub；
  7. server stub 将返回结果打包成消息并发送至消费方；
  8. client stub 接收到消息，并进行解码；

RPC 框架的目标就是要 2~8 这些步骤都封装起来，这些细节对用户来说是透明的，不可见的。

# Netty 通信原理

Netty 是一个异步事件驱动的网络应用程序框架， 用于快速开发可维护的高性能协议服务器和客户端。它极大地简化并简化了 TCP 和 UDP 套接字服务器等网络编程。

image-20231120000623958

# BIO

BIO：(Blocking IO)

image-20231120000526657

# NIO

NIO (Non-Blocking IO)

image-20231120000548255

  • Selector 一般称 为选择器 ，也可以翻译为 多路复用器，
  • Connect（连接就绪）、Accept（接受就绪）、Read（读就绪）、Write（写就绪）

# 框架设计

image-20231120000700930

  • config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
  • proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory
  • registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
  • cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance
  • monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService
  • protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter
  • exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
  • transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
  • serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

# 启动解析、加载配置信息

image-20231120000819292

# 服务暴露

image-20231120000848575

# 服务引用

image-20231120000909968

编辑 (opens new window)
上次更新: 2023/12/06, 01:31:48
Maven 高级
Zookeeper

← Zookeeper→

最近更新
01
k8s
06-06
02
进程与线程
03-04
03
计算机操作系统概述
02-26
更多文章>
Theme by Vdoing | Copyright © 2022-2025 Iekr | Blog