dubbo 的工作原理

1、工作原理

第一层：service层，接口层，给服务提供者和消费者来实现的
第二层：config层，配置层，主要是对dubbo进行各种配置的
第三层：proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton
第四层：registry层，服务注册层，负责服务的注册与发现
第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
第七层：protocol层，远程调用层，封装rpc调用
第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
第九层：transport层，网络传输层，抽象mina和netty为统一接口
第十层：serialize层，数据序列化层

工作流程
1、第一步，provider向注册中心去注册
2、第二步，consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务
3、第三步，consumer调用provider
4、第四步，consumer和provider都异步的通知监控中心
5、第五步，Containor 服务运行容器

2、注册中心挂了可以继续通信？

可以，因为刚开始初始化的时候，consumer会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信

19.01.05更新

3、dubbo 支持哪些通信协议以及序列化协议

1、dubbo协议
单一的长连接¹，NIO异步通信，hessian序列化²协议；
适用的场景：传输数据量很小（每次请求在100kb以内），但是并发量很高
2、rmi 协议
走java二进制序列化，多个短连接，很少用
使用的场景：文件传输
3、http协议
json 序列化
4、hessian协议
多个短连接，适用于提供者数量比消费者数量还多
5、webservice
SOAP文本序列化

4、dubbo支持哪些负载均衡、高可用以及动态代理的策略？

1、使用分配权重在provider上，根据机器的性能来调试权重的大小；
2、均匀分配到每一个provider上
3、基于hash一致性算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量。

容错策略

1、failover cluster模式
provider 宕机重试以后，req会分到其他的provider上。
2、failback
定时重试
3、failfast cluster模式
写操作，失败就失败
4、forking cluster
并行调用多个provider
5、broadcacst cluster
调用所有的provider

了解dubbo的SPI³: 机制？如何基于SPI机制对dubbo进行扩展？

4.2、
默认使用javassist动态字节码生成，创建代理类
但是可以通过spi扩展机制配置自己的动态代理策略

zookeeper和eureka的区别：

zk保证了CP ，一致性和容错分区
eureka 保证了AP，高可用

---

1. 长连接，走的是NIO异步通信，并发量很高，相对于短连接，短连接是一个req对应一个短连接，用完销毁； ↩︎

2. 转化成byte[ ] 数组，hessian序列化速度较慢，跨语言； ↩︎

3. service provider interface ，接口多实现，就是SPI ； ↩︎