工作原理:
Dubbo的角色主要有服务消费者、服务提供者、注册中心、监控中心。
服务注册:服务提供者启动后,其dubbo框架内部的应用容器会通过20881端口将指定的服务注册
到ZK注册中心上,并与注册中心保持心跳。
服务订阅:然后服务消费者启动后会订阅ZK上对应的服务接口,并将服务配置缓存到本地,后期
如果接口信息有更新,ZK会通知服务消费者去更新服务配置。
服务调用:调用服务时,服务消费者代理读取本地的服务配置,然后通过负载均衡算法选出一个特
定的地址,然后通过dubbo通讯协议访问特定地址的服务提供者、用hession序列化协议把参数序
列化的字节数组发送过去,服务提供者代理接收到服务调用,用hession把参数反序列化,然后找
到对应的接口,本地调用接口,然后真正的接口实现代码执行,返回结果,代理将结果hession序
列化后,通过dubbo协议发送给服务消费者。
核心配置:
1、配置优先级别:
1.method > interface > provider/consumer
2. 级别一样的情况下,consumer > provider
2、多版本支持:version,设置在在service、reference中
3、主机绑定:protocal中,host不设的情况下
4、容错机制:cluster,设置在reference中
failover、failback、failfast、broadcast、failsafe、forking
5、服务降级:mock, 设置在reference中,超时的情况下调用mock(本地的一个实现)
主要特点:
1、多协议支持:
dubbo://(20880)
http://(80)
rmi://(1099)
webservice://(80)
hessian://(80)
2、多注册中心支持:
zookeeper:推荐,适用于线上环境使用
redis:
multicast:
simple:
Dubbo的核心原理:
Dubbo主要解决了什么问题?
当系统拆分之后,如果不使用dubbo会发生什么问题:
直接基于 spring mvc,就纯 http 接口互相通信呗,还能咋样。但是这个肯定是有问题的,因为 http 接口通信维护起来成本很高,你要考虑超时重试、负载均衡等等各种乱七八糟的问题。需要大量手动的去维护服务注册信息,而且还无法感知服务下线。
所以 dubbo 说白了,是一种 rpc 框架,就是说本地就是进行接口调用,但是 dubbo 会代理这个调用请求,跟远程机器网络通信,给你处理掉负载均衡、服务实例上下线自动感知、超时重试等等乱七八糟的问题。那你就不用自己做了,用 dubbo 就可以了。
Dubbo 工作原理
- 第一层:service 层,接口层,给服务提供者和消费者来实现的
- 第二层:config 层,配置层,主要是对 dubbo 进行各种配置的
- 第三层:proxy 层,服务代理层,无论是 consumer 还是 provider,dubbo 都会给你生成代理,代理之间进行网络通信
- 第四层:registry 层,服务注册层,负责服务的注册与发现
- 第五层:cluster 层,集群层,封装多个服务提供者的路由以及负载均衡,将多个实例组合成一个服务
- 第六层:monitor 层,监控层,对 rpc 接口的调用次数和调用时间进行监控
- 第七层:protocal 层,远程调用层,封装 rpc 调用
- 第八层:exchange 层,信息交换层,封装请求响应模式,同步转异步
- 第九层:transport 层,网络传输层,抽象 mina 和 netty 为统一接口
- 第十层:serialize 层,数据序列化层