一起进阶学习JAVA：Dubbo

最新推荐文章于 2024-08-24 23:02:07 发布
最新推荐文章于 2024-08-24 23:02:07 发布
阅读量1k 收藏
点赞数 3
分类专栏： 分布式集群 文章标签： java 分布式 spring
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wlhack/article/details/108385855
版权

一起进阶学习JAVA：Dubbo


Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。

Dubbo处理流程

在这里插入图片描述
节点说明

节点角色名称
Provider暴露服务的服务提供方
Consumer调用远程服务的服务消费方
Registry服务注册与发现的注册中心
Monitor统计服务的调用次数和调用时间的监控中心
Container服务运行容器 负责启动 加载 运行服务提供者

调用关系说明:

  • 虚线 代表异步调用 实线代表同步访问
  • 蓝色虚线 是在启动时完成的功能
  • 红色虚线 是程序运行中执行的功能

调用流程:

  1. 服务提供者在服务容器启动时 向注册中心 注册自己提供的服务
  2. 服务消费者在启动时 向注册中心订阅自己所需的服务
  3. 注册中心返回服务提供者地址列表给消费者 如果有变更 注册中心会基于长连接推送变更数据给消费者服务，消费者从提供者地址列表中 基于软负载均衡算法 选一台提供者进行调用 如果调用失败 则重新选择一台
  4. 服务提供者和消费者 在内存中的调用次数 和 调用时间 定时每分钟发送给监控中心

服务注册中心Zookeeper

Registry（服务注册中心）在其中起着至关重要的作用。Dubbo官方推荐使用Zookeeper作为服务注册中心。Zookeeper 是 Apache Hadoop 的子项目，作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 。

Dubbo项目开发过程

接口协定

  • 定义Maven

    <groupId>com.xxx</groupId>
<artifactId>service-api</artifactId>
<version>1.0-SNAPSHOT</version>

  • 定义接口

    public interface HelloService {
	String sayHello(String name);
}

创建接口提供者

  • 引入API模块

    <dependency>
	<groupId>com.xxx</groupId>
	<artifactId>service-api</artifactId>
	<version>${project.version}</version>
</dependency>

  • 引入Dubbo相关依赖，此处为注解方式

    <dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-registry-zookeeper</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-rpc-dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-remoting-netty4</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-serialization-hessian2</artifactId>
</dependency>

  • 编写实现类，使用Dubbo中的@Service注解来声明

    @Service
public class HelloServiceImpl implements HelloService {
	@Override
	public String sayHello(String name) {
		return "hello: " + name;
	}
}

  • 编写配置文件，用于配置dubbo，这里使用dubbo-provider.properties，目录放置于resources下

    dubbo.application.name=dubbo-demo-annotation-provider
dubbo.protocol.name=dubbo
dubbo.protocol.port=20880

  • 编写启动main函数

    public class DubboPureMain {
	public static void main(String[] args) throws Exception {
		AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ProviderConfiguration.class);
		context.start();
		System.in.read();
	}
	@Configuration
	@EnableDubbo(scanBasePackages = "com.xxx.service.impl")
	@PropertySource("classpath:/dubbo-provider.properties")
	static class ProviderConfiguration {
		@Bean
		public RegistryConfig registryConfig() {
			RegistryConfig registryConfig = new RegistryConfig();
			registryConfig.setAddress("zookeeper://127.0.0.1:2181");
			return registryConfig;
		}
	}
}

创建消费者

  • 引入API模块

    <dependency>
	<groupId>com.xxx</groupId>
	<artifactId>service-api</artifactId>
	<version>${project.version}</version>
</dependency>

  • 引入Dubbo相关依赖

    <dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-registry-zookeeper</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-rpc-dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-remoting-netty4</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-serialization-hessian2</artifactId>
</dependency>

  • 编写服务，用于真实的引用dubbo接口并使用，其中@Reference中所指向的就是真实的第三方服务接口

    @Component
public class ConsumerComponent {
	@Reference
	private HelloService helloService;
	
	public String sayHello(String name) {
		return helloService.sayHello(name);
	}
}

  • 编写消费者配置文件，这里使用dubbo-consumer.properties，目录放置于resources下

    dubbo.application.name=service-consumer
dubbo.registry.address=zookeeper://127.0.0.1:2181

  • 编写启动类

    public class AnnotationConsumerMain {
	public static void main(String[] args) throws IOException,InterruptedException {
		AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ConsumerConfiguration.class);
		context.start();
		ConsumerComponent service = context.getBean(ConsumerComponent.class);
		while (true) {
			try {
				String hello = service.sayHello("world");
				System.out.println("result :" + hello);
			} catch (Exception e) {
				e.printStackTrace();
			}
		}
	}
	@Configuration
	@EnableDubbo(scanBasePackages = "com.xxx.service")
	@PropertySource("classpath:/dubbo-consumer.properties")
	@ComponentScan(value = {"com.xxx.bean.consumer"})
	static class ConsumerConfiguration {
	}
}

