Dubbo概述

工作原理：

 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 层，数据序列化层