Dubbo的笔记

Dubbo:

近期学习dubbo,在此记下一下dubbo的个人理解以及一些要点,具体的内容呢,dubbo官网已经非常清晰的介绍了,所以在此不啰嗦太多.只记录一些知识点.

dubbo官网: http://dubbo.apache.org/zh-cn/

简介:

	阿里巴巴的开源RPC框架,2012年鼎盛 2014年停更,2017年重启更新 2018年捐献给apache组织,ali的duboo版本停止在2.6版本,后期都为apache的版本
三大特性:
	面向接口的rpc框架、优秀的负载均衡和容错性、服务注册自动发现(我估计是zk的监听机制)
其余优点:
	高度可扩展、运行时流量调度、可视化管理工具

Dubbo的处理流程:

provider:服务者,提供服务
consumer:消费者,负责调用
registry:注册中心,负责让消费者感知到服务存在的中心(订阅服务)
monitor:监控中心
container:服务的存储容器
流程:
	1:服务者注册服务给注册中心
	2:消费者去注册中心订阅:去注册中心拉取节点列表
	3:注册中心把当前注册的服务用长链接的url形式返回给消费者
	4:消费者调用(可负载),调用失败重新调用
	5:把调用的记录等信息 定时发送给监控中心

Dubbo的hello world:

编写provider注意事项:
	这里的业务类使用Service注解时,就要使用apache.dubbo的@Service
	配置文件要配置的属性:
		dubbo.application.name
		dubbo.protocol(协议)
		dubbo.port
	需要用注解配置dubbo的配置文件
	需要注解配置enabledubbo
编写comsumer注意事项:
	调用service业务时 注入时需要使用@Refrese
	配置文件的属性:
		dubbo.application.name
		dubbo.registry.address zookeeper的注册中心
	填写@EnableDubbo
	填写@扫描配置文件
	填写bean扫描目录
XML的配置方式:
	类似于spring的配置风格.

Dubbo的配置:

application标签:
	name:名称、owner:负责人
	标签内可设置parameter标签来添加属性
	QOS:在线发布命令
	qosEnable是否启动QoS default:true
	qosPort:QOS绑定端口 默认22222
	qosAcceptForeignIp:是否允许远程访问 默认false
registry:
	zookeeper的注册中心
protocol:
	传输服务的协议指定.根据每个部门的技术栈可多个设置
service:
	具体暴露的接口
reference:
	消费者对使用的接口进行配置. 把这个接口对应到哪个暴露的服务呢,就干这个的
method:
	在更具体的指定某个接口的某个方法
其他和详情可查阅dubbo官网的配置(阿里是最良心的)
comsumer:
	客户端的一些配置属性
	check:检查当前业务中是否有提供者提供并有效,默认为true.如果没有某个业务会报错,设置范围:comsumer全局,reference单个服务,method单个方法
	retries:设置异常情况是否重试以及重试机制.需要考虑该接口的一个业务场景,如果该业务为幂等性(无论多少次结果都一致)那么可以使用,如果是事物提交类操作,那么需要考虑多次提交的后果,需要防范.设置范围:comsumer全局,reference单个服务,method单个方法
	设置范围:comsumer全局,reference单个服务,method单个方法
	timeout:
		设置超时时间,超过这个时间就认为超时,放弃调用,根据消费者的调用情况,进行一定的放宽,最少也得比提供者的处理时间要长,否则就会一直出现错误. 设置范围:comsumer全局,reference单个服务,method单个方法
	mock的作用:
		设置超时异常的处理类.如果没有就抛出异常 默认就是你的服务类名加上Mock,设置范围:comsumer全局,reference单个服务,method单个方法()有待验证

Dubbo高级:

SPI:JDK内置服务发现机制

SPI约定:
	MATA_INF/services下创建接口全限定名的文件,内容为实现类的全限定名
	借口实现类所在的jar包放在主程序的classpath中
	主程序通过ServiceLoader动态装在实现模块,它扫描了services目录下的配置文件,动态将类加载到jvm
	实现类必须携带无参构造(给类加载器初始化用的)