Dubbo的配置方式

  1. 注解: 基于注解可以快速的将程序配置，无需多余的配置信息，包含提供者和消费者。但是这种方式有一个弊端，有些时候配置信息并不是特别好找，无法快速定位。
  2. XML: 一般这种方式我们会和Spring做结合，相关的Service和Reference均使用Spring集成后的。通过这样的方式可以很方便的通过几个文件进行管理整个集群配置。可以快速定位也可以快速更改。
  3. 基于代码方式: 基于代码方式的对上述配置进行配置。这个使用的比较少，这种方式更适用于自己公司对其框架与Dubbo做深度集成时才会使用。

XML方式

我们一般XML会结合Spring应用去进行使用，将Service的注册和引用方式都交给Spring去管理。下面我们还是针对于上面的demo进行实现。

provider模块

  • 引入API依赖

    <dependency>
	<groupId>com.xxx</groupId>
	<artifactId>service-api</artifactId>
	<version>${project.version}</version>
</dependency>

  • 引入dubbo依赖。与原先的不同点在于，最后多了spring的依赖引入。

    <dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-registry-zookeeper</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-rpc-dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-remoting-netty4</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-serialization-hessian2</artifactId>
</dependency>

<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-config-spring</artifactId>
</dependency>

  • 编写实现类，不需要引入任何注解配置

    public class HelloServiceImpl implements HelloService {
	@Override
	public String sayHello(String name) {
		return "hello: " + name;
	}
}

  • 编写spring-dubbo-provider.xml文件，用于对dubbo进行文件统一配置。并且对刚才的配置进行引入。

    <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
		xmlns="http://www.springframework.org/schema/beans"
		xsi:schemaLocation="http://www.springframework.org/schema/beans
							http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
							http://dubbo.apache.org/schema/dubbo
							http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

	<dubbo:application name="dubbo-demo-annotation-provider"/>
	
	<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
	
	<dubbo:protocol name="dubbo"/>
	
	<bean id="helloService" class="com.xxx.service.impl.HelloServiceImpl"/>
	
	<dubbo:service interface="com.xxx.service.HelloService" ref="helloService"/>
</beans>

  • 编写启动类

    public class ProviderApplication {
	public static void main(String[] args) throws Exception {
		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring-*.xml");
		context.start();
	}
}

consumer模块

  • 引入API模块

    <dependency>
	<groupId>com.xxx</groupId>
	<artifactId>service-api</artifactId>
	<version>${project.version}</version>
</dependency>

  • 引入dubbo依赖。与原先的不同点在于，最后多了spring的依赖引入。

    <dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-registry-zookeeper</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-rpc-dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-remoting-netty4</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-serialization-hessian2</artifactId>
</dependency>

<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-config-spring</artifactId>
</dependency>

  • 定义spring的配置xml文件spring-dubbo-consumer.xml

    <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
		xmlns="http://www.springframework.org/schema/beans"
		xsi:schemaLocation="http://www.springframework.org/schema/beans
							http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
							http://dubbo.apache.org/schema/dubbo
							http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
	<dubbo:application name="demo-consumer"/>
	
	<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
	
	<dubbo:reference id="helloService" interface="com.xxx.service.HelloService">
	
	</dubbo:reference>
</beans>

  • 引入启动模块。因为引用了Spring框架，所以再上一步的helloService会被当做一个bean注入到真实的环境中。在我们生产级别使用的时候，我们可以通过Spring中的包扫描机制，通过@Autowired这种机制来进行依赖注入。

    public class XMLConsumerMain {
	public static void main(String[] args) throws Exception {
		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring-*.xml");
		HelloService demoService = context.getBean(HelloService.class);
		System.out.println(demoService.sayHello("world"));
	}
}

Dubbo配置项说明

dubbo:application

对应 org.apache.dubbo.config.ApplicationConfig, 代表当前应用的信息

  1. name: 当前应用程序的名称，在dubbo-admin中我们也可以看到，这个代表这个应用名称。我们在真正时是时也会根据这个参数来进行聚合应用请求。
  2. owner: 当前应用程序的负责人，可以通过这个负责人找到其相关的应用列表，用于快速定位到责任人。
  3. qosEnable : 是否启动QoS 默认true
  4. qosPort : 启动QoS绑定的端口 默认22222
  5. qosAcceptForeignIp: 是否允许远程访问 默认是false

dubbo:registry

org.apache.dubbo.config.RegistryConfig, 代表该模块所使用的注册中心。一个模块中的服务可以将其注册到多个注册中心上，也可以注册到一个上。后面再service和reference也会引入这个注册中心。

  1. id : 当当前服务中provider或者consumer中存在多个注册中心时，则使用需要增加该配置。在一些公司，会通过业务线的不同选择不同的注册中心，所以一般都会配置该值。
  2. address : 当前注册中心的访问地址。
  3. protocol : 当前注册中心所使用的协议是什么。也可以直接在 address 中写入，比如使用zookeeper，就可以写成 zookeeper://xx.xx.xx.xx:2181
  4. timeout : 当与注册中心不再同一个机房时，大多会把该参数延长

dubbo:protocol

