Apache Dubbo是一款高性能的 Java RPC 框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源 Java RPC框架,可以和 Spring 框架无缝集成。
duboo 中文官网
第一部分:项目架构演变过程
单体架构 到 微服务架构的演变
单一应用架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,提升效率的方法之一是将应用拆成互不相干的几个应用,以提升效率。此时,用于加速前端页面开发的Web框架(MVC)是关键。
分布式服务架构
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键。
第二部分: Dubbo 架构与实战
Dubbo的架构
节点角色说明
- Provider 暴露服务的服务提供方
- Consumer 调用远程服务的服务消费方
- Registry 服务注册与发现的注册中心
- Monitor 统计服务的调用次数和调用时间的监控中心
- Container 服务运行容器
调用关系说明
- 服务容器负责启动,加载,运行服务提供者。
- 服务提供者在启动时,向注册中心注册自己提供的服务。
- 服务消费者在启动时,向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
- 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
- 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。
Dubbo 架构具有以下几个特点,分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。
服务注册中心Zookeeper
通过前面的 Dubbo 架构图可以看到,Registry(服务注册中心)在其中起着至关重要的作用。Dubbo官 方推荐使用Zookeeper作为服务注册中心。Zookeeper 是 Apache Hadoop 的子项目,作为 Dubbo 服务的注册中心,工业强度较高,可用于生产环境,并推荐使用 。
dubbo的开发案例
在Dubbo中所有的的服务调用都是基于接口去进行双方交互的。双方协定好Dubbo调用中的接口,提供者来提供实现类并且注册到注册中心上。
调用方则只需要引入该接口,并且同样注册到相同的注册中心上(消费者)。即可利用注册中心来实现集群感知功能,之后消费者即可对提供者进行调用。
我们所有的项目都是基于Maven去进行创建,这样相互在引用的时候只需要以依赖的形式进行展现就可以了。
并且这里我们会通过maven的父工程来统一依赖的版本。
程序实现分为以下几步骤:
- 建立maven工程 并且 创建API模块: 用于规范双方接口协定
- 提供provider模块,引入API模块,并且对其中的服务进行实现。将其注册到注册中心上,对外来
统一提供服务。
- 提供consumer模块,引入API模块,并且引入与提供者相同的注册中心。再进行服务调用。
- 注解版
- XML版
- 纯代码版
这里推荐用到的注册中心是 zookeeper, 所以顺便可以熟悉一下 zk 的常用命令
cd /Users/ale/Downloads/apache-zookeeper-3.5.8-bin/bin ./zkServer.sh start-foreground ./zkServer.sh start ./zkServer.sh status ./zkServer.sh stop
服务端会 qos 22222
23:13:49.846 [main] INFO org.apache.dubbo.qos.server.Server.start(Server.java:109) - [DUBBO] qos-server bind localhost:22222, dubbo version: 2.7.5, current host: 127.0.0.1
客户端会 qos 绑定失败
23:14:33.902 [main] WARN
org.apache.dubbo.qos.protocol.QosProtocolWrapper.startQosServer(QosProtocolWrapper.java:113) - [DUBBO] Fail to start qos server: , dubbo version: 2.7.5, current host: 127.0.0.1
java.net.BindException: Address already in use
解决办法, 重新指定客户端的 qos 端口即可.
Dubbo 的管理控制台
Dubbo管理控制台 dubbo-admin
作用
主要包含:服务管理 、 路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能。
如我们在开发时,需要知道 Zookeeper 注册中心都注册了哪些服务,有哪些消费者来消费这些服务。我 们可以通过部署一个管理中心来实现。其实管理中心就是一个 web 应用,原来是 war(2.6版本以前)包需 要部署到tomcat即可。现在是jar包可以直接通过java命令运行。
控制台安装步骤
1. 从git 上下载项目 https://github.com/apache/dubbo-admin 或者直接下载zip包 https://codeload.github.com/apache/dubbo-admin/zip/master 2. 在 dubbo-admin-server/src/main/resources/application.properties # 这里可以修改 tomcat 默认端口, 可选 server.port=7001 # 登录窗口的用户名和密码 spring.root.password=root spring.guest.password=guest # 指定注册中心地址, 这里根据自己的实际需要进行更改 dubbo.registry.address=zookeeper://127.0.0.1:2181 3.切换到项目所在的路径 使用mvn 打包 mvn clean package -Dmaven.test.skip=true 4.java 命令运行 java -jar 对应的jar包 java -jar ./target/dubbo-admin-0.0.1-SNAPSHOT.jar 5. 访问 http://localhost:7001 使用用户名root 和 密码root 进行登录即可.
Dubbo的相关配置
dubbo:application
对应 org.apache.dubbo.config.ApplicationConfig, 代表当前应用的信息
- name: 当前应用程序的名称,在dubbo-admin中我们也可以看到,这个代表这个应用名称。我们在真正时是时也会根据这个参数来进行聚合应用请求。
- owner: 当前应用程序的负责人,可以通过这个负责人找到其相关的应用列表,用于快速定位到责任人。
- qosEnable : 是否启动QoS 默认true
- qosPort : 启动QoS绑定的端口 默认 22222
- qosAcceptForeignIp: 是否允许远程访问 默认是false
可以在 xml dubbo-demo-consumer.xml
中可以进行配置
<!-- 消费方应用名,用于计算依赖关系,不是匹配条件,不要与提供方一样 --> <dubbo:application name="consumer-of-helloworld-app" owner="chengxu"> <dubbo:parameter key="qos.enable" value="true"></dubbo:parameter> <dubbo:parameter key="qos.port" value="22223"></dubbo:parameter> <!--默认是 false--> <dubbo:parameter key="qos.accept.foreign.ip" value="false"></dubbo:parameter> </dubbo:application>
当然, 也可以在配置文件中进行配置 dubbo-consumer.properties
# 这里写上应用的名字 dubbo.application.name=service-consumer dubbo.application.qosEnable=true dubbo.application.qosPort=true dubbo.application.qosAcceptForeignIp=true
qos运维相关, 需要使用 telnet 命令. 例如登录
telnet localhost 22222
dubbo:registry
org.apache.dubbo.config.RegistryConfig, 代表该模块所使用的注册中心。一个模块中的服务可以将
其注册到多个注册中心上,也可以注册到一个上。后面再service和reference也会引入这个注册中心。
- id :如果在当前服务中provider或者consumer中存在多个注册中心时,则使用需要增加该配置。在一些公司,会通过业务线的不同选择不同的注册中心,所以一般都会配置该值。
- address : 当前注册中心的访问地址。
- protocol : 当前注册中心所使用的协议是什么。也可以直接在 address 中写入,比如使用zookeeper,就可以写成 zookeeper://xx.xx.xx.xx:2181
- timeout : 当与注册中心不再同一个机房时,大多会把该参数延长。
dubbo:protocol
org.apache.dubbo.config.ProtocolConfig, 指定服务在进行数据传输所使用的协议。
- id : 在大公司,可能因为各个部门技术栈不同,所以可能会选择使用不同的协议进行交互。这里在多个协议使用时,需要指定。
- name : 指定协议名称。默认使用 dubbo 。
dubbo:service
org.apache.dubbo.config.ServiceConfig, 用于指定当前需要对外暴露的服务信息,后面也会具体讲解。和 dubbo:reference 大致相同。
- interface : 指定当前需要进行对外暴露的接口是什么。
- ref : 具体实现对象的引用,一般我们在生产级别都是使用Spring去进行Bean托管的,所以这里面一般也指的是Spring中的BeanId。
- version : 对外暴露的版本号。不同的版本号,消费者在消费的时候只会根据固定的版本号进行消费。
dubbo:reference 服务消费者引用服务配置。
org.apache.dubbo.config.ReferenceConfig, 消费者的配置,这里只做简单说明,后面会具体讲解。
- id : 指定该Bean在注册到Spring中的id。
- interface: 服务接口名
- version : 指定当前服务版本,与服务提供者的版本一致。
- registry : 指定所具体使用的注册中心地址。这里面也就是使用上面在 dubbo:registry 中所声明的id。
dubbo:method
org.apache.dubbo.config.MethodConfig, 用于在制定的 dubbo:service 或者 dubbo:reference 中的更具体一个层级,指定具体方法级别在进行RPC操作时候的配置,可以理解为对这上面层级中的配置针对于具体方法的特殊处理。
- name : 指定方法名称,用于对这个方法名称的RPC调用进行特殊配置。
- async: 是否异步 默认false
dubbo:service 和 dubbo:reference详解
这两个在dubbo中是我们最为常用的部分,其中有一些我们必然会接触到的属性。并且这里会讲到一些设置上的使用方案。
- mock: 用于在方法调用出现错误时,当做服务降级来统一对外返回结果,后面我们也会对这个方法做更多的介绍。可以放在消费者的 consumer 和 reference 标签中。
- timeout: 用于指定当前方法或者接口中所有方法的超时时间。我们一般都会根据提供者的时长来具体规定。比如我们在进行第三方服务依赖时可能会对接口的时长做放宽,防止第三方服务不稳定导致服务受损。可以放在提供者的service标签, 消费者的 customer(优先级比 reference 高) 或 reference 标签.
- check: 放在消费者的<customer>下的标签:用于在启动时,检查生产者是否有该服务。我们一般都会将这个值设置为false,不让其进行检查。因为如果出现模块之间循环引用的话,那么则可能会出现相互依赖,都进行check的话,那么这两个服务永远也启动不起来。
- retries: 可以放在消费者的<consumer> 或者 <reference>标签中。用于指定当前服务在执行时出现错误或者超时时的重试机制。
- 注意提供者是否有幂等,否则可能出现数据一致性问题
- 注意提供者是否有类似缓存机制,如出现大面积错误时,可能因为不停重试导致雪崩
- executes: 用于在提供者的 service 标签, 来确保最大的并行度。
- 可能导致集群功能无法充分利用或者堵塞
- 但是也可以启动部分对应用的保护功能
- 可以不做配置,结合后面的熔断限流使用
其它配置 参考官网-schema 配置, 官网介绍的非常详细且更新及时
第三部分: Dubbo 高级应用实战
SPI 负载均衡 异步调用 自定义线程池 路由规则 服务降级
SPI
SPI简介
SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制。 目前有不少框架用它来做服务的扩展发现,简单来说,它就是一种动态替换发现的机制。使用SPI机制的优势是实现解耦,使得第三方服务模块的装配控制逻辑与调用者的业务代码分离。
JDK中的SPI
Java中如果想要使用SPI功能,先提供标准服务接口,然后再提供相关接口实现和调用者。这样就可以通过SPI机制中约定好的信息进行查询相应的接口实现。
SPI遵循如下约定:
1、当服务提供者提供了接口的一种具体实现后,在 META-INF/services
目录下创建一个以“接口全限定名”为命名的文件,内容为实现类的全限定名;
com.lagou.service.impl.HumanHelloService
2、接口实现类所在的 jar 包放在主程序的 classpath 中;
3、主程序通过java.util.ServiceLoader动态装载实现模块,它通过扫描META-
INF/services
目录下的配置文件找到实现类的全限定名,把类加载到JVM;
package com.lagou.service.impl; import com.lagou.service.HelloService; /** * spi:人类打招呼 */ public class HumanHelloService implements HelloService { @Override public String sayHello(String name) { return "hello my friend"; } }
4、SPI的实现类必须携带一个无参构造方法;
demo-base\spi-demo-impl\src\main\resources\META-
INF\services\com.lagou.service.HelloService
- 通过 ServiceLoader ,进行调用
package com.lagou.test; import com.lagou.service.HelloService; import java.util.ServiceLoader; public class JavaSpiMain { public static void main(String[] args) { // 怎么得到实现了 HelloService 接口的组件呢,这里用到了 ServiceLoader 类 final ServiceLoader<HelloService> list = ServiceLoader.load(HelloService.class); for (HelloService helloService : list) { System.out.println("类名:" + helloService.getClass().getName()); System.out.println(helloService.sayHello("hi!")); } } }
Dubbo中的 SPI
dubbo 中大量的使用了 SPI 来作为扩展点,通过实现同一接口的前提下,可以进行定制自己的实现类。
比如比较常见的协议,负载均衡,都可以通过SPI的方式进行定制化,自己扩展。Dubbo中已经存在的所有已经实现好的扩展点
我们使用三个项目来演示Dubbo中扩展点的使用方式,一个主项目main,一个服务接口项目api,一个服务实现项目impl。
api项目创建
(1)导入坐标 dubbo
(2)创建接口
在接口上 使用 @SPI
package com.lagou.service; import org.apache.dubbo.common.extension.SPI; @SPI public interface HelloServiceForDubbo { String sayHello(String name); }
impl项目创建
(1)导入 api项目 的依赖
(2)建立实现类,为了表达支持多个实现的目的,这里分别创建两个实现。分别为 HumanHelloService 和 DogHelloService 。
(3)SPI进行声明操作,在 resources 目录下创建目录 META-INF/dubbo 目录,在目录下创建名称为com.lagou.dubbo.study.spi.demo.api.HelloService的文件,文件内部配置两个实现类名称和对应的全限定名
main项目创建
(1)导入坐标 接口项目 和 实现类项目
(2)创建 DubboSpiMain 和原先调用的方式不太相同, dubbo 有对其进行自我重新实现 需要借助 ExtensionLoader,创建新的运行项目。这里 demo 中的示例和 java中 的功能相同,查询出所有的已知实现,并且调用
package com.lagou.test; import com.lagou.service.HelloServiceForDubbo; import org.apache.dubbo.common.URL; import org.apache.dubbo.common.extension.ExtensionLoader; import java.util.Set; public class DubboSpiMain { public static void main(String[] args) { // 获取拓展加载器 final ExtensionLoader<HelloServiceForDubbo> extensionLoader = ExtensionLoader.getExtensionLoader(HelloServiceForDubbo.class); // 遍历所有支持的拓展点 META-INF/dubbo final Set<String> extensionNames = extensionLoader.getSupportedExtensions(); for (String extensionName : extensionNames) { // 遍历拓展点对象 final HelloServiceForDubbo helloServiceForDubbo = extensionLoader.getExtension(extensionName); System.out.println(helloServiceForDubbo.sayHello("")); } }
(3)dubbo自己做SPI的目的
- JDK 标准的 SPI 会一次性实例化扩展点所有实现,如果有扩展实现初始化很耗时,但如果没用上也加载,会很浪费资源
- 如果有扩展点加载失败,则所有扩展点无法使用
- 提供了对扩展点包装的功能(Adaptive),并且还支持通过set的方式对其他的扩展点进行注入
Dubbo SPI中的Adaptive功能
Dubbo 中的 Adaptive功能,主要解决的问题是如何 动态的选择具体的扩展点。通过 getAdaptiveExtension方法统一对指定接口对应的所有扩展点进行封装,通过URL的方式对扩展点来进行动态选择。 (dubbo中所有的注册信息都是通过URL的形式进行处理的。) 这里同样采用相同的方式进行实现。
api 中的 HelloService 扩展如下方法, 与原先类似,在sayHello中增加 Adaptive 注解,并且在参数中提供URL参数.注意这里的URL参数的类为 org.apache.dubbo.common.URL。其中@SPI 可以指定一个字符串参数,用于指明该SPI的默认实现。
(2)创建实现类与上面 Service 实现类代码相似,只需增加URL形参即可
(3)编写 DubboAdaptiveMain
最后在获取的时候方式有所改变,需要传入URL参数,并且在参数中指定具体的实现类参数如:
public class DubboAdaptiveMain { public static void main(String[] args) { URL url = URL.valueOf("test://localhost/hello?hello.service=dog"); final HelloService adaptiveExtension = ExtensionLoader.getExtensionLoader(HelloService.class).getAdaptiveExtension(); adaptiveExtension.sayHello(url); } }
注意:
- 因为在这里只是临时测试,所以为了保证 URL 规范,前面的信息均为测试值即可,关键的点在于 hello.service 参数,这个参数的值指定的就是具体的实现方式。关于为什么叫 hello.service 是因为这个接口的名称,其中后面的大写部分被dubbo自动转码为 . 分割。
HelloService.class -> hello.service
- 通过 getAdaptiveExtension 来提供一个统一的类来对所有的扩展点提供支持(底层对所有的扩展点进行封装)。
- 调用时通过参数中增加 URL 对象来实现动态的扩展点使用。
- 如果URL没有提供该参数,则该方法会使用默认在 SPI 注解中声明的实现。
package com.lagou.service; import org.apache.dubbo.common.URL; import org.apache.dubbo.common.extension.Adaptive; import org.apache.dubbo.common.extension.SPI; /** * 指定默认匹配 human */ @SPI("human") public interface HelloServiceForDubbo { /** * 这里加上 Adaptive 注解,使得有动态的选择能力 * @param url * @return */ @Adaptive String sayHello(URL url); }
Dubbo调用时拦截操作
与很多框架一样,Dubbo 也存在拦截(过滤)机制,可以通过该机制在执行目标程序前后执行我们指定的代码。
Dubbo 的 Filter 机制,是专门为服务提供方和服务消费方调用过程进行拦截设计的,每次远程方法执行,该拦截都会被执行。这样就为开发者提供了非常方便的扩展性,比如为 dubbo 接口实现ip白名单功能、监控功能 、日志记录等。
步骤如下:
(1)实现 org.apache.dubbo.rpc.Filter 接口
(2)使用 org.apache.dubbo.common.extension.Activate 接口进行对类进行注册,通过group 可以指定生产端、消费端
(3)计算方法运行时间的代码实现
(4)在 META-INF.dubbo 中新建 org.apache.dubbo.rpc.Filter 文件,并将当前类的全名写入
注意:一般类似于这样的功能都是单独开发依赖的,所以再使用方的项目中只需要引入依赖,在调用接口时,该方法便会自动拦截
异步调用
Dubbo不只提供了堵塞式的的同步调用,同时提供了异步调用的方式。这种方式主要应用于提供者接口响应耗时明显,消费者端可以利用调用接口的时间去做一些其他的接口调用,利用 Future 模式来异步等待和获取结果即可。这种方式可以大大的提升消费者端的利用率。 目前这种方式可以通过XML的方式进行引入。
线程池
Dubbo已有线程池
dubbo 在使用时,都是通过创建真实的业务线程池进行操作的。目前已知的线程池模型有两个和java中的相互对应:
- fix: 表示创建固定大小的线程池。也是Dubbo默认的使用方式,默认创建的执行线程数为200,并且是没有任何等待队列的。所以再极端的情况下可能会存在问题,比如某个操作大量执行时,可能存在堵塞的情况。后面也会讲相关的处理办法。
- cache: 创建非固定大小的线程池,当线程不足时,会自动创建新的线程。但是使用这种的时候需要注意,如果突然有高TPS的请求过来,方法没有及时完成,则会造成大量的线程创建,对系统的CPU和负载都是压力,执行越多反而会拖慢整个系统。
自定义线程池
在真实的使用过程中可能会因为使用 fix模式的线程池,导致具体某些业务场景因为线程池中的线程数量不足而产生错误,而很多业务研发是对这些无感知的,只有当出现错误的时候才会去查看告警或者通过客户反馈出现严重的问题才去查看,结果发现是线程池满了。所以可以在创建线程池的时,通过某些手段对这个线程池进行监控,这样就可以进行及时的扩缩容机器或者告警。下面的这个程序就是这样子的,会在创建线程池后进行对其监控,并且及时作出相应处理。
(1)线程池实现, 这里主要是基于对 FixedThreadPool 中的实现做扩展出线程监控的部分
package com.lagou; import org.apache.dubbo.common.URL; import org.apache.dubbo.common.threadpool.ThreadPool; import org.apache.dubbo.common.threadpool.support.fixed.FixedThreadPool; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import java.util.Map; import java.util.concurrent.*; /** * @author likai * @date 2020/11/21 */ public class WatchThreadPool extends FixedThreadPool implements Runnable { private static final Logger log = LoggerFactory.getLogger(WatchThreadPool.class); // 定义一个阈值 private static final double ALARM_PERCENT = 0.80; private final Map<URL, ThreadPoolExecutor> THREAD_POOLS = new ConcurrentHashMap<>(); // 每隔3秒打印线程使用情况 public WatchThreadPool() { 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); log.info("线程池执行状态:[{}/{}]:{}%", activeCount, poolSize, usedNum); if (used >= ALARM_PERCENT) { log.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.lagou.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.lagou.service.HelloService 表示只对指定服务生效,必填。
- category=routers 表示该数据为动态配置类型,必填。
- dynamic : 是否为持久数据,当指定服务重启时是否继续生效。必填。
- runtime : 是否在设置规则时自动缓存规则,如果设置为true则会影响部分性能。
- rule : 是整个路由最关键的配置,用于配置路由规则。
... => ... 在这里 => 前面的就是表示消费者方的匹配规则,可以不填(代表全部)。 => 后方则必须填写,表示当请求过来时,如果选择提供者的配置。官方这块儿也给出了详细的示例,可以按照那里来讲。其中使用最多的便是 host 参数。 必填。
路由与上线系统结合
当公司到了一定的规模之后,一般都会有自己的上线系统,专门用于服务上线。方便后期进行维护和记录的追查。我们去想象这样的一个场景,一个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 机制比较特殊,所以需要利用一个专门的 outerFactory 来生成,原因在于并不是所有的都需要添加路由,所以需要利用 @Activate 来锁定具体哪些服务才需要生成使用。
(6)对 RouterFactory 进行注册,同样放入到
META-INF/dubbo/org.apache.dubbo.rpc.cluster.RouterFactory 文件中。
restartInstances=com.lagou.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的整体设计 服务注册与发现的源码分析
作业
编程题一:将Web请求 IP 透传到 Dubbo 服务中
通过扩展Dubbo的Filter(TransportIPFilter),完成Web请求的真实IP透传到Dubbo服务当中,并在Dubbo服务中打印请求的IP
题目要求:
- 构建一个Web项目(A),提供一个HTTP接口;构建2个Dubbo服务(B和C),各提供一个Dubbo接口,被Web项目调用(如下图所示)
- 从 Web 项目获取请求的IP,通过 TransportIPFilter 完成把 IP 设置到RpcContext 中
- 在两个 Dubbo项目(B和C)中,从 RpcContext 获取IP并打印到控制台,B和C都应该正确打印IP
- 注意:不可在业务方法调用Dubbo接口前采用硬编码的方式设置IP
编程题二:简易版Dubbo方法级性能监控
在真实业务场景中,经常需要对各个业务接口的响应性能进行监控(常用指标为:TP90、TP99)
下面通过扩展 Dubbo的Filter(TPMonitorFilter),完成简易版本 Dubbo 接口方法级性能监控,记录下TP90、TP99请求的耗时情况
题目要求:
- 编写一个Dubbo服务,提供3个方法(methodA、methodB、methodC),每方法都实现了随机休眠0-100ms
- 编写一个消费端程序,不断调用 Dubbo 服务的3个方法(建议利用线程池进行并行调用,确保在1分钟内可以被调用2000次以上)
- 利用 TPMonitorFilter 在消费端记录每个方法的请求耗时时间(异步调用不进行记录)
- 每隔 5s 打印一次最近1分钟内每个方法的TP90、TP99的耗时情况
作业1
分析与思路
- dubbo-api 提供接口
public interface HelloService { String sayHello(String name); }
- dubbo-provider 和 dubbo-provider2 提供对接口的实现。 这里以 dubbo-provider 举例。
@Service(interfaceClass = HelloService.class,retries = 0) @Component public class HelloServiceImpl implements HelloService { @Override public String sayHello(String name) { String requestIp = RpcContext.getContext().getAttachment(Constants.REQUEST_IP); System.out.println("provider1: sayHello + " +requestIp); return "provider1: sayHello + " +requestIp; } }
并在 resoruces下添加配置文件
transportIPFilter=com.lagou.filter.TransportIPFilter
- dubbo-consumer 使用了 过滤器进行远程 ip 的暂存
/** * 需要加入 注解 或者 手动开启,否则过滤器不生效 */ @Component @WebFilter(urlPatterns = "/hello") public class IPFilter implements Filter { @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { try { final String remoteAddr = servletRequest.getRemoteAddr(); System.out.println("过滤器 doFilter 方法获得 remoteAddr = " + remoteAddr); IPThreadLocal.set(servletRequest.getRemoteAddr()); filterChain.doFilter(servletRequest, servletResponse); } finally { IPThreadLocal.remove(); } } }
- dobbo 过滤器进行数据的取出和传递(TransportIPFilter完成把IP设置到 RpcContext)
/** * 给过滤器起一个名字 */ @Activate public class TransportIPFilter implements Filter { @Override public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { // 获得 IP final String ip = IPThreadLocal.get(); RpcContext.getContext().getAttachments().put(Constants.REQUEST_IP, ip); System.out.println("dubbo Filter 存入ip" + ip); return invoker.invoke(invocation); } }
- 这其中涉及到了我写在 dubbo-api 模块的工具类 IPThreadLocal.
public class IPThreadLocal { private static final ThreadLocal<String> THREAD_LOCAL = new ThreadLocal<String>(); public static void set(String ip) { THREAD_LOCAL.set(ip); } public static String get() { return THREAD_LOCAL.get(); } public static void remove() { THREAD_LOCAL.remove(); } }
- 分别启动 provider 和 customer 端,通过浏览器进行访问。customer 模块的 controller 如下。
@RestController public class HelloController { @Reference(loadbalance = "roundrobin") private HelloService dubboTestApi; @GetMapping("/hello") public String hello() { return this.dubboTestApi.sayHello("dubbo"); } }
作业2 思路
- dubbo-api 模块提供接口, dubbo-provider 提供实现, dubbo-consumer 模块在消费的时候传参毫秒数,用于控制休眠一定的毫秒数.
dubbo-api 用于提供接口
/** * 定义一个基础接口 */ public interface HelloService { String methodA(String name, int mills); String methodB(String name, int mills); String methodC(String name, int mills); }
provider 对其进行实现
public class HelloServiceImpl implements HelloService { @Override public String methodA(String name, int mills) { try { TimeUnit.MILLISECONDS.sleep(mills); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("method A : " + name); return "method A : " + name; } @Override public String methodB(String name, int mills) { try { TimeUnit.MILLISECONDS.sleep(mills); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("method B : " + name); return "method B : " + name; } @Override public String methodC(String name, int mills) { try { TimeUnit.MILLISECONDS.sleep(mills); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println("method C : " + name); return "method C : " + name; } }
- dubbo-consumer 模块中利用线程池进行并行调用 dubbo 的方法
ExecutorService executorService = Executors.newFixedThreadPool(3); // 确保在1分钟内可以被调用 2000 次以上 HelloService helloService = (HelloService) context.getBean("helloService"); for (int i = 0; i < 2300; i++) { executorService.execute(new HelloServiceThread(helloService)); }
这里涉及到真正干活的 HelloServiceThread 线程类
class HelloServiceThread extends Thread { private final HelloService helloService; HelloServiceThread(HelloService helloService) { super(); this.helloService = helloService; } @Override public void run() { try { TimeUnit.MILLISECONDS.sleep(30); } catch (InterruptedException e) { e.printStackTrace(); } final int i = ThreadLocalRandom.current().nextInt(3); String result = null; switch (i) { case 0: result = helloService.methodA("", ThreadLocalRandom.current().nextInt(100)); break; case 1: result = helloService.methodB("", ThreadLocalRandom.current().nextInt(100)); break; case 2: result = helloService.methodC("", ThreadLocalRandom.current().nextInt(100)); break; default: break; } // 调用结果 System.out.println(Thread.currentThread().getName() + " result = " + Objects.toString(result, "")); } }
XmlConsumer 用于不停的进行消费,确保在1分钟内可以被调用 2000 次以上,这里用到了 线程池。
public class XmlConsumer { public static void main(String[] args) throws Exception { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{"classpath:dubbo-demo-consumer.xml"}); // 起始时间 long startMills = Instant.now().toEpochMilli(); ExecutorService executorService = Executors.newFixedThreadPool(3); // 确保在1分钟内可以被调用 2000 次以上 HelloService helloService = (HelloService) context.getBean("helloService"); for (int i = 0; i < 2300; i++) { executorService.execute(new HelloServiceThread(helloService)); } executorService.shutdown(); executorService.awaitTermination(3, TimeUnit.MINUTES); // 终止时间 long endMills = Instant.now().toEpochMilli(); System.out.println("-----总耗时" + (endMills - startMills) + "-----"); } }
- spi-filter模块下的 自定义 dubbo 过滤器 TPMonitorFilter , 分别进行方法的请求的统计 和 TP90 和 99的结果输出。
以下是 TPMonitorFilter 的代码片段,这里可以拿到方法名和耗时时间。
@Override public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { long epochMilli = Instant.now().toEpochMilli(); Result invoke = invoker.invoke(invocation); final LocalDateTime now = LocalDateTime.now(); final Instant endInstant = now.atZone(ZoneId.systemDefault()).toInstant(); // 方法耗时 int costMills = (int) (endInstant.toEpochMilli() - epochMilli); // 方法名称 String methodName = invocation.getMethodName(); ... ...
对方法耗时进行统计
/** * recordArray 共计 60 等份 * * 调用时间 1ms 2ms 3ms 4ms 5ms * 方法methodA 1 2 3 * 方法methodB 3 3 1 5 * 方法methodC 1 8 3 */ // localDateTime 对象包含了时分秒信息,取出秒 作为下标 int index = now.getSecond(); // 这里肯定不为 null, 若时间比对成功则则 进行 put if (recordArray[index].isDateTimeEquals(now)) { Integer value = recordArray[index].get(methodName, costMills); if (value != null) { recordArray[index].put(methodName, costMills, value + 1); } else { recordArray[index].put(methodName, costMills, 1); } } else { // 否则表示钟或小时至少有一个不存在则清空该 table 后重新put recordArray[index].clear(); recordArray[index].setDateTime(now); // 秒不相等,判断分是否相等。 若相等。 // 0~1 1_2 58~59 59~60(0) 一看到1分0秒,就表示完结了。 3分1秒 4分0秒 9分3秒 ~ 10分2秒 // 0 59 181~182 240~241 543~544 ~ 602~603 recordArray[index].put(methodName, costMills, 1); }
这里用到了自定义数据类型 RecordTable
/** * 一种类似表格的数据接口,类似 Map<A, Map<B,C>>类型。 */ class RecordTable { /** * 总记录数 */ private static int count = 0; /** * 内部使用线程安全的 Google guava 包下的 Table 类型 */ private final Table<String, Integer, Integer> table = Tables.synchronizedTable(HashBasedTable.create()); /** * 包含时间信息,记录为 1 秒 */ private LocalDateTime dateTime; public static RecordTable[] newArray() { count = 0; // 共计 60 等份 int length = 60; final RecordTable[] array = new RecordTable[length]; final LocalDateTime now = LocalDateTime.now(); for (int i = 0; i < 60; i++) { array[i] = new RecordTable(); array[i].setDateTime(now); }; return array; } public RecordTable() {} public Integer get(@Nullable Object rowKey, @Nullable Object columnKey) { return table.get(rowKey, columnKey); } public Integer put(String rowKey, Integer columnKey, Integer value) { count++; System.out.println("put 的次数 =" + count); return table.put(rowKey, columnKey, value); } /** * 若 日期 和 时分秒 相等则认为是相等 * * @param obj * @return */ public boolean isDateTimeEquals(Object obj) { if (obj instanceof LocalDateTime) { LocalDateTime other = (LocalDateTime) obj; if (this.dateTime != null && this.dateTime.toLocalDate().equals(other.toLocalDate())) { final LocalTime localTime = this.dateTime.toLocalTime(); final LocalTime otherLocalTime = other.toLocalTime(); return localTime.getHour() == otherLocalTime.getHour() && localTime.getMinute() == otherLocalTime.getMinute() && localTime.getSecond() == otherLocalTime.getSecond(); } return false; } return false; } public void clear() { table.clear(); } public Map<String, Map<Integer, Integer>> rowMap() { return table.rowMap(); } public boolean isEmpty(){ return table.isEmpty(); } public LocalDateTime getDateTime() { return dateTime; } public void setDateTime(LocalDateTime dateTime) { this.dateTime = dateTime; } }
对请求耗时进行处理,打印 TP90 和 TP99信息。
@Override public void run() { // 每隔 5s 打印一次最近1分钟内每个方法的TP90、TP99的耗时情况 System.out.println("----------每5s一次的任务开始----------"); // 总行数(最大值为 length) int totalColumnSize = 0; // 总记录数(执行方法的总次数) int totalSize = 0; int aTotalSize = 0; int bTotalSize = 0; int cTotalSize = 0; List<Integer> listA = new ArrayList<>(800); List<Integer> listB = new ArrayList<>(800); List<Integer> listC = new ArrayList<>(800); for (int i = 0; i < recordArray.length; i++) { if (recordArray[i] == null || recordArray[i].isEmpty()) { continue; } // 行记录数 = (方法A+B+C调用的总次数) int size = 0; // 每行方法A的调用次数 int methodAtotalSize = 0; int methodBtotalSize = 0; int methodCtotalSize = 0; final Map<String, Map<Integer, Integer>> rowMap = recordArray[i].rowMap(); for (Map.Entry<String, Map<Integer, Integer>> entry : rowMap.entrySet()) { final String methodName = entry.getKey(); final Map<Integer, Integer> value = entry.getValue(); if (value != null) { for (Map.Entry<Integer, Integer> valueEntry : value.entrySet()) { // 消耗毫秒数 Integer costMills = valueEntry.getKey(); // 消费次数 final Integer count = valueEntry.getValue(); size += count; if ("methodA".equalsIgnoreCase(methodName)) { methodAtotalSize += count; for (int j = 0; j < count; j++) { listA.add(costMills); } } else if ("methodB".equalsIgnoreCase(methodName)) { methodBtotalSize += count; for (int j = 0; j < count; j++) { listB.add(costMills); } } else if ("methodC".equalsIgnoreCase(methodName)) { methodCtotalSize += count; for (int j = 0; j < count; j++) { listC.add(costMills); } } } if ("methodA".equalsIgnoreCase(methodName)) { aTotalSize += methodAtotalSize; } else if ("methodB".equalsIgnoreCase(methodName)) { bTotalSize += methodBtotalSize; } else if ("methodC".equalsIgnoreCase(methodName)) { cTotalSize += methodCtotalSize; } } } totalColumnSize++; totalSize += size; System.out.println("行记录数" + size + "其中A记录数 = " + methodAtotalSize + ", B记录数 = " + methodBtotalSize + ", C记录数 = " + methodCtotalSize + ", 下标为" + i + ", 时间为: " + recordArray[i].getDateTime() + ", " + recordArray[i].rowMap()); } System.out.println("总记录数 = " + totalSize + "("+ aTotalSize +", " + bTotalSize +", " + cTotalSize +")" + ", 总行数 = " + totalColumnSize + "\n------每5s一次的任务结束-----"); // A的 top 90 int aTop90 = (int) Math.ceil(aTotalSize * 0.9D) -1; int aTop99 = (int) Math.ceil(aTotalSize * 0.99D) - 1; // 升序取第 %90 位 或 逆序取第 %10 System.out.println("top A T90下标=" + aTop90 + ", T99 下标=" + aTop99); Object[] a = listA.toArray(); Arrays.sort(a, (Comparator) new TPComparator()); System.out.println(Arrays.toString(a)); System.out.println("top A T90 =" + a[aTop90] + ", T99 =" + a[aTop99] + "\n---"); // B的 top 90 int bTop90 = (int) Math.ceil(bTotalSize * 90D / 100) - 1; int bTop99 = (int) Math.ceil(bTotalSize * 99D / 100) - 1; System.out.println("top B T90下标=" + bTop90 + ", T99下标=" + bTop99); Object[] b = listB.toArray(); Arrays.sort(b, (Comparator) new TPComparator()); System.out.println(Arrays.toString(b)); System.out.println("top B T90 =" + b[bTop90] + ", T99 =" + b[bTop99] + "\n---"); // C的 top 90 int cTop90 = (int) Math.ceil(cTotalSize * 90D / 100) - 1; int cTop99 = (int) Math.ceil(cTotalSize * 99D / 100) - 1; System.out.println("top C T90下标=" + cTop90 + ", T99下标=" + cTop99); Object[] c = listC.toArray(); Arrays.sort(c, (Comparator) new TPComparator()); System.out.println(Arrays.toString(c)); System.out.println("top C T90 =" + c[cTop90] + ", T99 =" + c[cTop99] + "\n---"); } }
TP 指标到底是啥?
TP 指标: TP50:指在一个时间段内(如5分钟),统计该方法每次调用所消耗的时间,并将这些时间按从小到大的顺序进行排序,取第 50% 的那个值作为 TP50 值;配置此监控指标对应的报警阀值后,需要保证在这个时间段内该方法所有调用的消耗时间至少有 50% 的值要小于此阀值,否则系统将会报警。TP90,TP99,TP999 与 TP50值计算方式一致,它们分别代表着对方法的不同性能要求,TP50相对较低,TP90则比较高,TP99,TP999 则对方法性能要求很高
参考
dubbo入门和springboot集成dubbo小例子 - 会当临绝顶forever - 博客园
https://www.cnblogs.com/baijinqiang/p/10848259.html
dubbo-spring-boot-project/dubbo-spring-boot-samples at master · apache/dubbo-spring-boot-project
https://github.com/apache/dubbo-spring-boot-project/tree/master/dubbo-spring-boot-samples