Dubbo服务框架解析（一）

公司的一个项目的分布式系统的服务管理，使用了阿里的服务框架Dubbo，因此这里准备对服务框架进行了介绍。

Dubbo服务框架可以使得java分布式系统之间进行解耦，使用一个服务注册中心来统一管理服务的信息，服务提供者提供注册中心进行注册，而服务消费者可以透明地订阅和消费服务。并支持服务的路由、过滤、负载均衡等，支持多种通讯协议及NIO框架，是一个灵活性和扩展性非常棒的服务管理框架。

本文以github中当前版本2.5.4的源码来分析。

为了支持更灵活的扩展性，当前dubbo拆分了非常多的project，下面以官网的总体模块图来说明各个模块的作用。

模块说明：

• dubbo-common 公共逻辑模块，包括Util类和通用模型。
• dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
• dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
• dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡, 容错，路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
• dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。
• dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。
• dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。
• dubbo-container 容器模块，是一个Standlone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。

整体上按照分层结构进行分包，与分层的不同点在于：

• container为服务容器，用于部署运行服务，没有在层中画出。
• protocol层和proxy层都放在rpc模块中，这两层是rpc的核心，在不需要集群时(只有一个提供者)，可以只使用这两层完成rpc调用。
• transport层和exchange层都放在remoting模块中，为rpc调用的通讯基础。
• serialize层放在common模块中，以便更大程度复用。

下面是更详细的Project关系图，依赖关系线有点乱。整个模块是从上到下传递依赖的。

从图中可以看到，每个模块都实现了多种扩展机制，供使用者选择，比如服务注册库registry实现了zookeeper、multicast、redis等多种机制，而我们选择了zookeeper来保存服务注册信息，这真是很贴心的开源框架啊！