分布式服务框架原理（一）Dubbo设计

>>分布式服务框架设计

分布式服务框架一般可以分为以下几个部分，

（1）RPC基础层：

包括底层通信框架，如NIO框架、通信协议，序列化和反序列化协议，以及在这几部分上的封装，屏蔽底层通信细节和序列化方式差异

（2）服务发布/消费：

服务提供者根据消费者请求消息中的接口名，方法名，参数列表等信息，通过Java反射，调用本地的接口实现类；服务消费者将服务提供者发布的接口封装成远程服务调用；

（3）服务调用链：

在服务调用的职责链中，通过在调用链切面的编码完成相关的监控和扩展，如负载均衡，服务调用性能统计，调用完成通知，失败重发等功能

（4）服务注册中心：

注册中心负责服务的发布和通知，需要支持服务的平滑上线下线等

（5）服务治理中心：

服务治理中心是一个可视化的模块，提供对服务的可视化分析和维护，包括服务运行状态，调用关系和健康度等

 

>>Dubbo的设计角色

（1）系统角色

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

（2）调用关系

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

 

>>Dubbo是如何架构的

Dubbo的总体架构如图所示：

 

框架分层架构中，各个层次的设计要点：

服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。

>>Dubbo的底层实现

（1）协议支持

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

（2）默认使用Dubbo协议

连接个数：单连接

（3）Dubbo源码模块图

Dubbo以包结构来组织各个模块，各个模块及其关系，如图所示：

可以通过Dubbo的代码（使用Maven管理）组织，与上面的模块进行比较。简单说明各个包的情况：

>>服务暴露和消费的详细过程

（1）服务提供者暴露一个服务的详细过程

服务提供者暴露服务的主过程：

首先ServiceConfig类拿到对外提供服务的实际类ref(如：HelloWorldImpl),然后通过ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例，

到这一步就完成具体服务到Invoker的转化。接下来就是Invoker转换到Exporter的过程。

Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程(如上图中的红色部分)，下面我们以Dubbo和RMI这两种典型协议的实现来进行说明：

Dubbo的实现

Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法，它主要是打开socket侦听服务，并接收客户端发来的各种请求，通讯细节由Dubbo自己实现。

RMI的实现

RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法，它通过Spring或Dubbo或JDK来实现RMI服务，通讯细节这一块由JDK底层来实现，这就省了不少工作量。

（2）服务消费者消费一个服务的详细过程

服务消费的主过程：

首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例(如上图中的红色部分)，这是服务消费的关键。

接下来把Invoker转换为客户端需要的接口(如：HelloWorld)。

 

整理自 

Dubbo官方文档

Dubbo架构设计详解

阿里架构之旅（二）——Dubbo解析

出处：http://www.cnblogs.com/binyue/p/5312193.html