Dubbo学习

最新推荐文章于 2023-11-01 12:06:37 发布

秃头的二哈

最新推荐文章于 2023-11-01 12:06:37 发布

阅读量616

点赞数 1

分类专栏： Java后端学习文章标签： dubbo 学习分布式

本文链接：https://blog.csdn.net/hanpiyo/article/details/128692167

版权

Java后端学习专栏收录该内容

5 篇文章 0 订阅

订阅专栏

1.概念

1.1 Dubbo特性

面向接口代理的高性能RPC调用
- 两个服务器直接互相调用只需要调用接口即可，Dubbo会自动匹配对应的底层代码
智能负载均衡
- 当用户调用同一个业务的服务器时候，会选择负载量少的服务器进行调用，防止浪费资源
服务自动注册与发现
- 因为客户端不知道某个服务器属于什么业务模块，所以dubbo相当于有个注册中心，将服务器所属功能模块列成一个清单

在这里插入图片描述

高可扩展能力
- 遵循微内核+插件的设计原则，所以其核心都是可以扩展的
运行期流量调度
- 通过流量调度实现灰度发布（指的是当有新服务的时候，先让一部分服务器去实现新服务，然后再慢慢过渡到全部服务器去实现新服务）
可视化的服务治理与运维

1.2 设计架构

在这里插入图片描述

在传统的部署架构下，服务发现涉及提供者、消费者和注册中心三个参与角色，其中，提供者注册 URL 地址到注册中心，注册中心负责对数据进行聚合，消费者从注册中心订阅 URL 地址更新。在云原生背景下，比如当应用部署在 Kubernetes 等平台，由于平台自身维护了应用/服务与实例间的映射关系，因此注册中心与注册动作在一定程度上被下沉到了基础设施层，因此框架自身的注册动作有时并不是必须的。

2.快速开始

2.1需求假设

某个电商系统，订单服务需要调用用户服务获取某个用户的所有地址

模块	功能
订单服务web模块	创建订单等
用户服务service模块	查询用户地址等

预期结果：订单服务web模块在A服务器，用户服务模块在B服务器，A可以远程调用B的功能

2.2.工程架构

分包：
- 建议将服务接口，服务模型，服务异常等均放在 API 包中，因为服务模型及异常也是 API 的一部分，同时，这样做也符合分包原则：重用发布等价原则(REP)，共同重用原则(CRP)。
- 如果需要，也可以考虑在 API 包中放置一份 spring 的引用配置，这样使用方法，只需在 spring 加载过程中引用此配置即可，配置建议放在模块的包目录下，以免冲突
粒度：
- 服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。
- 服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。

在这里插入图片描述

2.3 创建模块

2.3.1 gmall-interface—公共接口层

Bean模型

public class UserAddress implements Serializable{
    private Integer id;
    private String userAddress;
    private String userId;
    private String consignee;
    private String phoneNum;
    private String isDefault;
}

Service接口

UserService
public List<UserAddress> getUserAddressList(String userId)

在这里插入图片描述

2.3.2 gmall-user—用户模块

导入相应的依赖

<dependencies>
  	<dependency>
  		<groupId>com.atguigu.dubbo</groupId>
  		<artifactId>gmall-interface</artifactId>
  		<version>0.0.1-SNAPSHOT</version>
  	</dependency>
  </dependencies>

编写业务实现类

public class UserServiceImpl implements UserService {
		
	@Override
	public List<UserAddress> getUserAddressList(String userId) {
		// TODO Auto-generated method stub
		return userAddressDao.getUserAddressById(userId);
	}

}

2.3.3 gmall-order-web—订单模块

导入相应依赖

<dependencies>
  	<dependency>
  		<groupId>com.atguigu.dubbo</groupId>
  		<artifactId>gmall-interface</artifactId>
  		<version>0.0.1-SNAPSHOT</version>
  	</dependency>
   </dependencies>

测试

public class OrderService {
	
	UserService userService;
	
	/**
	 * 初始化订单，查询用户的所有地址并返回
	 * @param userId
	 * @return
	 */
	public List<UserAddress> initOrder(String userId){
		return userService.getUserAddressList(userId);
	}

}

