dubbo 总结

分布式 rpc框架（远程过程调用）
用来维护治理分布式系统中复杂的调用关系！
archiitect

注册中心 消费者 生产者 container 监控中心
**消费者同步调用服务提供者！

zookeeper

树型目录服务 

超时

精确设置的优先：方法优先 接口次之 全局再次之
消费者设置的优先（级别一样的情况下）
	无论是time-out retries(重试 默认轮训) loadblanace actives等都是一样的规则

配置多版本

可以用version进行配置   实现灰度发布

本地存根

在调用provider之前进行参数验证或者缓存的时候可以使用本地存根 远程服务接口相当于在本地也有一份存根代码 满足要求再用远程代理对象调用远程服务
1实现接口
2写有参构造器（传入的是远程代理对象）
3写reference配置文件

高可用

消费者调用过一次提供者的话  即使注册中心宕机 消费者还是可以通过本地缓存去调用（已经知道提供者在哪台机器了，，，，，，监控中心 注册中心集群也是一样的）

dubbo 直连

即使没有注册中心 也可以通过dubbo进行直连. reference注解写上提供者的ip端口号即可！

集群下的dubbo负载均衡

1按权重随机
2按权重轮训：访问还是轮训 但是最后考虑权重值
3最少活跃调用数 相同活跃的随机   使得越慢的调用越少（越慢的提供者调用前后技术差越大）
4一致性hash

默认按照权重进行随机的负载均衡机制！！！
可以通过注解erference进行修改loadbalance机制   可以在service注解写权重 也可以在dubbo控制台进行修改

服务降级

对一些服务 页面不处理或简单的处理 ===》从而释放服务器的资源 保证核心交易正常运行 

方法：（都是在消费方设置）
			1消费方调用服务的时候直接返回null 不进行远程调用
						mock = force：return + null
						也可以在dubbo控制台设置 进行屏蔽
		    2 消费方进行服务调用的时候 由于网络波动或者其他原因（超时）调用失败后 返回null 不抛出异常  （好处也有减少不重要服务不稳定的时候对调用方和服务提供方的影响）
		    			dubbo控制台 点击 容错

集群容错模式
集群调用失败的时候的方案

1重新切换到能提供服务的其他机器
2只发起一次调用 失败立即报错   （有的幂等性操作可以retry多次的  但是非幂等的不行）
3忽略出现的异常  写入审计日志
4失败自动恢复   失败一段时间后定时的进行调用  适用于消息通知 和一些必须要成功的调用
5对于实时性要求高的 可以并行调用 同事调用多台服务器上的同一个服务
6调用服务的全部机器 任何一台有问题都认为调用失败 用来更新缓存 更新本地日志等等（就是每台服务器都必须成功）

可以在service 和 reference标签中配置

可以整合hystrix进行服务容错

RPC原理

远程过程调用

computer1 调用 2的话   发起远程调用 通过 代理对象  把我们要调用的信息通过网络传输给服务端 服务端收到后调用本地的方法 调用完成后 服务端也通过代理 在网络传输回去 ，客户端代理收到结果后进行返回 ，   （（（（像调用本地方法一样调用 。把中间的过程封装起来，rpc框架包括了代理对象 封装数据 网络传输等））））  

dubbo底层通信通过netty（nio）

dubbo原理

1spring解析配置文件中的每个标签都有一个总接口 ：BeanDefinitionParser
		dubboBeanDefinitionParser解析你配置的标签 存储到对应的。。。config里面
		
2	service标签会封装成servicebean 创建完后  
					调用afterPropertiesSet（）     						 ----------都是spring的原理
					：保存标签里配置的provider application module register monitor protocols
			ioc容器启动完成后调用：  onApplicationEvent
					：如果是要暴露的服务 但是还没有暴露 进行服务的暴露
								暴露url地址： 加载注册中心信息	把协议在对应的端口进行暴露  写入到对应的提供者消费者注册表(就是缓存 所以dubbo有缓存的功能)中 暴露服务 创建服务器(创建的就是netty服务器 监听对应的端口)