org.apache.dubbo.config.ProtocolConfig, 指定服务在进行数据传输所使用的协议。

  1. id : 在大公司，可能因为各个部门技术栈不同，所以可能会选择使用不同的协议进行交互。这里在多个协议使用时，需要指定。
  2. name : 指定协议名称。默认使用 dubbo 。

dubbo:service

org.apache.dubbo.config.ServiceConfig, 用于指定当前需要对外暴露的服务信息和 dubbo:reference 大致相同。

  1. interface : 指定当前需要进行对外暴露的接口是什么。
  2. ref : 具体实现对象的引用，一般我们在生产级别都是使用Spring去进行Bean托管的，所以这里面一般也指的是Spring中的BeanId。
  3. version : 对外暴露的版本号。不同的版本号，消费者在消费的时候只会根据固定的版本号进行消费。

dubbo:reference

org.apache.dubbo.config.ReferenceConfig, 消费者的配置。

  1. id : 指定该Bean在注册到Spring中的id。
  2. interface: 服务接口名
  3. version : 指定当前服务版本，与服务提供者的版本一致。
  4. registry : 指定所具体使用的注册中心地址。这里面也就是使用上面在 dubbo:registry 中所声明的id。

dubbo:method

org.apache.dubbo.config.MethodConfig, 用于在制定的 dubbo:service 或者 dubbo:reference 中的更具体一个层级，指定具体方法级别在进行RPC操作时候的配置，可以理解为对这上面层级中的配置针对于具体方法的特殊处理。

  1. name : 指定方法名称，用于对这个方法名称的RPC调用进行特殊配置。
  2. async: 是否异步 默认false

dubbo:service和dubbo:reference详解

这两个在dubbo中是我们最为常用的部分，其中有一些我们必然会接触到的属性。并且这里会讲到一些设置上的使用方案。

  1. mock: 用于在方法调用出现错误时，当做服务降级来统一对外返回结果，后面我们也会对这个方法做更多的介绍。
  2. timeout: 用于指定当前方法或者接口中所有方法的超时时间。我们一般都会根据提供者的时长来具体规定。比如我们在进行第三方服务依赖时可能会对接口的时长做放宽，防止第三方服务不稳定导致服务受损。
  3. check: 用于在启动时，检查生产者是否有该服务。我们一般都会将这个值设置为false，不让其进行检查。因为如果出现模块之间循环引用的话，那么则可能会出现相互依赖，都进行check的话，那么这两个服务永远也启动不起来。
  4. retries: 用于指定当前服务在执行时出现错误或者超时时的重试机制。
    1. 注意提供者是否有幂等，否则可能出现数据一致性问题
    2. 注意提供者是否有类似缓存机制，如出现大面积错误时，可能因为不停重试导致雪崩
  5. executes: 用于在提供者做配置，来确保最大的并行度。
    1. 可能导致集群功能无法充分利用或者堵塞
    2. 但是也可以启动部分对应用的保护功能
    3. 可以不做配置，结合后面的熔断限流使用

SPI

SPI 全称为 (Service Provider Interface) ，是JDK内置的一种服务提供发现机制。 目前有不少框架用它来做服务的扩展发现，简单来说，它就是一种动态替换发现的机制。使用SPI机制的优势是实现解耦，使得第三方服务模块的装配控制逻辑与调用者的业务代码分离。

JDK中的SPI

在这里插入图片描述
Java中如果想要使用SPI功能，先提供标准服务接口，然后再提供相关接口实现和调用者。这样就可通过SPI机制中约定好的信息进行查询相应的接口实现。

SPI遵循如下约定：

  1. 当服务提供者提供了接口的一种具体实现后，在META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名；
  2. 接口实现类所在的jar包放在主程序的classpath中；
  3. 主程序通过java.util.ServiceLoader动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名，把类加载到JVM；
  4. SPI的实现类必须携带一个无参构造方法；

Dubbo中的SPI

dubbo中大量的使用了SPI来作为扩展点，通过实现同一接口的前提下，可以进行定制自己的实现类。比如比较常见的协议，负载均衡，都可以通过SPI的方式进行定制化，自己扩展。Dubbo中已经存在的所有已经实现好的扩展点。
在这里插入图片描述
下图中则是Dubbo中默认提供的负载均衡策略。

在这里插入图片描述

Dubbo中扩展点使用方式

api项目创建

  • 导入坐标 dubbo

    <dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-registry-zookeeper</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-rpc-dubbo</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-remoting-netty4</artifactId>
</dependency>
<dependency>
	<groupId>org.apache.dubbo</groupId>
	<artifactId>dubbo-serialization-hessian2</artifactId>
</dependency>

  • 创建接口，并在接口上使用@SPI

    @SPI
public interface HelloService {
    public String sayHello(String name, int timeToWait);
}

impl项目创建

  • 导入API项目依赖

    <dependency>
	<groupId>com.xxx</groupId>
	<artifactId>service-api</artifactId>
	<version>${project.version}</version>