2.3.4 测试结果

现在这样是无法进行调用的。我们gmall-order-web引入了gmall-interface，但是interface的实现是gmall-user，我们并没有引入，而且实际他可能还在别的服务器中。

2.3.5 使用Dubbo改造

将gmall-user改造作为服务提供者

引入dubbo

<!-- 引入dubbo -->
		<dependency>
			<groupId>com.alibaba</groupId>
			<artifactId>dubbo</artifactId>
			<version>2.6.2</version>
		</dependency>
	<!-- 由于我们使用zookeeper作为注册中心，所以需要操作zookeeper
dubbo 2.6以前的版本引入zkclient操作zookeeper 
dubbo 2.6及以后的版本引入curator操作zookeeper
下面两个zk客户端根据dubbo版本2选1即可
-->
		<dependency>
			<groupId>com.101tec</groupId>
			<artifactId>zkclient</artifactId>
			<version>0.10</version>
		</dependency>
		<!-- curator-framework -->
		<dependency>
			<groupId>org.apache.curator</groupId>
			<artifactId>curator-framework</artifactId>
			<version>2.12.0</version>
		</dependency>

配置提供者

<!--当前应用的名字  -->
	<dubbo:application name="gmall-user"></dubbo:application>
	<!--指定注册中心的地址  -->
    <dubbo:registry address="zookeeper://118.24.44.169:2181" />
    <!--使用dubbo协议，将服务暴露在20880端口  -->
    <dubbo:protocol name="dubbo" port="20880" />
    <!-- 指定需要暴露的服务 -->
    <dubbo:service interface="com.atguigu.gmall.service.UserService" ref="userServiceImpl" />

启动服务

public static void main(String[] args) throws IOException {
		ClassPathXmlApplicationContext context = 
				new ClassPathXmlApplicationContext("classpath:spring-beans.xml");
		
		System.in.read(); 
	}

2.将gmall-order-web改造为服务消费者

引入dubbo

<!-- 引入dubbo -->
		<dependency>
			<groupId>com.alibaba</groupId>
			<artifactId>dubbo</artifactId>
			<version>2.6.2</version>
		</dependency>
	<!-- 由于我们使用zookeeper作为注册中心，所以需要引入zkclient和curator操作zookeeper -->
		<dependency>
			<groupId>com.101tec</groupId>
			<artifactId>zkclient</artifactId>
			<version>0.10</version>
		</dependency>
		<!-- curator-framework -->
		<dependency>
			<groupId>org.apache.curator</groupId>
			<artifactId>curator-framework</artifactId>
			<version>2.12.0</version>
		</dependency>

配置消费者信息

<!-- 应用名 -->
	<dubbo:application name="gmall-order-web"></dubbo:application>
	<!-- 指定注册中心地址 -->
	<dubbo:registry address="zookeeper://118.24.44.169:2181" />
	<!-- 生成远程服务代理，可以和本地bean一样使用demoService，interface也是上面服务提供者所暴露的接口位置 -->
	<dubbo:reference id="userService" interface="com.atguigu.gmall.service.UserService"></dubbo:reference>

3.测试

访问gmall-order-web的initOrder请求，会调用UserService获取用户地址；

调用成功。说明我们order已经可以调用远程的UserService了

2.3.6 注解版

1、服务提供方

<dubbo:application name="gmall-user"></dubbo:application>
<dubbo:registry address="zookeeper://118.24.44.169:2181" />
<dubbo:protocol name="dubbo" port="20880" />
<dubbo:annotation package="com.atguigu.gmall.user.impl"/>
import com.alibaba.dubbo.config.annotation.Service;
import com.atguigu.gmall.bean.UserAddress;
import com.atguigu.gmall.service.UserService;
import com.atguigu.gmall.user.mapper.UserAddressMapper;

@Service //使用dubbo提供的service注解，注册暴露服务
public class UserServiceImpl implements UserService {

