分布式之dubbo3

最新推荐文章于 2024-07-20 00:05:47 发布

一只经常emo的程序员

最新推荐文章于 2024-07-20 00:05:47 发布

阅读量959

点赞数 23

分类专栏：分布式文章标签：分布式

本文链接：https://blog.csdn.net/jbjmh/article/details/139611594

版权

分布式专栏收录该内容

34 篇文章 1 订阅

订阅专栏

1、什么是Dubbo3

Apache Dubbo 是一款易用、高性能的 WEB 和 RPC 框架，同时为构建企业级微服务提供服务发现、流量治理、可观测、认证鉴权等能力、工具与最佳实践。

“Dubbo3 已在阿里巴巴内部微服务集群全面落地，成功取代运行多年的 HSF 框架。”

2、构建Dubbo3脚手架

2.1 框架依赖

Maven
SpringCloud 2.6.11
Dubbo 3.1.8 + zookeeper 3.4.14

2.2 搭建Zookeeper

解压
修改zk的配置文件

进入conf，将文件zoo_sample.cfg 改为zoo.cfg
测试zk

启动zookeeper

执行zookeeper根目录下，bin文件中的zkServer.cmd

上面的CMD窗口不要关闭，这样zookeeper就是出于运行状态了

2.3 创建工程

2.3.1 创建父工程

mdb-dubbo-ann

