1. SPI
1.1 SPI简介
SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制。 目前有不少框架用它来做服务的扩展发现,简单来说,它就是一种动态替换发现的机制。使用SPI机制的优势是实现解耦,使得第三方服务模块的装配控制逻辑与调用者的业务代码分离。
1.2 JDK中的SPI
Java中如果想要使用SPI功能,先提供标准服务接口,然后再提供相关接口实现和调用者。这样就可以通过SPI机制中约定好的信息进行查询相应的接口实现。
SPI遵循如下约定:
- 当服务提供者提供了接口的一种具体实现后,在META-INF/services目录下创建一个以“接口全
限定名”为命名的文件,内容为实现类的全限定名; - 接口实现类所在的jar包放在主程序的classpath中;
- 主程序通过java.util.ServiceLoader动态装载实现模块,它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名,把类加载到JVM;
- SPI的实现类必须携带一个无参构造方法;
1.3 Dubbo中的SPI
dubbo中大量的使用了SPI来作为扩展点,通过实现同一接口的前提下,可以进行定制自己的实现类。比如比较常见的协议,负载均衡,都可以通过SPI的方式进行定制化,自己扩展。Dubbo中已经存在的所有已经实现好的扩展点。
1.4 Dubbo中扩展点使用方式
1.4.1 api项目创建
- 导入坐标dubbo
- 创建接口,在接口上使用@SPI
/**
* @author: lvqz
* @date: 2020/9/1
* @time: 16:07
*/
//这个注解的value可以设置默认的扩展点
@SPI("dog")
public interface HelloService {
//普通实现
String sayHello();
//实现Adaptive
@Adaptive
String sayHello(URL url);
}
1.4.2 impl项目创建
- 导入api项目的依赖
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>dubbo_spi_demo</artifactId>
<groupId>com.lvqz</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>dubbo_spi_impl</artifactId>
<dependencies>
<dependency>
<groupId>com.lvqz</groupId>
<artifactId>dubbo_spi_api</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
-
建立实现类,为了表达支持多个实现的目的,这里分别创建两个实现。分别为
HumanHelloService
和DogHelloService
。
-
SPI进行声明操作,在 resources 目录下创建目录 META-INF/dubbo 目录,在目录下创建名称为
com.lagou.dubbo.study.spi.demo.api.HelloService的文件,文件内部配置两个实现类名称和对应的全限定名:
human=com.lvqz.service.impl.HumanHelloService
dog=com.lvqz.service.impl.DogHelloService
1.4.3 main项目创建
- 导入坐标 接口项目 和 实现类项目
- 创建DubboSpiMain
和原先调用的方式不太相同, dubbo 有对其进行自我重新实现 需要借助ExtensionLoader,创建新的运行项目。这里demo中的示例和java中的功能相同,查询出所有的已知实现,并且调用
/**
* @author: lvqz
* @date: 2020/9/1
* @time: 16:12
*/
public class DubboSpiMain {
public static void main(String [] args){
//获取扩展加载器
final ExtensionLoader<HelloService> extensionLoader = ExtensionLoader.getExtensionLoader(HelloService.class);
//遍历所有的扩展点
Set<String> supportedExtensions = extensionLoader.getSupportedExtensions();
for (String supportedExtension : supportedExtensions) {
System.out.println(supportedExtension);
System.out.println(extensionLoader.getExtension(supportedExtension).sayHello());
}
}
}
1.5 dubbo自己做SPI的目的
- JDK 标准的 SPI 会一次性实例化扩展点所有实现,如果有扩展实现初始化很耗时,但如果没用上也加 载,会很浪费资源
- 如果有扩展点加载失败,则所有扩展点无法使用
- 提供了对扩展点包装的功能(Adaptive),并且还支持通过set的方式对其他的扩展点进行注入
1.6 Dubbo SPI中的Adaptive功能
Dubbo中的Adaptive功能,主要解决的问题是如何动态的选择具体的扩展点。通过
getAdaptiveExtension 统一对指定接口对应的所有扩展点进行封装,通过URL的方式对扩展点来进行动态选择。 (dubbo中所有的注册信息都是通过URL的形式进行处理的。)这里同样采用相同的方式进行实现。
-
创建接口
api中的 HelloService 扩展如下方法, 与原先类似,在sayHello中增加 Adaptive 注解,并且在参数中提供URL参数.注意这里的URL参数的类为 org.apache.dubbo.common.URL其中@SPI可以指定一个字符串参数,用于指明该SPI的默认实现。 -
创建实现类
与上面Service实现类代码相似,只需增加URL形参即可
/**
* @author: lvqz
* @date: 2020/9/1
* @time: 16:09
*/
public class DogHelloService implements HelloService {
public String sayHello() {
return "wang wang!";
}
public String sayHello(URL url) {
return "wang url" + url;
}
}
- 编写DubboAdaptiveMain
最后在获取的时候方式有所改变,需要传入URL参数,并且在参数中指定具体的实现类参数
/**
* @author: lvqz
* @date: 2020/9/1
* @time: 16:40
*/
public class DubboAdaptiveMain {
public static void main(String [] args){
final ExtensionLoader<HelloService> extensionLoader = ExtensionLoader.getExtensionLoader(HelloService.class);
//设置扩展域的地址 前面这段不重要test://localhost/hello?
// hello.service代表了HelloService,大写字母小写,并用.分隔
// human代表那个key
URL url = URL.valueOf("test://localhost/hello?hello.service=human");
// URL url = URL.valueOf("test://localhost/hello?hello.service=dog");
//这里不指定hello.service参数,就会找@SPI(”“)中写的默认参数
// URL url = URL.valueOf("test://localhost/hello");
HelloService extension = extensionLoader.getAdaptiveExtension();
System.out.println("extension = " + extension);
String s = extension.sayHello(url);
System.out.println(s);
}
}
1.7 Dubbo调用时拦截操作
与很多框架一样,Dubbo也存在拦截(过滤)机制,可以通过该机制在执行目标程序前后执行我们指定的代码。
Dubbo的Filter机制,是专门为服务提供方和服务消费方调用过程进行拦截设计的,每次远程方法执行,该拦截都会被执行。这样就为开发者提供了非常方便的扩展性,比如为dubbo接口实现ip白名单功能、监控功能 、日志记录等。
步骤如下:
- 实现
org.apache.dubbo.rpc.Filter
接口 - 使用
org.apache.dubbo.common.extension.Activate
接口进行对类进行注册 通过group 可以
指定生产端 消费端 如:
@Activate(group = {CommonConstants.CONSUMER)
- 计算方法运行时间的代码实现
- 在 META-INF.dubbo 中新建
org.apache.dubbo.rpc.Filter
文件,并将当前类的全名写入
timerFilter=包名.过滤器的名字
2. 负载均衡策略
负载均衡(Load Balance), 其实就是将请求分摊到多个操作单元上进行执行,从而共同完成工作任务。
负载均衡策略主要用于客户端存在多个提供者时进行选择某个提供者。
2.1 负载均衡基本配置
在集群负载均衡时,Dubbo 提供了多种均衡策略(包括随机、轮询、最少活跃调用数、一致性Hash),缺省为random随机调用。
//在服务消费者一方配置负载均衡策略
@Reference(check = false,loadbalance = "random")
//在服务提供者一方配置负载均衡
@Service(loadbalance = "random")
public class HelloServiceImpl implements HelloService {
public String sayHello(String name) {
return "hello " + name;
}
}
2.2自定义负载均衡器
负载均衡器在Dubbo中的SPI接口是org.apache.dubbo.rpc.cluster.LoadBalance
, 可以通过实现这个接口来实现自定义的负载均衡规则。
- 自定义负载均衡器
- 配置负载均衡器
在dubbo-spi-loadbalance工程的 META-INF/dubbo 目录下新建org.apache.dubbo.rpc.cluster.LoadBalance
文件,并将当前类的全名写入
onlyFirst=com.lvqz.loadbalance.OnlyFirstBalance
- 在服务消费方指定自定义负载均衡器 onlyFirst
3. 异步调用
Dubbo不只提供了堵塞式的的同步调用,同时提供了异步调用的方式。这种方式主要应用于提供者接口响应耗时明显,消费者端可以利用调用接口的时间去做一些其他的接口调用,利用 Future
模式来异步等待和获取结果即可。这种方式可以大大的提升消费者端的利用率。 目前这种方式可以通过XML的方式进行引入。
- 为了能够模拟等待,通过 int timeToWait参数,标明需要休眠多少毫秒后才会进行返回。
- 接口实现 为了模拟调用耗时 可以让线程等待一段时间
- 在消费者端,配置异步调用 注意消费端默认超时时间1000毫秒 如果提供端耗时大于1000毫秒会出现超时
- 测试,我们休眠100毫秒,然后再去进行获取结果。方法在同步调用时的返回值是空,我们可以通过
RpcContext.getContext().getFuture()
来进行获取Future对象来进行后续的结果等待操作。
4. 线程池
4.1 Dubbo已有线程池
dubbo在使用时,都是通过创建真实的业务线程池进行操作的。目前已知的线程池模型有两个和java中的相互对应:
- fix: 表示创建固定大小的线程池。也是Dubbo默认的使用方式,默认创建的执行线程数为200,并
且是没有任何等待队列的。所以再极端的情况下可能会存在问题,比如某个操作大量执行时,可能存在堵塞的情况。后面也会讲相关的处理办法。
- cache: 创建非固定大小的线程池,当线程不足时,会自动创建新的线程。但是使用这种的时候需
要注意,如果突然有高TPS的请求过来,方法没有及时完成,则会造成大量的线程创建,对系统的
CPU和负载都是压力,执行越多反而会拖慢整个系统。
5. 路由规则
路由是决定一次请求中需要发往目标机器的重要判断,通过对其控制可以决定请求的目标机器。我们可以通过创建这样的规则来决定一个请求会交给哪些服务器去处理。
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.lagou.service.HelloServi ce?category=routers&force=true&dynamic=true&rule=" + URL.encode("=> host != 你的 机器ip不能是127.0.0.1")));
}
}
5.1 路由规则详解
通过上面的程序,我们实际本质上就是通过在zookeeper中保存一个节点数据,来记录路由规则。
- route:// 表示路由规则的类型,支持条件路由规则和脚本路由规则,可扩展,必填。
- 0.0.0.0 表示对所有 IP 地址生效,如果只想对某个 IP 的生效,请填入具体 IP,必填。
- com.lagou.service.HelloService 表示只对指定服务生效,必填。
- category=routers 表示该数据为动态配置类型,必填。
- dynamic : 是否为持久数据,当指定服务重启时是否继续生效。必填。
- runtime : 是否在设置规则时自动缓存规则,如果设置为true则会影响部分性能。
- rule : 是整个路由最关键的配置,用于配置路由规则。
… => … 在这里 => 前面的就是表示消费者方的匹配规则,可以不填(代表全部)。 => 后方则必
须填写,表示当请求过来时,如果选择提供者的配置。官方这块儿也给出了详细的示例,可以按照那里来讲。
其中使用最多的便是 host 参数。 必填。
6. 服务动态降级
6.1 什么是服务降级
服务降级,当服务器压力剧增的情况下,根据当前业务情况及流量对一些服务有策略的降低服务级别,以释放服务器资源,保证核心任务的正常运行。
6.2 为什么要服务降级
而为什么要使用服务降级,这是防止分布式服务发生雪崩效应,什么是雪崩?就是蝴蝶效应,当一个请求发生超时,一直等待着服务响应,那么在高并发情况下,很多请求都是因为这样一直等着响应直到服务资源耗尽产生宕机,而宕机之后会导致分布式其他服务调用该宕机的服务也会出现资源耗尽宕机,这样下去将导致整个分布式服务都瘫痪,这就是雪崩。
6.3 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" />
- 使用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