	@Autowired
	UserAddressMapper userAddressMapper;

2、服务消费方

<dubbo:application name="gmall-order-web"></dubbo:application>
<dubbo:registry address="zookeeper://118.24.44.169:2181" />
<dubbo:annotation package="com.atguigu.gmall.order.controller"/>

@Controller
public class OrderController {
@Reference  //使用dubbo提供的reference注解引用远程服务
UserService userService;

3.监控中心

1.监控中心配置

所有服务配置连接监控中心，进行监控统计
    <!-- 监控中心协议，如果为protocol="registry"，表示从注册中心发现监控中心地址，否则直连监控中心 -->
	<dubbo:monitor protocol="registry"></dubbo:monitor>

Simple Monitor 挂掉不会影响到 Consumer 和 Provider 之间的调用，所以用于生产环境不会有风险。

Simple Monitor 采用磁盘存储统计信息，请注意安装机器的磁盘限制，如果要集群，建议用mount共享磁盘。

4.整合SpringBoot

1.引入spring-boot-starter以及dubbo和curator的依赖

<dependency>
    <groupId>com.alibaba.boot</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>0.2.0</version>
</dependency>

2.配置提供者

dubbo.application.name=gmall-user
dubbo.registry.protocol=zookeeper
dubbo.registry.address=192.168.67.159:2181
dubbo.scan.base-package=com.atguigu.gmall
dubbo.protocol.name=dubbo
application.name就是服务名，不能跟别的dubbo提供端重复
registry.protocol 是指定注册中心协议
registry.address 是注册中心的地址加端口号
protocol.name 是分布式固定是dubbo,不要改。
base-package  注解方式要扫描的包

3.配置消费者

dubbo.application.name=gmall-order-web
dubbo.registry.protocol=zookeeper
dubbo.registry.address=192.168.67.159:2181
dubbo.scan.base-package=com.atguigu.gmall
dubbo.protocol.name=dubbo

4.dubbo注解

@Service（要暴露服务用该注解）、@Reference（需要远程调用来消费服务）

【如果没有在配置中写dubbo.scan.base-package,还需要使用@EnableDubbo注解】

5.Dubbo配置

5.1 配置原则

在这里插入图片描述

配置生效优先级：

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

5.2 启动时检查

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。（服务提供者没启动就启动消费者就会报错）

可以通过 check="false" 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

关闭某个服务的启动时检查

<dubbo:reference interface="com.foo.BarService" check="false" />

关闭所有服务的启动时检查

<dubbo:consumer check="false" />

关闭注册中心启动时检查

<dubbo:registry check="false" />

5.3超时配置

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

5.3.1 Dubbo消费端

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

指定接口以及特定方法超时配置
<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

5.3.2 Dubbo服务端

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

指定接口以及特定方法超时配置
<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>

5.3.3 配置原则

dubbo推荐在Provider上尽量多配置Consumer端属性：

1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

2、在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的

配置的覆盖规则：

1.方法级配置别优于接口级别，即小Scope优先

2.Consumer端配置优于 Provider配置优于全局配置

3.最后是Dubbo Hard Code的配置值（见配置文档）

在这里插入图片描述

总结：
- 精确优先（方法级优先，接口级次，全局配置再次之）
- 消费者配置优先（同级别配置，消费者方优先，服务提供者次之）
- 精确优先大于消费者设置优先

5.4 重试次数

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

重试次数配置如下：
<dubbo:service retries="2" />
或
<dubbo:reference retries="2" />
或
<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

如果有多个服务提供方，则重试时也会去重试其他服务

5.5 多版本

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

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

在低压力时间段，先升级一半提供者为新版本

再将所有消费者升级为新版本

然后将剩下的一半提供者升级为新版本

老版本服务提供者配置：（version则是服务的版本号）
<dubbo:service interface="com.foo.BarService" version="1.0.0" />

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

老版本服务消费者配置：（若要调用老版本的BarService服务，则要再调用的后面添加version版本号）
<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="*" />

6.Dubbi与SpingBoot整合的三种方式

SpringBoot与dubbo整合的三种方式：

导入dubbo-starter，在application.properties配置属性，使用**@Service【暴露服务】使用@Reference【引用服务】**（要记得加上注解@EnableDubbo开启基于注解的dubbo功能）

保留dubbo xml配置文件;

