什么是 dubbo
Dubbo 是工作在 soa 面向服务分布式框架中的服务管理中间件。Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。
它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo 采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容。
Dubbo 使用的是缺省协议， 采用长连接和 nio 异步通信， 适合小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
反之， dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
节点角色说明
- Provider: 暴露服务的服务提供方。
- Consumer: 调用远程服务的服务消费方。
- Registry: 服务注册与发现的注册中心。
- Monitor: 统计服务的调用次调和调用时间的监控中心。
- Container: 服务运行容器。
调用关系说明
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
在实际开发的场景中应该如何选择 RPC 框架
- SpringCloud ： Spring 全家桶，用起来很舒服，只有你想不到，没有它做不到。可惜因为发布的比较晚，国内还没出现比较成功的案例，大部分都是试水，不过毕竟有 Spring作背景，还是比较看好。
- Dubbox：相对于 Dubbo 支持了 REST，估计是很多公司选择 Dubbox 的一个重要原因之一，但如果使用 Dubbo 的 RPC 调用方式，服务间仍然会存在 API 强依赖，各有利弊，懂的取舍吧。
- Thrift： 如果你比较高冷，完全可以基于 Thrift 自己搞一套抽象的自定义框架吧。
- Hessian：如果是初创公司或系统数量还没有超过 5 个，推荐选择这个，毕竟在开发速度.运维成本.上手难度等都是比较轻量.简单的，即使在以后迁移至 SOA，也是无缝迁移。
- rpcx/gRPC：在服务没有出现严重性能的问题下，或技术栈没有变更的情况下，可能一直不会引入，即使引入也只是小部分模块优化使用。