Dubbo是什么
Dubbo是一个分布式、高性能、透明化的 RPC 服务框架，作用是提供服务自动注册、自动发现等高效服务治理方案。
各节点角色说明
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
Dubbo服务调用关系说明
0.服务容器负责启动，加载，运行服务提供者。
1.服务提供者在启动时，向注册中心注册自己提供的服务。
2.服务消费者在启动时，向注册中心订阅自己所需的服务。
3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心
Dubbo支持的通信协议
默认Dubbo协议: 采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）,适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
其他也支持Hessian协议,HTTP协议,RMI协议,WebService协议,Thrift协议,Memcached协议,Redis协议等.
Dubbo支持的注册中心
Multicast注册中心
Multicast注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现；
Zookeeper注册中心
基于分布式协调系统Zookeeper实现，采用Zookeeper的watch机制实现数据变更；
redis注册中心
基于redis实现，采用key/Map存储，住key存储服务名和类型，Map中key存储服务URL，value服务过期时间。基于redis的发布/订阅模式通知数据变更；
Simple注册中心:
只是简单实现，不支持集群，可作为自定义注册中心的参考，但不适合直接用于生产环境
Dubbo内核SPI(Service Provider Interface)简介
SPI本质将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。
Dubbo负载均衡策略
dubbo和spring cloud的区别
最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。
而SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。