  导入dubbo-starter，使用**@ImportResource**导入dubbo的配置文件即可（可以注释掉@EnableDubbo和@Service）

 **@ImportResource(locations="classpath:provider.xml")**

使用注解API的方式：

  将每一个组件手动创建到容器中,让dubbo来扫描其他的组件

 将每一个标签用配置文件来代替：

@Configuration
public class MyDubboConfig {
	
	@Bean
	public ApplicationConfig applicationConfig() {
		ApplicationConfig applicationConfig = new ApplicationConfig();
		applicationConfig.setName("boot-user-service-provider");
		return applicationConfig;
	}
	
	//<dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"></dubbo:registry>
	@Bean
	public RegistryConfig registryConfig() {
		RegistryConfig registryConfig = new RegistryConfig();
		registryConfig.setProtocol("zookeeper");
		registryConfig.setAddress("127.0.0.1:2181");
		return registryConfig;
	}
	
	//<dubbo:protocol name="dubbo" port="20882"></dubbo:protocol>
	@Bean
	public ProtocolConfig protocolConfig() {
		ProtocolConfig protocolConfig = new ProtocolConfig();
		protocolConfig.setName("dubbo");
		protocolConfig.setPort(20882);
		return protocolConfig;
	}
	
	/**
	 *<dubbo:service interface="com.atguigu.gmall.service.UserService" 
		ref="userServiceImpl01" timeout="1000" version="1.0.0">
		<dubbo:method name="getUserAddressList" timeout="1000"></dubbo:method>
	</dubbo:service>
	 */
	@Bean
	public ServiceConfig<UserService> userServiceConfig(UserService userService){
		ServiceConfig<UserService> serviceConfig = new ServiceConfig<>();
		serviceConfig.setInterface(UserService.class);
		serviceConfig.setRef(userService);
		serviceConfig.setVersion("1.0.0");
		
		//配置每一个method的信息
		MethodConfig methodConfig = new MethodConfig();
		methodConfig.setName("getUserAddressList");
		methodConfig.setTimeout(1000);
		
		//将method的设置关联到service配置中
		List<MethodConfig> methods = new ArrayList<>();
		methods.add(methodConfig);
		serviceConfig.setMethods(methods);
		
		//ProviderConfig
		//MonitorConfig
		
		return serviceConfig;
	}

}

编写好配置类之后，在主配置类BootUserServiceProviderApplication中添加扫描包注解**@EnableDubbo**（scanBasePackage=“com.atguigu.gmall”）或者**@DubboComponentScan**（basePackages=“xxxx”）,并且在服务的实现类要添加**@Service**注解将其注入

7.高可用

7.1 zookeeper宕机与dubbo直连

现象：zookeeper注册中心宕机，还可以消费dubbo暴露的服务。（当链接成功一次之后注册中心突然宕机）

原因：

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

Dubbo直连：直接通过Dubbo直连进行通讯，这样就不用经过注册中心了：

做法：在消费者的服务实现类中，在接口组件注入的**@Autowired注解替换成@Reference（url=“127.0.0.1:20882”）**

7.2 集群下dubbo负载均衡配置

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

Random LoadBalance（dubbo默认）
- 随机，按权重设置随机概率。
  
  在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
  
  调用方式：@Reference(loadbalance=“random”)
RoundRobin LoadBalance
- 轮循，按公约后的权重设置轮循比率(按照顺序来)。
  
  存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
  
  该图中的首先是按照轮询机制从1号服务器开始按顺序分配请求，当第二轮到2号服务器之后，由于按照权重分配，7次请求只有一次可以到3号服务器，所以第二轮不能再到3号服务器，只能一直接2号服务器。
  
  调用方式：@Reference(loadbalance=“roundrobin”)
LeastActive LoadBalance
- 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
  
  使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
  
  所以会选择1号服务器进行调用，因为响应处理请求快。
ConsistentHash LoadBalance
- 一致性 Hash，相同参数的请求总是发到同一提供者。
  
