Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。其核心部分包含：
1)集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
2)远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
3)自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
因为是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。内部使用了 Netty、Zookeeper，保证了高性能高可用性。使用 Dubbo 可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。
SpringC主从中心loud 使用的 Eureka ，Dubbo推荐使用zookeeper
SpringCloud 将一个应用定义为一个服务,Dubbo 将一个接口定义为一个服务，
SpringCloud是一个生态，而Dubbo是SpringCloud生态中关于服务调用一种解决方案(服务治理）
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 协议 redis：基于 redis 实现的 RPC 协议
首先Dubbo在2014 年开始停止维护过几年，17 年开始重新维护，并进入了 Apache 项目。
Dubbox 是继 Dubbo 停止维护后，当当网基于 Dubbo 做的一个扩展项目，如加了服务可 Restful 调用，更新了开源组件等。
管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。
Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议。
Dubbo是一个分布式的服务框架，底层是通过RPC来完成服务和服务之间的调用的。RPC(Remote Procedure Call Protocol)是一种远程调用协议， 允许像调用本地服务那样调用远程其它服务，即实现跨进程交互。Dubbo分为四个模块，分别为：注册中心（Registry）、提供者（Provider）、消费者（Consumer）和监控（Monitor）。
1.注册中心（Registry）：可以是zookeeper、redis、multicast、simple（官方推荐使用Zookeeper）；
2.提供者（Provider）：服务启动时，Provider引用容器中的服务，并向Registry注册服务信息（包括IP地址，服务名，方法定义等），同时暴露服务（Consumer是直接和Provider通讯实现服务调用的）。
3.消费者（Consumer）：服务启动时，Consumer向Registry订阅服务，如果没有订阅到自己想获得的服务，它会不断的尝试订阅。新的服务注册到注册中心以后，注册中心会将这些服务通过notify到消费者。Consumer直接调用Provider提供的服务。
4.监控（Monitor）：Consumer和Provider会通过异步的方式定时向Monitor发送消息，报告服务的状态。Monitor在整个架构中是可选的，Monitor功能需要单独配置，不配置或者配置后挂掉并不会影响服务的调用。
所以，Dubbo的实现思路是通过注册中心实现服务的动态注册与发现，Provider暴露服务，Consumer直接和Provider通讯实现服务间的调用的。
1)Dubbo 提供了声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。
2)Dubbo 2.2.0 以上版本支持服务降级。
3)Dubbo目前暂时不支持，后续可能采用基于 JTA/XA 规范实现。
4)Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。
当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。
Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check="true"，可以通过 check="false" 关闭检查。
可以的，启动 dubbo 时，消费者会从 zookeeper 拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。
去除dubbo超时重试机制，并重新评估设置超时时间。业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理。
当然Dubbo的重试机制其实是非常好的QOS保证，它的路由机制，是会帮你把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。但是请一定要综合线上的访问情况，给出综合的评估。
检查 dubbo 的 jar 包有没有在 classpath 中，以及有没有重复的 jar 包
检查暴露服务的 spring 配置有没有加载
在服务提供者机器上测试与注册中心的网络是否通
可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。
容错指的是某种系统控制在一定范围内的一种允许或包容犯错情况的发生。具体容错策略如下：
1.Failover Cluster失败自动切换：dubbo的默认容错方案，当调用失败时自动切换到其他可用的节点，具体的重试次数和间隔时间可通过引用服务的时候配置，默认重试次数为1也就是只调用一次。
2.Failback Cluster失败重新恢复：在调用失败，记录日志和调用信息，然后返回空结果给consumer，并且通过定时任务每隔5秒对失败的调用进行重试
3.Failfast Cluster快速失败：只会调用一次，失败后立刻抛出异常
4.Failsafe Cluster失败安全：调用出现异常，记录日志不抛出，返回空结果
5.Forking Cluster并行调用多个服务提供者：通过线程池创建多个线程，并发调用多个provider,结果保存到阻塞队列，只要有一个provider成功返回结果，就会立刻返回结果
6.Broadcast Cluster广播模式：逐个调用每个provider,如果其中一台报错，在循环调用结束后，抛出异常
RandomLoadBalance:随机负载均衡。随机的选择一个。是Dubbo的默认负载均衡策略。
RoundRobinLoadBalance:轮询负载均衡。轮询选择一个。
LeastActiveLoadBalance:最少活跃调用数，相同活跃数的随机。活跃数指调用前后计数差。使慢的 Provider 收到更少请求，因为越慢的 Provider 的调用前后计数差会越大。
ConsistentHashLoadBalance:一致性哈希负载均衡。相同参数的请求总是落在同一台机器上。
Dubbo是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。
Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 实现分布式服务追踪
官方微信
官方抖音
