工作原理：
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 就可以了。