  当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。算法参见：http://en.wikipedia.org/wiki/Consistent_hashing

7.3 服务降级

概念：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。

向注册中心写入动态配置覆盖规则：
RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));

其中：

屏蔽：mock=force:return+null 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。（直接将要降级的服务所发送的请求设置为null）
容错：还可以改为 mock=fail:return+null 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。（当服务请求超时失败之后直接返回null）

7.4 集群容错

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

集群容错模式

Failover Cluster（默认模式）
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。

重试次数配置如下：
<dubbo:service retries="2" />
或
<dubbo:reference retries="2" />
或
<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。（用于一定要成功的服务）

Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。

集群模式配置
按照以下示例在服务提供方和消费方配置集群模式
<dubbo:service cluster="failsafe" />
或
<dubbo:reference cluster="failsafe" />

7.5 整合hystrix

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

配置spring-cloud-starter-netflix-hystrix

spring boot官方提供了对hystrix的集成，直接在pom.xml里加入依赖：

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

然后在提供者和消费者的主Application类上增加**@EnableHystrix**来启用hystrix starter：

2.配置Provider端

在Dubbo的Provider上增加@HystrixCommand配置，这样子调用就会经过Hystrix代理

@Service(version = "1.0.0")
public class HelloServiceImpl implements HelloService {
    @HystrixCommand(commandProperties = {
     @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
     @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") })
    @Override
    public String sayHello(String name) {
        // System.out.println("async provider received: " + name);
        // return "annotation: hello, " + name;
        throw new RuntimeException("Exception to show hystrix enabled.");
    }
}

3.配置Consumer端

对于Consumer端，则可以增加一层method调用，并在method上配置**@HystrixCommand**。当调用出错时，会走到fallbackMethod = "reliable"的调用里，就会去调用reliable方法。

    @Reference(version = "1.0.0")
    private HelloService demoService;

    @HystrixCommand(fallbackMethod = "reliable")
    public String doSayHello(String name) {
        return demoService.sayHello(name);
    }
    public String reliable(String name) {
        return "hystrix fallback value";
    }

8.Dubbo原理

8.1RPC原理

在这里插入图片描述

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

1）服务消费方（client）调用以本地调用方式调用服务；

2）client stub（相当于是客户端的代理）接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；

3）client stub找到服务地址，并将消息发送到服务端；

4）server stub收到消息后进行解码；

5）server stub根据解码结果调用本地的服务进行序列化处理；

6）本地服务执行并将结果返回给server stub；

7）server stub将返回结果打包成消息并发送至消费方；

8）client stub接收到消息，并进行解码；

9）服务消费方得到最终结果。

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

8.2Netty通信原理

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

在这里插入图片描述

NIO (Non-Blocking IO)

在这里插入图片描述

Selector 一般称为选择器 ，也可以翻译为 **多路复用器，**通过一个选择器来监听多个通道监听事件，当达到某种case状态的时候再开启线程进行处理。

Connect（连接就绪）、Accept（接受就绪）、Read（读就绪）、Write（写就绪）

Netty基本原理：

在这里插入图片描述

8.3dubbo原理-框架设计

在这里插入图片描述

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 网络传输层：底层是netty框架，抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

8.4dubbo原理 -启动解析、加载配置信息

在这里插入图片描述

当启动dubbo 的时候，底层会对dubbo标签逐一进行解析，并创建相对应的标签解析器。

8.5dubbo原理 -服务暴露

在这里插入图片描述

8.6服务引用调用

服务引用:

在这里插入图片描述

服务调用：

在这里插入图片描述

完结撒花~

秃头的二哈

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Dubbo学习

在传统的部署架构下，服务发现涉及提供者、消费者和注册中心三个参与角色，其中，提供者注册 URL 地址到注册中心，注册中心负责对数据进行聚合，消费者从注册中心订阅 URL 地址更新。在云原生背景下，比如当应用部署在 Kubernetes 等平台，由于平台自身维护了应用/服务与实例间的映射关系，因此注册中心与注册动作在一定程度上被下沉到了基础设施层，因此框架自身的注册动作有时并不是必须的。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
复制链接

扫一扫