</dependency>

  • 建立实现类，为了表达支持多个实现的目的，这里分别创建两个实现。分别为HumanHelloService 和 DogHelloService 。

    public class HumanHelloService implements HelloService {
	@Override
	public String sayHello(String name) {
		return "HumanHelloService hello: " + name;
	}
}

    public class DogHelloService implements HelloService {
	@Override
	public String sayHello(String name) {
		return "DogHelloServicehello: " + name;
	}
}

  • SPI进行声明操作，在resources目录下创建目录META-INF/dubbo目录，在目录下创建名称为com.xxx.dubbo.study.spi.demo.api.HelloService的文件，文件内部配置两个实现类名称和对应的全限定名：

    human=com.xxx.service.impl.HumanHelloService
dog=com.xxx.service.impl.DogHelloService

注：使用SPI之后调用方式会不太相同，dubbo 有对其进行自我重新实现 需要借助ExtensionLoader

Dubbo自己做SPI的目的：

  1. JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加
    载，会很浪费资源
  2. 如果有扩展点加载失败，则所有扩展点无法使用
  3. 提供了对扩展点包装的功能(Adaptive)，并且还支持通过set的方式对其他的扩展点进行注入

Dubbo调用时拦截操作

与很多框架一样，Dubbo也存在拦截（过滤）机制，可以通过该机制在执行目标程序前后执行我们指定的代码。

