dubbo架构构成

dubbo运行架构如下图示：

• 节点角色说明：

1、Provider:暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。
2、Registry:服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。
3、Container: 服务运行容器。
 
 
1
2
3

• 调用关系说明： 
  1、服务容器负责启动，加载，运行服务提供者。 
  2、服务提供者在启动时，向注册中心注册自己提供的服务。 
  3、服务消费者在启动时，向注册中心订阅自己所需的服务。 
  4、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 
  5、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 
• 6、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

• 1.3 dubbo的特性

  (1) 连通性：

  注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表 
  注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

  (2) 健状性：

  监控中心宕掉不影响使用，只是丢失部分采样数据数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务注册中心对等集群，任意一台宕掉后，将自动切换到另一台注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯服务提供者无状态，任意一台宕掉后，不影响使用服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

  (3) 伸缩性：

  注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心 
  服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

  (4) 升级性：

  当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力：

  

  1.4 dubbo的调用方式

  • 异步调用

  基于NIO的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小。

  

  • 本地调用

  本地调用，使用了Injvm协议，是一个伪协议，它不开启端口，不发起远程调用，只在JVM内直接关联，但执行Dubbo的Filter链。

  Define injvm protocol:

  <dubbo:protocol name="injvm" />
     
     
  1

  Set default protocol:

  <dubbo:provider protocol="injvm" />
     
     
  1

  Set service protocol:

  <dubbo:service protocol="injvm" />
     
     
  1

  Use injvm first:

  <dubbo:consumer injvm="true" .../>
  <dubbo:provider injvm="true" .../>
  或
  
  <dubbo:reference injvm="true" .../>
  <dubbo:service injvm="true" .../>
     
     
  1
  2
  3
  4
  5
  6

  注意：服务暴露与服务引用都需要声明injvm=“true”

  1.5 dubbo支持的注册中心

  Dubbo提供的注册中心有如下几种类型可供选择：

  • Multicast注册中心
  • Zookeeper注册中心
  • Redis注册中心
  • Simple注册中心

  ZooKeeper是一个开源的分布式服务框架，它是Apache Hadoop项目的一个子项目，主要用来解决分布式应用场景中存在的一些问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置管理等，它支持Standalone模式和分布式模式，在分布式模式下，能够为分布式应用提供高性能和可靠地协调服务，而且使用ZooKeeper可以大大简化分布式协调服务的实现，为开发分布式应用极大地降低了成本。

  ZooKeeper总体架构

  

  ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。

  1.6 dubbo支持的远程通信协议

  远程通信需要指定通信双方所约定的协议，在保证通信双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通信框架，主要包括如下几个：

  • Mina
  • Netty
  • Grizzly

  

  1.7 dubbo支持的远程调用协议

  Dubbo支持多种协议，如下所示：

  • Dubbo协议
  • Hessian协议
  • HTTP协议
  • RMI协议
  • WebService协议
  • Thrift协议
  • Memcached协议
  • Redis协议

  

  在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。