浅谈Dubbo

一、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. 服务消费者和提供者，再内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心