Dubbo的Filter机制，是专门为服务提供方和服务消费方调用过程进行拦截设计的，每次远程方法执行，该拦截都会被执行。这样就为开发者提供了非常方便的扩展性，比如为dubbo接口实现ip白名单功能、监控功能 、日志记录等。
步骤如下：

  1. 实现 org.apache.dubbo.rpc.Filter接口

  2. 使用 org.apache.dubbo.common.extension.Activate 接口进行对类进行注册 通过group可以指定生产端 消费端 如:

    @Activate(group = {CommonConstants.CONSUMER)

  3. 计算方法运行时间的代码实现

  4. 在 META-INF.dubbo 中新建 org.apache.dubbo.rpc.Filter 文件，并将当前类的全名写入

    timerFilter=包名.过滤器的名字

注意：一般类似于这样的功能都是单独开发依赖的，所以再使用方的项目中只需要引入依赖，在调用接口时，该方法便会自动拦截。

负载均衡策略

负载均衡基本配置

负载均衡（Load Balance）, 其实就是将请求分摊到多个操作单元上进行执行，从而共同完成工作任务。

负载均衡策略主要用于客户端存在多个提供者时进行选择某个提供者。

在集群负载均衡时，Dubbo 提供了多种均衡策略（包括随机、轮询、最少活跃调用数、一致性Hash），缺省为random随机调用。

配置负载均衡策略，既可以在服务提供者一方配置，也可以在服务消费者一方配置，如下：

//在服务消费者一方配置负载均衡策略
@Reference(check = false,loadbalance = "random")

//在服务提供者一方配置负载均衡
@Service(loadbalance = "random")
public class HelloServiceImpl implements HelloService {
	public String sayHello(String name) {
		return "hello " + name;
	}
}

自定义负载均衡器

负载均衡器在Dubbo中的SPI接口是 org.apache.dubbo.rpc.cluster.LoadBalance, 可以通过实现这个接口来实现自定义的负载均衡规则。

  1. 自定义负载均衡器
    在上面案例基础上创建名称为dubbo-spi-loadbalance的Maven模块，并创建负载均衡器OnlyFirstLoadbalancer。这里功能只是简单的选取所有机器中的第一个(按照字母排序 + 端口排序)。

  2. 配置负载均衡器
    在dubbo-spi-loadbalance工程的 META-INF/dubbo 目录下新建org.apache.dubbo.rpc.cluster.LoadBalance 文件，并将当前类的全名写入

    onlyFirst=包名.负载均衡器

  3. 在服务提供者工程实现类中编写用于测试负载均衡效果的方法 启动不同端口时 方法返回的信息不同

  4. 启动多个服务 要求他们使用同一个接口注册到同一个注册中心 但是他们的dubbo通信端口不同

  5. 在服务消费方指定自定义负载均衡器onlyFirst

  6. 测试自定义负载均衡的效果

异步调用

Dubbo不只提供了堵塞式的的同步调用，同时提供了异步调用的方式。这种方式主要应用于提供者接口响应耗时明显，消费者端可以利用调用接口的时间去做一些其他的接口调用,利用 Future 模式来异步等待和获取结果即可。这种方式可以大大的提升消费者端的利用率。 目前这种方式可以通过XML的方式进行引入。

异步调用的实现

  1. 为了能够模拟等待，通过int timeToWait参数，标明需要休眠多少毫秒后才会进行返回。

    String sayHello(String name, int timeToWait);

  2. 接口实现 为了模拟调用耗时 可以让线程等待一段时间

  3. 在消费者端，配置异步调用 注意消费端默认超时时间1000毫秒 如果提供端耗时大于1000毫秒会出现超时
    可以通过改变消费端的超时时间 通过timeout属性设置即可单位毫秒

    <dubbo:reference id="helloService" interface="com.xxx.service.HelloService">
	<dubbo:method name="sayHello" async="true" />
</dubbo:reference>

  4. 测试，我们休眠100毫秒，然后再去进行获取结果。方法在同步调用时的返回值是空，我们可以通过 RpcContext.getContext().getFuture() 来进行获取Future对象来进行后续的结果等待操作。

异步调用特殊说明

需要特别说明的是，该方式的使用，请确保dubbo的版本在2.5.4及以后的版本使用。 原因在于在2.5.3及之前的版本使用的时候，会出现异步状态传递问题。比如我们的服务调用关系是 A -> B -> C , 这时候如果A向B发起了异步请求，在错误的版本时，B向C发起的请求也会连带的产生异步请求。这是因为在底层实现层面，他是通过RPCContext中的attachment实现的。在A向B发起异步请求时，会在attachment中增加一个异步标示字段来表明异步等待结果。B在接受到A中的请求时，会通过该字段来判断是否是异步处理。但是由于值传递问题，B向C发起时同样会将该值进行传递，导致C误以为需要异步结果，导致返回空。这个问题在2.5.4及以后的版本进行了修正。

线程池

Dubbo已有线程池

dubbo在使用时，都是通过创建真实的业务线程池进行操作的。目前已知的线程池模型有两个和java中的相互对应:

  • fix: 表示创建固定大小的线程池。也是Dubbo默认的使用方式，默认创建的执行线程数为200，并且是没有任何等待队列的。所以再极端的情况下可能会存在问题，比如某个操作大量执行时，可能存在堵塞的情况。后面也会讲相关的处理办法。
  • cache: 创建非固定大小的线程池，当线程不足时，会自动创建新的线程。但是使用这种的时候需要注意，如果突然有高TPS的请求过来，方法没有及时完成，则会造成大量的线程创建，对系统的CPU和负载都是压力，执行越多反而会拖慢整个系统。

自定义线程池

在真实的使用过程中可能会因为使用fix模式的线程池，导致具体某些业务场景因为线程池中的线程数量不足而产生错误，而很多业务研发是对这些无感知的，只有当出现错误的时候才会去查看告警或者通过客户反馈出现严重的问题才去查看，结果发现是线程池满了。所以可以在创建线程池的时，通过某些手段对这个线程池进行监控，这样就可以进行及时的扩缩容机器或者告警。下面的这个程序就是这样子的，会在创建线程池后进行对其监控，并且及时作出相应处理。

  1. 线程池实现, 这里主要是基于对FixedThreadPool 中的实现做扩展出线程监控的部分

    public class WatchingThreadPool extends FixedThreadPool implements Runnable {
	private static final Logger LOGGER = LoggerFactory.getLogger(WatchingThreadPool.class);
	private static final double ALARM_PERCENT = 0.90;
	private final Map<URL, ThreadPoolExecutor> THREAD_POOLS = new ConcurrentHashMap<>();
	
	public WatchingThreadPool() {
		// 每隔3秒打印线程使用情况
		Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay(this, 1,3, TimeUnit.SECONDS);
	}
	
	@Override
	public Executor getExecutor(URL url) {
		// 从父类中创建线程池
		final Executor executor = super.getExecutor(url);
		if (executor instanceof ThreadPoolExecutor) {
			THREAD_POOLS.put(url, ((ThreadPoolExecutor) executor));
		}
		return executor;
	}
	
	@Override
	public void run() {
		// 遍历线程池，如果超出指定的部分，进行操作，比如接入公司的告警系统或者短信平台
		for (Map.Entry<URL, ThreadPoolExecutor> entry : THREAD_POOLS.entrySet()) {
			final URL url = entry.getKey();
			final ThreadPoolExecutor executor = entry.getValue();
			// 当前执行中的线程数
			final int activeCount = executor.getActiveCount();
			// 总计线程数
			final int poolSize = executor.getCorePoolSize();
			double used = (double)activeCount / poolSize;
			final int usedNum = (int) (used * 100);
			LOGGER.info("线程池执行状态:[{}/{}]:{}%", activeCount, poolSize, usedNum);
			if (used >= ALARM_PERCENT) {
				LOGGER.error("超出警戒值！host:{}, 当前已使用量:{}%, URL:{}", url.getIp(), usedNum, url);
			}
		}
	}
}

  2. SPI声明，创建文件 META-INF/dubbo/org.apache.dubbo.common.threadpool.ThreadPool

    watching=包名.线程池名

  3. 在服务提供方项目引入该依赖

  4. 在服务提供方项目中设置使用该线程池生成器

    dubbo.provider.threadpool=watching

  5. 接下来需要做的就是模拟整个流程，因为该线程当前是每1秒抓一次数据，所以我们需要对该方法的提供者超过1秒的时间(比如这里用休眠 Thread.sleep )，消费者则需要启动多个线程来并行执行，来模拟整个并发情况。

  6. 在调用方则尝试简单通过for循环启动多个线程来执行 查看服务提供方的监控情况

路由规则

路由是决定一次请求中需要发往目标机器的重要判断，通过对其控制可以决定请求的目标机器。我们可以通过创建这样的规则来决定一个请求会交给哪些服务器去处理。

路由规则快速入门

  1. 提供两个提供者(一台本机作为提供者，一台为其他的服务器)，每个提供者会在调用时可以返回不同的信息 以区分提供者。

  2. 针对于消费者，我们这里通过一个死循环，每次等待用户输入，再进行调用，来模拟真实的请求情况。

  3. 我们通过ipconfig来查询到我们的IP地址，并且单独启动一个客户端，来进行如下配置(这里假设我们希望隔离掉本机的请求，都发送到另外一台机器上)。

    public class DubboRouterMain {
	public static void main(String[] args) {
		RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
		Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://127.0.0.1:2181"));
		registry.register(URL.valueOf("condition://0.0.0.0/com.xxx.service.HelloService?category=routers&force=true&dynamic=true&rule=" + URL.encode("=> host != 你的机器ip不能是127.0.0.1")));
	}
}

  4. 通过这个程序执行后，我们就通过消费端不停的发起请求，看到真实的请求都发到了除去本机以外的另外一台机器上。

路由规则详解

通过上面的程序，我们实际本质上就是通过在zookeeper中保存一个节点数据，来记录路由规则。消费者会通过监听这个服务的路径，来感知整个服务的路由规则配置，然后进行适配。这里主要介绍路由配置的参数

规则解释是否必填
route://表示路由规则的类型，支持条件路由规则和脚本路由规则，可扩展必填
0.0.0.0表示对所有 IP 地址生效，如果只想对某个 IP 的生效，请填入具体 IP必填
com.xxx.service.HelloService表示只对指定服务生效必填
category=routers表示该数据为动态配置类型必填
dynamic是否为持久数据，当指定服务重启时是否继续生效必填
runtime是否在设置规则时自动缓存规则，如果设置为true则会影响部分性能
rule... => ...在这里=> 前面的就是表示消费者方的匹配规则，可以不填(代表全部)。=> 后方则必须填写，表示当请求过来时，选择提供者的配置。必填

路由与上线系统结合

当公司到了一定的规模之后，一般都会有自己的上线系统，专门用于服务上线。方便后期进行维护和记录的追查。我们去想象这样的一个场景，一个dubbo的提供者要准备进行上线，一般都提供多台提供者来同时在线上提供服务。这时候一个请求刚到达一个提供者，提供者却进行了关闭操作。那么此次请求就应该认定为失败了。所以基于这样的场景，我们可以通过路由的规则，把预发布(灰度)的机器进行从机器列表中移除。并且等待一定的时间，让其把现有的请求处理完成之后再进行关闭服务。同时，在启动时，同样需要等待一定的时间，以免因为尚未重启结束，就已经注册上去。等启动到达一定时间之后，再进行开启流量操作。

实现思路

1.利用zookeeper的路径感知能力，在服务准备进行重启之前将当前机器的IP地址和应用名写入zookeeper。
2.服务消费者监听该目录，读取其中需要进行关闭的应用名和机器IP列表并且保存到内存中。
3.当前请求过来时，判断是否是请求该应用，如果是请求重启应用，则将该提供者从服务列表中移除。

实现方式

  1. 引入Curator 框架，用于方便操作Zookeeper

  2. 编写Zookeeper的操作类，用于方便进行zookeeper处理

  3. 编写需要进行预发布的路径管理器，用于缓存和监听所有的待灰度机器信息列表。

  4. 编写路由类(实现 org.apache.dubbo.rpc.cluster.Router)，主要目的在于对ReadyRestartInstances 中的数据进行处理，并且移除路由调用列表中正在重启中的服务。

  5. 由于 Router机制比较特殊，所以需要利用一个专门的RouterFactory 来生成，原因在于并不是所有的都需要添加路由，所以需要利用 @Activate 来锁定具体哪些服务才需要生成使用

    @Activate
public class RestartingInstanceRouterFactory implements RouterFactory {
	@Override
	public Router getRouter(URL url) {
		return new RestartingInstanceRouter(url);
	}
}

  6. 对 RouterFactory 进行注册，同样放入到META-INF/dubbo/org.apache.dubbo.rpc.cluster.RouterFactory文件中。

    restartInstances=com.xxx.router.RestartingInstanceRouterFactory

  7. 将dubbo-spi-router项目引入至 consumer 项目的依赖中。

  8. 这时直接启动程序，还是利用上面中所写好的consumer程序进行执行，确认各个 provider可以正常执行。

  9. 单独写一个main函数来进行将某台实例设置为启动中的状态，比如这里我们认定为当前这台机器中的 service-provider这个提供者需要进行重启操作。

    ReadyRestartInstances.create().addRestartingInstance("service-provider", "正在重新启动的机器IP");

  10. 执行完成后，再次进行尝试通过 consumer 进行调用，即可看到当前这台机器没有再发送任何请求

  11. 一般情况下，当机器重启到一定时间后，我们可以再通过 removeRestartingInstance 方法对这个机器设定为既可以继续执行。

  12. 调用完成后，我们再次通过consumer 去调用，即可看到已经再次恢当前机器的请求参数。

服务动态降级

服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务有策略的降低服务级别，以释放服务器资源，保证核心任务的正常运行。

为什么要服务降级

而为什么要使用服务降级，这是防止分布式服务发生雪崩效应，什么是雪崩？就是蝴蝶效应，当一个请求发生超时，一直等待着服务响应，那么在高并发情况下，很多请求都是因为这样一直等着响应，直到服务资源耗尽产生宕机，而宕机之后会导致分布式其他服务调用该宕机的服务也会出现资源耗尽宕机，这样下去将导致整个分布式服务都瘫痪，这就是雪崩。

dubbo 服务降级实现方式

  • 在 dubbo 管理控制台配置服务降级
    屏蔽和容错

    • mock=force:return+null
      表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
    • mock=fail:return+null
      表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
      在这里插入图片描述

  • 指定返回简单值或者null

    <dubbo:reference id="xxService" check="false" interface="com.xx.XxService" timeout="3000" mock="return null" />
<dubbo:reference id="xxService2" check="false" interface="com.xx.XxService2" timeout="3000" mock="return 1234" />

如果是标注 则使用@Reference(mock="return null") @Reference(mock="return 简单值")也支持 @Reference(mock="force:return null")

  • 使用java代码 动态写入配置中心

    RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://IP:端口"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));

  • 整合整合 hystrix

Java进阶：Dubbo
m0_67393686的博客
08-01 185
ApacheDubbo是一款高性能的JavaRPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源JavaRPC框架，可以和Spring框架无缝集成。什么是RPC？RPC全称为remoteprocedurecall，即远程过程调用。比如两台服务器A和B，A服务器上部署一个应用，B服务器上部署一个应用，A服务器上的应用想调用B服务器上的应用提供的方法，由于两个应用不在一个内存空间，不能直接调用，所以需要通过网络来表达调用的语义和传达调用的数据。httpDubbo提供了三大核心能力。...
Java进阶面试题：zookeeper 都有哪些使用场景？
band_mmbx的博客
09-20 166
那么此时就可以使用 zookeeper 分布式锁，一个机器接收到了请求之后先获取 zookeeper 上的一把分布式锁，就是可以去创建一个 znode，接着执行操作；这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。分布式锁这个东西，很常用的，你做 Java 系统开发，分布式系统，可能会有一些场景会用到。，一旦 B 系统处理完了就修改 zookeeper 那个节点的值，A 立马就可以收到通知，完美解决。
JAVA之dubbo学习
qq_42574729的博客
09-12 480
目录: Dubbo简介及结构图 Dubbo支持的几种Registry Zookeeper简介 Zookeeper安装 Dubbo支持的几种Protocol Dubbo项目搭建 Admin管理界面 Assembly打包 监控中心搭建 一，SOA 英文名称(Service Oriented Ambiguity) 中文名称:面向服务架构 2.1 有一个专门提供服务单元. 2.2 其他所有单元都调用这个服务. ...
Java学习之Dubbo+ZooKeeper分布式服务Demo
06-19 556
背景：在之前的一个《Java学习之SpringBoot整合SSM Demo》分享中说到搭建ZooKeeper和Dubbo分布式框架中遇到了一些技术问题没能成功，只分享了其中的一个中间产物，那就是大家看到的《Java学习之SpringBoot整合SSM Demo》分享，带着深深的遗憾父亲节端午节没有回家陪老婆孩子也没有陪岳父岳母在公司苦学JAVA，终于现在解决了这其中的技术难点将ZooKeeper ...
Java实现Dubbo快速入门指南
最新发布
2301_77695569的博客
08-24 1222
Dubbo是一个由阿里巴巴开源的高性能Java RPC框架，广泛用于构建分布式服务架构。它提供了服务的注册、发现、调用等功能，支持多种协议和序列化方式，使得开发者能够轻松构建和维护分布式服务。在开始之前，请确保你的开发环境满足以下要求：在深入了解Dubbo之前，我们需要了解以下核心概念： 服务接口定义 首先，定义一个服务接口，例如： 实现服务 然后，实现这个接口： 定义服务提供地址 构建并运行提供程序 在消费者中调用远程服务 服务注册与发现 配置服务提供者和消费者连接到ZooKeeper注册中心： 配
dubbo进阶--入门实例
ditan20061218的博客
04-09 153
注册中心搭建好之后，现在开始进行一个dubbo实例，来体验一下dubbo的魅力。 为了方便的管理jar包，本次使用的是maven项目。 项目主要结构： 提供者： 消费者： 实现过程： 本次的demo属于简单入门，所以从代码上来看没有多少，主要是看dubbo是如何进行提供分布式服务的。 ...
dubbo进阶--基本概念
ditan20061218的博客
03-26 167
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行。Dubbo就是其中一种分布式服务架构，在使用Dubbo之前，我们有必要了解一下Dubbo的基本概念。 Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合。它致力于提供高性能和透明化的RPC远程调...
Dubbo进阶--zookeeper注册中心
ditan20061218的博客
03-28 179
上篇已经介绍了Dubbo的基本概念，我们知道了Dubbo提供方会将自己的服务注册到注册中心，使服务暴露出来，实现透明化。这节就介绍一下注册中心的搭建 目前常用的注册中心主要有四种，如下： 通过上述四种方法的对比，我选择了第一种zookeeper注册中心。 搭建环境： Linux：CentOS-7.0-1406-x86_64 jdk：jdk-7...
miaosha：:star::star::star::star:秒杀系统设计与实现。互联网工程师进阶与分析:person_raising_hand::rooster:
02-11
邮箱： GitHub： : QQ： QQ群1（秒杀架构一群）： ...一点小建议：学习本系列知识之前，如果你完全没接触过MQ ， SpringBoot ， Redis ， Dubbo ， ZK ， Maven ， lua等，那么我建议您可以先在网上搜一下每一
Java进阶面试题：如何设计一个高并发系统？
band_mmbx的博客
09-22 386
你需要考虑：哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何 join，哪些数据要放到缓存里去，放哪些数据再可以扛住高并发的请求，你需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是无比复杂的，一旦做过一次，并且做好了，你在这个市场上就会非常的吃香。其实大部分公司，真正看重的，不是说你掌握高并发相关的一些基本的架构知识，架构中的一些技术，RocketMQ、Kafka、Redis、Elasticsearch，高并发这一块，你了解了，也只能是次一等的人才。
dubbo实战之一：准备和初体验，Java进阶
zybb166的博客
12-18 276
org.apache.dubbo dubbo-dependencies-bom ${dubbo.version} pom import io.netty netty-all 4.1.25.Final org.apache.dubbo dubbo ${dubbo.version} org.apache.dubbo dubbo-dependencies-zookeeper ${dubbo.version} pom org.apache.dubbo dubbo-spring-boo
Java和dubbo中的SPI机制学习
clamaa的专栏
10-18 209
  关于java的SPI机制，可以参考：https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html   为了实现在模块装配时的时候不在程序中动态指明，需要提供一种服务发现机制，为某个接口寻找服务实现的机制，就是将装配的控制权转移到程序之外，在模块化设计中这个机制尤其重要。   Java SPI（Service Pro...
Java－Dubbo知识点整理
了解➔熟悉➔掌握➔精通
08-10 1475
分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net 1、Dubbo是什么 Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring 框架无缝集成。 RPC 指的是远程调用协议，也就是说两个服务器交互数据。 2、Dubbo的由来 互联网的快速发展，Web应用程序的规模不断扩大，一般会经历如下四个发展阶段。 单一应用架构：当网站流量
Dubbo进阶（三）——Dubbo配置方式详解
IT全栈 华强工作室
04-29 2504
Dubbo进阶（三）——Dubbo配置方式详解 &nbsp;&nbsp;Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，是阿里巴巴 SOA 服务化治理方案的核心框架，每天为 2,000+ 个服务提供 3,000,000,000+ 次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。 &nbsp;&nbsp;Dubbo 采用全Spring配置方式，透明化...
大神进阶必看—Dubbo
qq_44545083的博客
02-19 115
1、面试题 为什么要进行系统拆分？如何进行系统拆分？拆分后不用dubbo可以吗？ 2、面试官心里分析 从这个问题开始就进行分布式系统环节了，好多同学给我反馈说，现在出去分布式成标配了，没有哪个公司不问问你分布式的事儿。你要是不会分布式的东西，简直这简历没法看，没人会让你去面试。 其实为啥会这样呢？这就是因为整个大行业技术发展的原因。 早些年，我印象中在2010年初的时候，整个IT行业，很少有人谈...
Dubbo进阶（二）Dubbo高级实战
舞鹤白沙编码日志
02-10 947
一. SPI （一）SPI简介 SPI 全称为 (Service Provider Interface) ，是JDK内置的一种服务提供发现机制。 目前有不少框架用它来做服务的扩展发现，简单来说，它就是一种动态替换发现的机制。使用SPI机制的优势是实现解耦， 使得第三方服务模块的装配控制逻辑与调用者的业务代码分离。 （二）JDK中的SPI Java中如果想要使用SPI功能，先提供标准服务接口，然后再提供相关接口实现和调用者。这样就可以通过SPI机制中约定好的信息进行查询相应的接口实现。 .
Dubbo源码学习目录
进击的小白
10-26 488
Dubbo源码学习1:入口
Dubbo（从入门到掌握）看完这一篇就够了
西敏寺的乐章的博客
04-14 8764
Dubbo是阿里巴巴公司开源的一个高性能、轻量级的 Java RPC 框架。致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。
Java工程师进阶必备：全面进阶知识与面试宝典
资源摘要信息:"Java 工程师进阶知识...通过系统地学习和掌握"Java工程师进阶知识完全扫盲.zip"中的内容，Java工程师不仅能够为面试做好充分的准备，更能在实际的工作中提升开发水平，成为一名真正意义上的高级工程师。
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值