分布式服务框架DUBBO（一）dubbo 简介

好久都没有更新自己的blog了，加班多了，事情多了。每天回到自己蜗居的小房子都已经深夜10点多，加上自己最近身体确实不太好，总之，借口多了很多。开头废话不能太多，还是直入正题。

简介

在dubbo的官方网站上，是这样来介绍的。DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。从这样一段介绍中，有这样几个值得我们关注的点，分布式服务框架以及提供SOA的服务化治理。

原理

从这张图中可以看到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协议传输大文件或超大字符串。

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

对于一个小成本的互联网公司，或者是一个正在从传统行业转型的一个公司来说，使得分布式变得不那么遥不可及。门槛相对来说不那么高，能够算是一种分布式的一种解决方案，但是成本来说也没有那么高。由于底层使用的还是netty的NIO框架，其实dubbo这种基于长连接的方式，注定dubbo在使用过程中，有一定的局限性。比如： 由于这种长连接的方式，那么就需要结合需求来尽量的在局域网使用dubbo的这种的通信方式。
另外基于这种组件的模式开发，组件的之间强依赖强耦合减少，不仅仅是组件之间在消费者和提供者之间也对应没有了耦合。Dubbo缺省协议采用单一长连接和NIO异步通讯，使用于这种短消息但并发量较高的场景。

注：dubbo官网地址：http://dubbo.io/Home-zh.htm