介绍
Dubbo 是一个分布式服务框架，致力于提高性能和透明化的 RPC 远程过程调用的方案，以及 SOA 服务治理方案。
其核心部分包括了：
- 远程通讯：提供对多种基于长连接的 NIO 框架的抽象封装，包括多种线程模型，序列化，以及「请求-响应」模式的信息交换模式等。
- 集群容错：提供基于接口方法的透明远程过程调用，包括了多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
- 自动发现：基于注册中心目录服务，使服务消费者能够动态地查找服务提供方，使地址透明，使服务提供方可以平滑增加或者减少机器。
- 服务自动注册与发现：不再需要写死服务提供方的地址，注册中心基于接口名来查询服务提供者的 IP 地址，并且能够平滑地添加或者删除服务提供者。
架构
Dubbo 架构
节点角色的说明：
- Provider：暴露服务的服务提供方
- Consumer：调用远程服务的服务消费方
- Registry：服务注册与发现的注册中心
- Monitor：统计服务的调用次数和调用时间的监控中心
- Container：服务运行的容器
调用关系说明：
- 服务容器负责启动，加载，运行服务提供者
- 服务提供者在启动时，向注册中心注册自己提供的服务
- 服务消费者在启动时，向注册中心订阅自己所需要的服务
- 注册中心会返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
- 服务消费者会从提供者地址列表中，基于软负载均衡的算法，选一台提供者进行调用，入股哦调用失败，再选择另一台进行调用
- 服务消费者和提供者，都会在内存中累计调用次数和调用时间，定时每分钟发送一个统计次数的数据到监控中心
注册中心
Dubbo 提供的注册中心有以下几种类型可以选择：
- Multicast 注册中心
- ZooKeeper 注册中心：ZooKeeper 集群由一组 Server 节点组成，这一组 Server 节点中存在一个角色作为 Leader 的节点，其它节点则为 Follower。当客户端 Client 连接到 ZooKeeper 集群后，执行写请求时，这些请求会被发送到 Leader 节点上，然后 Leader 节点上的数据变更会同步到集群中其它的 Follower 节点。
- Redis 注册中心
- Simple 注册中心
网络协议
远程通信需要指定通信双方所约定的协议，在保证通信双方理解协议语义的基础上，保证高效、稳定的消息传输。Dubbo 继承了目前主流的网络通信框架：
- Mina
- Netty
- Grizzly
远程调用协议
Dubbo 支持的远程调用协议：
- Dubbo 协议
- HTTP 协议
- RMI 协议
- Web Service 协议
- Thrift 协议
- Redis 协议
在通信过程中，不同的服务等级一般对应着不同的服务质量，所以要根据应用的创建场景来选择协议。
特性
连通性
注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动的时候与注册中心交互，所以注册中心不会转发请求，压力较小。
监控中心负责统计各个服务的调用次数、调用时间等，统计先在内存汇总后每分钟一个发送到监控中心的服务器里。
服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间内是不包括网络开销的。
服务消费者向注册中心获取服务提供者的地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间是包含网络开销的。
注册中心、服务提供者、服务消费者三者之间都是长连接，监控中心除外。
注册中心通过长连接感知服务提供者的存在，如果服务提供者宕机了，注册中心会立即推送事件通知消费者；如果注册中心和监控中心都宕机了，不会影响已有的提供者和消费者，消费者在本地缓存了提供者的列表；注册中心和监控中心全部都宕机了，服务消费者可以直接连接服务提供者。
健壮性
- 监控中心宕机了，不影响使用，只是会缺少部分采样数据；
- 数据库宕机了，注册中心仍能够缓存提供服务列表进行查询，但是不能注册新的服务
- 注册中心对等的集群中的任意一台宕机了，将自动切换到另外一台
- 注册中心全部宕机了，服务提供者和服务消费者仍然能够通过本地缓存进行通讯
- 如果服务提供者无状态了，任意一台宕机了，也不影响使用
- 如果服务提供者全部宕机了，服务消费者应用将无法使用，并且无限次重连等待服务提供者恢复
伸缩性
注册中心对等集群，可以动态增加机器部署实例，所有客户端将自动发现新的注册中心；如果服务提供者无状态了，也可以动态增加机器部署实例，并且注册中心将推送新的服务提供者信息给消费者
升级性
当服务集群规模进一步扩大，带动 IT 结构进一步升级，需要实现动态部署，进行流动计算，现有的分布式服务架构不会带来阻力。