一、Dubbo是什么？
1） 本质：一个jar包，一个分布式框架，一个远程服务调用的分布式框架
垂直的MVC系统 拆分成分布式系统
垂直的都是在一个服务器上，调用方法直接就自然而然的调用了，没有什么问题
当需求变多的时候，就会拆分多个，部署在不同的服务器上，这相对于以前都在一个服务器上，现在分布式后，web层调用Service层的服务就变成了远程调用（因为web层和service层都部署在不同的服务器上），如何像以前一样在一个服务器上自然而然的调用方法，dubbo来解决。
二、Dubbo的好处？
- 透明化的远程调用，就像本地方法一样调用远程方法，只需要简单的配置，没有任何的API入侵
- 软负载均衡及容错机制，可在内网代替F5等硬件负载均衡，降低成本，减少单点
- 服务注册与发现，不在需要写死服务器提供方地址，注册中心基于接口名查询服务提供者的ip地址，并能够平滑添加或删除服务提供者。
三、Dubbo架构图
节点角色说明：
- Provider(生产者)：暴露服务的服务提供方
- Consumer(消费者)：调用远程服务的服务消费方
若按照上面，消费者调用生产者的服务就变成如下图所示
这样的调用非常繁琐，比较凌乱，万一分布式需要更多，就凉了。所以我们需要它
Registry(注册中心)： 服务注册与发现的注册中心，dubbo推荐的是使用zookeeper,什么是zookeeper？zookeeper是用于分布式中一致性处理的框架。
zookeeper是dubbbo的注册中心，相当于一个中间者。服务消费者层中间件上闹到可用的服务器生产者的集群地址，再从集群地址中选出一个进行直连。所以如果注册中心集群都挂了，发布者和订阅者之间就不能通信了。
于是关系就变为
这样服务就好很多，但是这样还是不够的，我们还需要一个监控中心（监控调用调用是否失败，是否挂了），
Monitor -------- 统计服务的调用次和调用时间的监控中心。然后，Provider（生产者）放在容器中运行，就叫做Container服务器容器。
所以dubbo想关角色
- Provider(生产者)：暴露服务的服务提供方
- Consumer(消费者)：调用远程服务的服务消费方
- Registry(注册中心)
- Monitor(统计服务的调用次数、调用时间的监控中心)
- Container:服务运行容器
四、最终dubbo服务架构
按照流程图解析
0. 服务容器负责启动、加载、运行服务提供者
1. 服务提供者（生产者）在启动时，向注册中心注册自己提供的服务
2. 服务消费者在启动时，向注册中心订阅自己所需要的服务
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者
4. 服务消费者，从提供者列表中，基于软负载均衡算法，元一台提供者进行调用，如果调用失败，再选另一台调用
5. 服务消费者和提供者，再内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心