dubbo

1、原理

从这张图中可以看到dubbo的整个从服务的发布到订阅消费的过程大致分为5个步骤。

• start

container启动，这里的容器一般情况下直接是整合spring。再通过web容器来加载spring容器来启动服务。

• register

将服务通过dubbo的url发布到注册中心的过程称之为register。

• subscribe

订阅的过程其实也是对于消费者来说也是透明的，类似于spring的整个注入过程。通过在整合spring后的注册中心地址来订阅服务，有一个非常好的地方就是dubbo在订阅的过程中，对于服务端的依赖是没有的。就是说，在整个订阅过程中，无论服务的启动与否对于消费者来说都是没有关系的。整个过程，从服务到消费是没有耦合的。

• notify

这个过程对于注册中心来说，是不断的进行通信的。注册中心有自己一套的健康管理计划，不间断的heartbeat来向消费者通知自己的服务注册消息。

• invoke

其实对于dubbo的注册中心来说，相当于一个红娘的角色。在消费者和提供者之间提供服务的地址，最后来执行调用和被调用的其实还是服务的消费者和服务提供者。消费者通过注册中心的地址能够找到服务端的服务地址，这样就可以直接调用服务的本身以此来直接调用服务。

• monitor

monitor来说，其实一个在线婚介所。由来支配各地的需求，这里的服务并发比较集中，那么相对来说就需要提供更多的服务节点来去更好的分发来自消费者的请求。并且能够根据ip来分配被调用者的权重等相关的配置信息。

特点

Dubbo缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。

• 连接个数：单连接 连接方式：长连接 传输协议：TCP 传输方式：NIO异步传输 序列化：Hessian二进制序列化

  适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。

  适用场景：常规远程服务方法调用

dubbo在使用过程中的局限性

比如： 由于这种长连接的方式，那么就需要结合需求来尽量的在局域网使用dubbo的这种的通信方式。 

另外基于这种组件的模式开发，组件的之间强依赖强耦合减少，不仅仅是组件之间在消费者和提供者之间也对应没有了耦合。Dubbo缺省协议采用单一长连接和NIO异步通讯，使用于这种短消息但并发量较高的场景。