Dubbo的SPI:

	对spi进行了扩展编写
	与javaSPI的区别:
	1:在api模块中将服务借口 设置@SPI注解
	2:META-INF下建立的是dubbo目录而不是services
	3:在每个服务的文件中:每个服务实现类前要加一个key否则无法扩展
	这么做的目的:
	1:JDK会一次性实例化所有实现.这样会浪费资源
	2:如果一个实现加载失败,那么所有实现都没法用
	3:提供了新功能Adaptive,还支持通过set方式进行注入
	Dubbo SPI中的 Adaptive: 动态选择拓展

Duboo的过滤器:

	在SPI的基础上开发的(过滤器也需要在META-INF里创建定义文件)
	为了结构清晰,过滤器尽量为单独的一个项目.方便维护和开发.
	@Active注解需要声明当前过滤器拦截哪一方,选择哪一方 就在哪一方的工程中进行执行,可多方添加.
	在消费者或生产者 只需要添加filter的依赖就可以使用该过滤器

Dubbo rpc调用负载均衡:

	策略:随机(默认)、轮询、最少活跃调用数、一致性hash算法
	如何设置 在service或reference上设置loadbalance属性
	自定义负载均衡策略:
		也是SPI风格开发.实现LoadBalance接口,就可以根据自己的需求编写最佳返回invoker.引入maven依赖,使用时注解中设置 spi配置文件中LoadBalance的实现类的key

Dubbo 异步调用:

	只能xml里设置,注解无法设置具体方法标签.如果正常调用方法,使用了异步async的话,不会等待返回结果.所以无法接收到结果.要用falutre来接收,RpcContext.get...

Dubbo 线程池:

	有两种:fix固定线程,cache自增线程池 固定会造成程序崩溃,自增会一直增大造成服务器崩溃.都不太好,需要自定义设置一些边界和预警来提醒我们智能设置
	自定义线程池:
		继承ThreadPool的接口的实现类(如FixedThreadPool),
		将线程池处理模块单独启动线程(一定的.)
		利用父类创建线程池.
		在线程方法做具体处理

Dubbo的路由:

	路由规则可以动态添加,在注册中心上进行设置
	路由规则:
		route://规则类型 必填
		0.0.0.0:所有IP,也可单独设置IP 必填
		指定的serviceName 如org.demo.HelloService 必填
		group:指定group生效,不写就是所有不配置group的生效
		version:指定version生效,不写就是所有不配置version的生效
		category=routers 该条配置为动态配置 必填
		dynamic=false 是否持久化在注册中心
		runtime 设置自动缓存 规则
		rule 具体的规则 
			=>左侧为消费者为空适用所有消费者  右侧为提供者 为空表示禁止访问.(没有任何提供者可以匹配规则那就是全禁止了)
		路由的应用场景:
			当提供者一些节点再启动或者重启时,服务不可用.这时需要路由功能进行灰度保护,防止消费者请求该提供者.利用了zk的监听节点功能,将启动中的提供者放入灰度文件夹中.进行请求时,先判断灰度文件夹中是否存在该节点,如果有,请求路由转发.如果没有正常访问.当该提供者启动完成时,灰度文件夹将该节点删除.(也就是会有两个目录,记录所有提供者和灰度提供者)
		自定义路由规则类
			实现Router接口
			自定义route类的route方法中,将存在于重启列表的invoker进行抛出.不放在可调用列表中.剩下的进行返回.
				(这个方法是什么时候调用的呢?
					在源码剖析前,我的猜测是在客户端调用服务时,dubbo会先去匹配route规则,这时就会调用这个自定义route规则类.然后就抛出了那些正在重启的提供者)
				(源码剖析的原理:)

Dubbo服务降级:

	给核心服务工程腾地儿.释放资源给核心服务
	方案:屏蔽:直接返回给消费者null对象.(没有请求提供者)
			容错:在调用了后超时了再返回null
	admin系统可直接对消费者设置
	@Reference注解设置mock属性 fouce屏蔽返回  fail超时返回(默认)