父工程控制版本:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.6.11</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <modules>
        <module>dubbo-consumer</module>
        <module>dubbo-provider</module>
        <module>dubbo-common</module>
    </modules>
    <groupId>com.msb</groupId>
    <artifactId>msb-dubbo-ann</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>msb-dubbo-ann</name>
    <packaging>pom</packaging>
    <description>Demo project for Spring Boot</description>

    <properties>
        <java.version>1.8</java.version>
        <dubbo-version>3.1.8</dubbo-version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
        </dependency>
    </dependencies>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.apache.dubbo</groupId>
                <artifactId>dubbo-spring-boot-starter</artifactId>
                <version>${dubbo-version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.dubbo</groupId>
                <artifactId>dubbo-rpc-dubbo</artifactId>
                <version>${dubbo-version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.dubbo</groupId>
                <artifactId>dubbo-registry-zookeeper</artifactId>
                <version>${dubbo-version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

</project>

2.3.2 创建提供者

dubbo-provider

引入依赖：

<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
</dependency>
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-rpc-dubbo</artifactId>
</dependency>
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-registry-zookeeper</artifactId>
</dependency>

增加配置

server:
  port: 8002
logging:
  config: classpath:logback.xml
dubbo:
  application:
    name: dubbo-provider
  protocol:
    name: dubbo
    #客户端链接20880就可以访问我们的dubbo
    port: 20883
  registry:
    address: zookeeper://127.0.0.1:2181

更改主类

import org.apache.dubbo.config.spring.context.annotation.EnableDubbo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.ImportResource;
// 因为是自动装配也可以不加这个注解
@EnableDubbo(scanBasePackages = "com.msb.dubbo.provider.service")
@SpringBootApplication
public class DubboProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(DubboProviderApplication.class);
    }
}

接着增加通信端口

public interface IUserService {
    User getUserById(Long id);
}

@Data
@AllArgsConstructor
@Builder
public class User implements Serializable {
    private static final long serialVersionUID = 1L;

    private Long id;
    private String name;
    private int age;

}

增加实现类

@DubboService// 定义一个dubbo服务
public class UserServiceImpl implements IUserService {
    @Override
    public User getUserById(Long id) {
        User user = User.builder().id(id)
                .age(12)
                .name("天涯")
                .build();
        return user;
    }

2.3.3 创建客户端

引入依赖

<!--这里是dubbo和SpringBoot桥梁的整合-->
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
</dependency>
<!--每一种协议都会对应的一个jar比方：dubbo、rest、tripe 三种协议-->
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-rpc-dubbo</artifactId>
</dependency>
<!--注册中心可以是zk,nacos -->
<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-registry-zookeeper</artifactId>
</dependency>

更改配置

server:
  port: 8001
logging:
  config: classpath:logback.xml
dubbo:
  application:
    name: dubbo-consumer
  registry:
    address: zookeeper://127.0.0.1:2181

更改主类

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

增加调用接口

public interface IUserService {
    User getUserById(Long id);
}

@Data
@AllArgsConstructor
@Builder
public class User implements Serializable {
    private static final long serialVersionUID = 1L;

    private Long id;
    private String name;
    private int age;

}

增加业务调用处理

@RestController
public class OrderController {
    @Autowired
    private OrderService orderService;

    @RequestMapping("/createOrder/{userId}")
    public String createOrder(@PathVariable("userId") Long userId){
        return orderService.createOrder(userId);
    }
}

@Slf4j
@Service
public class OrderService {
    // 引用对应的dubbo服务
    @DubboReference
    private IUserService iUserService;
    public String createOrder(Long userId){
        User user = iUserService.getUserById(userId);
        log.info("用户用户信息：{}",user);
        return "创建订单成功";
    }
}

2.3.4 测试

http://localhost:8001/createOrder/232

2.3.5 重构创建公共模块

dubbo-common 存放IUserService 和User

提供端和消费端

<dependency>
    <groupId>com.msb</groupId>
    <artifactId>dubbo-common</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</dependency>

2.3.6 测试

http://localhost:8001/createOrder/232

2.4 开启rest协议

如果我们的服务希望既要支持dubbo协议调用，也要能支持http调用，所以，要么仍然保留SpringMVC那一套，如果不想保留那一套，就可以开启 dubbo中的rest协议。

2.4.1 增加依赖

<dependency>
    <groupId>org.apache.dubbo</groupId>
    <artifactId>dubbo-rpc-rest</artifactId>
</dependency>

2.4.2 更改配置

dubbo:
  application:
    name: dubbo-provider
  # 这里的协议加了s,所以可以设置多个通信协议
  protocols:
    p1:
      name: dubbo
      #客户端链接20883就可以访问我们的dubbo
      port: 20883
    p2:
      name: rest
      #客户端链接20884就可以访问我们的rest
      port: 20884

2.4.3 更改对应代码服务

@DubboService// 定义一个dubbo服务
@Path("/user")
public class UserServiceImpl implements IUserService {
    @GET
    @Path("/{userId}")
    @Produces(MediaType.APPLICATION_JSON)
    @Override
    public User getUserById(@PathParam("userId") Long userId) {
        User user = User.builder().id(userId)
                .age(12)
                .name("天涯")
                .build();
        return user;
    }

}

2.4.4 测试

在消费端增加RestTemplate

@EnableDubbo
@SpringBootApplication
public class DubboConsumeApplication {

    @Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
    public static void main(String[] args) {
        SpringApplication.run(DubboConsumeApplication.class);
    }
}

@Slf4j
@Service
public class OrderService {
    @DubboReference
    private IUserService iUserService;

    @Autowired
    RestTemplate restTemplate;
    public String createOrder(Long userId){
        User user = restTemplate.getForObject("http://localhost:20884/user/232",User.class);
        log.info("用户用户信息：{}",user);
        return "创建订单成功";
    }
}

http://localhost:8001/createOrder/232

2.4.5 使用接口调用Rest

将rest协议放到common中

 <dependency>
            <groupId>org.apache.dubbo</groupId>
            <artifactId>dubbo-rpc-rest</artifactId>
        </dependency>

修改IUserService

@Path("/user")
public interface IUserService {
    @GET
    @Path("/{userId}")
    @Produces(MediaType.APPLICATION_JSON)
    User getUserById(@PathParam("userId") Long id);
}

修改consume里面内容

@Slf4j
@Service
public class OrderService {
    // 指定写协议
    @DubboReference(protocol = "rest")
    private IUserService iUserService;

    @Autowired
    RestTemplate restTemplate;
    public String createOrder(Long userId){
        User user = iUserService.getUserById(userId);
        log.info("用户用户信息：{}",user);
        return "创建订单成功";
    }
}

如果我们不能确定是否是走的http，我们可以DispatcherServlet#service 里面打个端点，看是否进入

3、Dubbo3 架构

4、服务注册

4.1 Zookeeper注册数据基本结构

我们可以用zkCli.cmd来链接服务，查看对应的节点，我们可以想象成一个一个的文件夹，

使用ZooInspector来查看对应的节点

4.2 接口级注册

在这个过程中：

每个 Provider 通过特定的 key 向注册中心注册本机可访问地址；
注册中心通过这个 key 对 provider 实例地址进行聚合；
Consumer 通过同样的 key 从注册中心订阅，以便及时收到聚合后的地址列表；

4.2.1 数据结构

4.1.2 接口易用性代价

一个事物总是有其两面性，Dubbo2 地址模型带来易用性和强大功能的同时，也给整个架构的水平可扩展性带来了一些限制。这个问题在普通规模的微服务集群下是完全感知不到的，而随着集群规模的增长，当整个集群内应用、机器达到一定数量时，整个集群内的各个组件才开始遇到规模瓶颈。在总结包括阿里巴巴、工商银行等多个典型的用户在生产环境特点后，我们总结出以下两点突出问题（如图中红色所示）：

首先，注册中心集群容量达到上限阈值。由于所有的 URL 地址数据都被发送到注册中心，注册中心的存储容量达到上限，推送效率也随之下降。
而在消费端这一侧，Dubbo2 框架常驻内存已超 40%，每次地址推送带来的 cpu 等资源消耗率也非常高，影响正常的业务调用。

为什么会出现这个问题？我们以一个具体 provider 示例进行展开，来尝试说明为何应用在接口级地址模型下容易遇到容量问题。青蓝色部分，假设这里有一个普通的 Dubbo Provider 应用，该应用内部定义有 10 个 RPC Service，应用被部署在 100 个机器实例上。这个应用在集群中产生的数据量将会是 “Service 数 * 机器实例数”，也就是 10 * 100 = 1000 条。数据被从两个维度放大：

从地址角度。100 条唯一的实例地址，被放大 10 倍
从服务角度。10 条唯一的服务元数据，被放大 100 倍

4.3 应用级注册

那这样 1个服务有10个服务接口 100个实例对应数据应该

mapping里面有 10条 services 里面就100 条总共是110条

这里元数据可以放到元数据中心（可以和注册中心一样），也可以放到本地，消费者获取需要发送rpc调用

默认发送本地，对应配置

4.4 Provider和Consumer双版本支持参数讲解

Provicer提供方

dubbo.application.register-mode

参数	参数含义
interface	只有接口级注册
instance	只有应用级注册
all（默认）	接口级注册和应用级注册并存

Consumer消费方

dubbo.application.service-discovery.migration:FORCE_INTERFACE

参数	参数含义
FORCE_INTERFACE	只消费接口级地址，如无地址则报错，单订阅2.x地址
APPLICATION_FIRST(默认)	智能决策接口级/应用级地址，双订阅
FORCE_APPLICATION	只消费应用级地址，如无地址则报错，单订阅3.x地址

4.5 为什么Dubbo3支持双版本注册

为了方便迁移， Dubbo3.0之前都是接口级别注册，Dubbo3之后都是应用级注册

5、服务注册源码分析

5.1 服务启动

找入口是@EnableDubbo

5.1.1 注册DubboDeployApplicationListener

这里监听器是监听Spring容器启动之后，我们再进行服务注册，不符订阅，应用注册，启动本地服务

5.1.2 扫描我们@DubboService 注册BeanDefinition

DubboComponentScanRegistrar 执行的时候会调用registerBeanDefinitions

注册后置处理器ServiceAnnotationPostProcessor

ServiceAnnotationPostProcessor 实现BeanDefinitionRegistryPostProcessor则进行BeanDefintion的注册

注册userServiceImpl

注册ServieBean的BeanDefinition

5.1.3 加载配置文件

配置的加载

5.2 服务导出

面试题：Dubbo3是什么时候进行服务导出的？

Dubbo3通过DubboDeployApplicationListener监听Spring的启动，当Spring启动会发送ContextRefreshedEvent事件，DubboDeployApplicationListener监听这个事件进行服务导出，会把我们服务注册到注册中心，并且启动本地服务。

问题：服务导出：获取服务配置 + 服务注册（服务） + 启动服务（Netty/Tomcat），那先注册再启动，还是先启动再注册？

先启动再注册，如果先注册再启动，那么注册完还没有启动的时候，别的服务就调用进来这就会出现调用失败

这里注意有接口级的注册和应用的注册

5.2.1 入口分析

我们通过DubboDeployApplicationListener

如下图这里就是核心内容

5.2.2 接口级注册

5.2.2.1 判断注册方式

exportServices是进行接口级注册，由于他的调用链路比较长我们直接来到 ServiceConfig#doExportUrls

通过配置的模式获取对应注册地址

可以看到这里简化的配置比较容易理解了

双注册模式配置查询对应参数为dubbo.application.register-mode ，默认值为all
如果用户配置了接口注册模式配置则只走接口级配置这里默认值为interface
满足应用级注册就添加一个应用级注册的地址
满足接口级注册配置就添加一个接口级注册地址

这个方法是根据服务注册模式来判断使用接口级注册地址还是应用级注册地址分别如下所示：配置信息： dubbo.application.register-mode 配置值：

interface
- 接口级注册
instance
- 应用级注册
all
- 接口级别和应用级都注册

最终的注册地址配置如下：接口级注册地址

registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=9008&registry=zookeeper&release=3.0.8&timestamp=1653703292768

应用级注册地址：

service-discovery-registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=10275&registry=zookeeper&release=3.0.8&timestamp=1653704425920

前面说了这个注册服务的配置地址会由Dubbo内部进行判断如果判断是all的话会自动将一个配置的注册地址转变为两个一个是传统的接口级注册，一个是应用级注册使用的配置地址

5.2.2.2 生成invoke

我们来看key1:获取对应的invoke

然后我们再看注册中心，注册服务数据的源码如果想要查看源码细节可以在RegistryProtocol类型的export(final Invoker originInvoker) 方法的如下代码位置打断点：

RegistryProtocol的export方法的注册中心注册数据代码如下:

1、暴露本地服务，就是提供给调用方一个调用的接口服务，这个我们后面来说

2、获取注册Registry ，这里如果是接口级注册则是ZookeeperRegistry，如果应用级注册：ServiceDiscoveryRegistry

3、我们看一下registry

5.2.2.3 接口级注册

我们再ZookeeperRegistry#doRegistry打上端点

堆栈信息中我们可以看到调用它的方法是

5.2.2.4 应用级注册：将服务提供者数据转换到本地内存的元数据信息中

5.2.2.5 映射数据注册（应用）

5.2.3 应用级注册

5.2.3.1 应用元数据信息注册

5.2.3.2 实例信息

这里最终会调用到ZookeeperServiceDiscovery#doRegister

6、本地服务暴露

那我们注意点如果是dubbo我们应该用netty绑定一个端口

这里最终会调用到 NettyServer#doOpen

7、Consumer的订阅服务

7.1 订阅入口

来到关键入口类DefaultModuleDeployer#startSync 方法

这里分两点：1、是创建一个远程调用 invoke，2、创建代理类

我们先看第1点

7.2 接口级订阅

这里我们进入选择应用级订阅、接口级订阅、应用和接口级订阅，我们进入应用和接口级订阅

首先进入接口级订阅：

最终会到 FailbackRegistry#subscribe

上面是进行目录创建，有则忽略，没有则创建，让后给子节点增加监听器

最后将数据urls放到缓存

7.3 应用级订阅

这里我们进入选择应用级订阅、接口级订阅、应用和接口级订阅，我们进入应用和接口级订阅

应用级订阅

最终会调用到ServiceDiscoveryRegistry#doSubscribe

这里面设计到两个关键点、

1、获取接口对应的应用名称

2、subscribedServices为接口所对应的应用名，接下来就会取获取该应用的所有实例

获取对应实例的元数据信息

循环发送事件ServiceInstancesChangedEvent，ServiceInstancesChangedListener#onEvent获取对应事件来获取对应的元数据信息

这里我们重点分析一下从远端获取数据

7.4 智能选择接口级还是应用级

如果应用级注册为空，接口级注册不为空，则是使用接口级注册

如果接口级注册为空，应用级注册不为空，则是使用应用级注册

如果接口级和应用级都不为空，则用应用级

7.5 创建代理类

最终回到用到JavassistProxyFactory

7.6 @DubboReference标注对象的引入

我们看一下ReferenceAnnotationBeanPostProcessor的继承关系

它继承BeanFactoryPostProcessor,所以他一定为实现postProcessBeanFactory

后面会将@DubboReference标注类对应的BeanDefinition进行实例化，我们看一下对应class类ReferenceBean

问题：我们如果想往IOC容器中注入一个对象应该怎样处理

使用@Bean进行方法的标注或者实现接口FactoryBean

所以此时应该关注ReferenceBean#getObject

所以在服务调用的时候才创建代理类进行调用

8、Dubbo协议服务调用

8.1 服务端启动过程深入分析

我们查看一下服务启动的过程

ProtocolFilterWrapper.export

好我们进入DubboProtocol.export

创建服务

分析我们的Handler

我们接着返回刚才位置

下面的super方法里面会创建服务，ChannelHandlers.wrap会对hander进一步包装

1、我们进入ChannelHandlers.wrap

MultiMessageHandler—>HeartbeatHandler---->AllChannelHandler -> DecodeHandler -> HeaderExchangeHandler -> ExchangeHandlerAdapter

我看看一下super创建服务

NettyServerhandler -> NettyServer -> MultiMessageHandler—>HeartbeatHandler---->AllChannelHandler -> DecodeHandler -> HeaderExchangeHandler -> ExchangeHandlerAdapter

8.2 服务端调用过程

我们知道请求过来通过Netty服务一定是Handler的处理,下面就是整个过程

NettyServerHandler -> NettyServer -> MultiMessageHandler—>HeartbeatHandler---->AllChannelHandler -> DecodeHandler -> HeaderExchangeHandler -> ExchangeHandlerAdapter

NettyServerHandler

MultiMessageHandler

HeartbeatHandler

AllChannelHandler

https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/advanced-features-and-usage/performance/threading-model/provider/

DecodeHandler

HeaderExchangeHandler

ExchangeHandlerAdapter

这里是调用我们的目标invoker，但是这里目标invoker被filter给包装了，所以先要调用filter

我们自定义过滤器就会在这里起作用

调用完毕过滤器就会调用到AbstractProxyInvoker#invoke

8.3 客户端调用

会调用JavassistProxyFactory#getProxy获取代理类

调用的时候一定会调用到InvokerInvocationHandler.invoker的方法

调用过程会有容错负载均衡FailoverClusterInvoker#doInvoke

HeaderExchangeHandler#received处理返回数据

9、Triple协议

9.1 背景

在Dubbo2.7中，默认的是Dubbo协议，因为Dubbo协议相比较于Http1.1而言，Dubbo协议性能上是要更好的。

但是Dubbo协议自己的缺点就是不通用，假如现在通过Dubbo协议提供了一个服务，那如果想要调用该服务就必须要求服务消费者也要支持Dubbo协议。

而随着企业的发展，往往可能会出现公司内部使用多种技术栈，可能这个部门使用Dubbo，另外一个部门使用Spring Cloud，另外一个部门使用gRPC，那此时部门之间要想相互调用服务就比较复杂了，所以需要一个通用的、性能也好的协议，这就是Triple协议。

9.2 Triple协议介绍

Triple 是 Dubbo3 提出的基于 HTTP2 的开放协议，旨在解决 Dubbo2 私有协议带来的互通性问题。另外，Google公司开发的gRPC，也基于的HTTP2，目前gRPC是云原生事实上协议标准，包括k8s/etcd等都支持gRPC协议。

9.3 HTTP1 和HTTP2进行对比

9.3.1 HTTP1

POST /getName HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

username=john&password=1234

我们会发现我们除了username=john&password=1234 数据之外，其他的内容都是额外信息，并且这些额外信息量很大。

9.3.2 HTTP2

帧长度，用三个字节来存一个数字，这个数字表示当前帧的实际传输的数据的大小，3个字节表示的最大数字是2

的24次方（16M），所以一个帧最大为9字节+16M。
帧类型，占一个字节，可以分为数据帧和控制帧
1. DATA：用于传输请求和响应中的数据，包含有效载荷（payload）。
2. HEADERS：用于传输HTTP头部信息，包含有效载荷（payload）。
3. PRIORITY：用于指定数据流的优先级，包含与数据流相关的信息。
4. RST_STREAM：用于指示数据流的中止，并通知原因。
5. SETTINGS：用于传输HTTP/2连接的配置参数。
6. PUSH_PROMISE：用于服务端推送资源，包含预期的请求头和有效载荷。
7. PING：用于检测HTTP/2连接的可用性和延迟时间。
标志位，占一个字节，可以用来表示当前帧是整个请求里的最后一帧，方便服务端解析、
流标识符，占4个字节，在Java中也就是一个int，不过最高位保留不用，表示Stream ID，这也是HTTP2的一个重要设计
实际传输的数据Payload，如果帧类型是HEADERS，那么这里存的就是请求头，如果帧类型是DATA ，那么这里

存的就是请求体

通过这种设计，我们可以发现，我们就可以来压缩请求头了，比如如果帧的类型是HEADERS ，那就进行压缩，当然压缩算法是固定的HPACK算法，不能更换。

9.4 Triple源码分析

通过学习Dubbo协议，我们首先要知道我们启动服务的应该是在TripleProtocol

9.4.1 客户端处理

调到TripleInvoker.doInvoke

这里我们数据会放到队列，最后会调用到HeaderQueueCommand#doSend方法，发送数据

放入队列

先放到队列，然后会定时flush的时候进行处理

下面我们可以看到，当我发现有数据就会一直取知道128个后才发送，如果poll为空，则走下面内容数据不为空则发送

刷新后则调用到HeaderQueueCommand#doSend方法

下面发送请求体和完成，与上面发送请求头都是异步处理，代码一样只是最后调用处理不同

上图我们可以看出，也是异步处理，最终会调用到DataQueueCommand#doSend方法

发送完成数据

最终会调用感到EndStreamQueueCommand.doSend方法

9.4.2 服务端启动

进入启动Netty的源码

这里有个处理器NettyPortUnificationServerHandler，我们这里有的decode方法，他会识别我们是不是HTTP2协议

怎样识别HTTP2协议？

如果要建立的是一个HTTP2连接，那么在建立完Socket连接后,客户端立刻会发送一个连接前言，也就是一串字节

(对应的字符串为:“PRI*HTTP/2.0\r\n\r\nSM\r\n\r\n”)，给到服务端，服务端从而知道要建立的是HTTP2

如果识别出RECOGNIZED，

处理数据

处理请求头

获取invoker

启动监听器

这里处理请求头获取了Invoker和对应的listener:UnaryServerCallListener 处理请求内容中会用到

处理请求

处理请求体

这里只是给我们invoker设置了参数，但是没有立刻调用，而是在complete中进行调用

处理完成帧

10、扩展点SPI

10.1 概念

SPI是一种软件编程模型，用于实现在运行时动态加载和扩展组件的能力。在Dubbo3中，SPI机制被广泛应用于扩展框架功能，允许用户自定义实现各种接口，以满足业务需求。

Java中的SPI机制

我们使用Mybatis操作数据库，那我们应该使用怎样操作mysql 或者oracle或者DB2呢？首先我们应该引入对应的Mysql的jar，我们利用这jar才能操作数据库，那对于JDBC操作DriveMananger获取链接的时候，他怎样获取Mysql的jar包中对应的类，来链接mysql呢

实例：

加载对应的配置

缺点：我们如果对应配置文件中com.msb.dubbo.provider.SPI.JDK.Course配置多个实现类，但是我们只需要EnglishCourse，所以为了效率我们只应该加载EnglishCourse，但是JDK的SPI会把所有的加载掉，所以Dubbo退出自己的SPI

Dubbo3 SPI演示

Wrapper包装（AOP）

10.2源码分析

一只经常emo的程序员

关注

23
点赞
踩
26

收藏

觉得还不错? 一键收藏
打赏
0
评论
分布式之dubbo3

Triple 是 Dubbo3 提出的基于 HTTP2 的开放协议，旨在解决 Dubbo2 私有协议带来的互通性问题。另外，Google公司开发的gRPC，也基于的HTTP2，目前gRPC是云原生事实上协议标准，包括k8s/etcd等都支持gRPC协议。
复制链接

扫一扫