什么是Dubbo？
Dubbo 是阿里开源的远程服务调用(RPC)的分布式框架，提供了 SOA 服务治理方案;它的架构主要有五个角色/核心组件，分为是 Container(容器)、Provider(服务的提供方)、Registry(注册中心)、Consumer(服务的消费方)、Monitor(监控中心)。
容器主要负责启动、加载、运行服务提供者;
同时服务提供者在启动时，向注册中心注册自己提供的服务;
消费者向注册中心订阅自己的服务;注册中心返回服务提供者列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者;
对于服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另外一台调用;
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心;
Dubbo 在项目中主要用来实现不同系统之间的服务调用，由于项目是按照不同的功能分了不同的系统，按照三层架构又分了不同的服务，其中三层架构中的控制层作为服务的消费方，业务层和持久层共同作为服务的发布方，这样的架构实现了系统的服务化，提高了开发效率，实现了业务的解耦。
项目中通过 Dubbo 和 Spring 的整合，采用全 Spring 配置方式，只需要用 Spring 来加载Dubbo 的配置，完成了服务的发布和调用。
我们主要在服务的暴露方通过dubbo:service标签来暴露服务，在服务的消费方通过dubbo:reference标签来引用服务，注册中心我们选用的是 zookeeper，对服务的URL进行了管理和配置。
Dubbo 支持 Dubbo 协议、RMI 协议、hessian 协议、Http 协议等。
Dubbo 协议：缺省协议、采用了单一长连接和 NIO 异步通讯、使用线程池并发处理请求，能减少握手和加大并发效率、采用的是 Hession 二进制序列化、性能较好，推荐使用。
主要应用于传入传出参数数据包较小(建议小于 100K)，消费者比提供者个数多，由于是单一连接，因为尽量不要传输大文件。
RMI 协议：采用 JDK 标准的 RMI 协议(基于 TCP 协议)、堵塞式短连接、JDK 标准序列化方式、同步通讯。
适用于消费者和提供者个数差不多的，可传文件。测试发现偶尔会连接失败，需要重建 Stub。
Hessian 协议：采用 http 通讯，采用 Servlet 暴露服务，多连接短连接的同步传输方式，采用hession 的二进制序列化，适合提供者比消费者多。
Dubbo入门详细教程
Dubbo快速入门，Java分布式框架必会的dubbo教程
关于Dubbo面试题
【面试题1】Dubbo支持的协议、
dubbo(默认)：单一长连接和NIO异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。传输协议 TCP，异步，Hessian 序列化;
rmi：采用JDK标准的rmi协议实现，传输参数和返回参数对象需要实现Serializable接口，使用java标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和提供者个数差不多，可传文件，传输协议 TCP。多个短连接，TCP 协议传输，同步传输，适用常规的远程服务调用和 rmi 互操作。在依赖低版本的 Common-Collections包，java 序列化存在安全漏洞;
webservice：基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生 WebService 的互操作。多个短连接，基于 HTTP 传输，同步传输，适用系统集成和跨语言调用;
http：基于 Http 表单提交的远程调用协议，使用Spring的HttpInvoke 实现。多个短连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器 JS 调用;
hessian：集成Hessian 服务，基于HTTP通讯，采用Servlet暴露服务，Dubbo 内嵌 Jetty 作为服务器时默认实现，提供与Hession服务互操作。多个短连接，同步 HTTP 传输，Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件;
memcache： 基于memcached实现的RPC协议
传入传出参数数据包较小(建议小于100K)，消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
redis： 基于redis实现的RPC协议
【面试题2】Dubbo推荐用什么协议?使用该协议有哪些优缺点?
传入传出参数数据包较小(建议小于100K)，消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
【面试题3】Dubbo超时时间的设置
通过timeout属性配置超时时间,服务的提供者和消费者都可以配置，尽量在服务提供者中配置，因为服务的提供者会对自己提供的服务情况更清楚超时时间不要设置太大(1~5S),会影响并发性能问题。
【面试题4】Dubbo自动重试机
Dubbo在调用服务不成功时，默认会重试2次。Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机制也能一定程度的保证服务的质量
【面试题5】Dubbo支持的注册中心
Multicast 注册中心
Multicast 注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现
Zookeeper 注册中心
基于分布式协调系统 Zookeeper 实现，采用Zookeeper 的 watch 机制实现数据变更
redis 注册中心
基于redis实现，采用key/Map存储，住key存储服务名和类型，Map中key存储服务URL，value 服务过期时间。基于redis 的发布/订阅模式通知数据变更;
【面试题6】Dubbo集群的负载均衡策略
随机
按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。(权重可以在dubbo管控台配置)
轮循
按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
最少活跃调用数
相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
一致性Hash
相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
【面试题7】Dubbo支持哪些序列化方式?
dubbo序列化：阿里尚未开发成熟的高效java序列化实现，阿里不建议在生产环境使用它
hessian2序列化(默认推荐)：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的hessian lite，它是dubbo RPC默认启用的序列化方式
json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。
java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。
【面试题8】注册中心宕机，服务间是否可以继续通信
可以通信的，启动dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用;
但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的。
另外如果服务的提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复;
【面试题9】Dubbo与spring的关系
Dubbo采用全Spring 配置方式，透明化接入应用，对应用没有任何API 侵入，只需用Spring加载Dubbo的配置即可。
【面试题10】Dubbo使用的是什么通信框架?
NIO Netty框架
【面试题11】Dubbo的集群容错方案
Failover Cluster(默认):
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=“2” 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。
【面试题12】Dubbo 和 Spring Cloud 的关系?
Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo定位服务治理、Spirng Cloud 是一个生态。最大的区别：Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。
