dubbo-2

---

Dubbo对于服务提供方和服务消费方，
从框架的10层中分别提供了各自需要关心和扩展的接口，
构建整个服务生态系统(服务提供方和服务消费方本身就是一个以服务为中心的)。
根据官方提供的，
对于上述各层之间关系的描述，如下所示：

在RPC中，Protocol是核心层，
也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，
然后在Invoker的主过程上Filter拦截点。

图中的Consumer和Provider是抽象概念，
只是想让看图者更直观的了解哪些类分属于客户端与服务器端，
不用Client和Server的原因是
Dubbo在很多场景下都使用Provider、Consumer、Registry、Monitor划分逻辑拓扑节点，保持统一概念。

而Cluster是外围概念，
所以Cluster的目的是将多个Invoker伪装成一个Invoker，
这样其它人只要关注Protocol层Invoker即可，
加上Cluster或者去掉Cluster对其它层都不会造成影响，
因为只有一个提供者时，是不需要Cluster的。

Proxy层封装了所有接口的透明化代理，
而在其它层都以Invoker为中心，
只有到了暴露给用户使用时，
才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，
只是不那么透明，
不那么看起来像调本地服务一样调远程服务。

而Remoting实现是Dubbo协议的实现，
如果你选择RMI协议，
整个Remoting都不会用上，
Remoting内部再划为Transport传输层和Exchange信息交换层，
Transport层只负责单向消息传输，
是对Mina、Netty、Grizzly的抽象，
它也可以扩展UDP传输，
而Exchange层是在传输层之上封装了Request-Response语义。

Registry和Monitor实际上不算一层，而是一个独立的节点，
只是为了全局概览，用层的方式画在一起。

从上面的架构图中，我们可以了解到，
Dubbo作为一个分布式服务框架，
主要具有如下几个核心的要点：

☆ 服务定义

服务是围绕服务提供方和服务消费方的，
服务提供方实现服务，
而服务消费方调用服务。

☆ 服务注册

对于服务提供方，它需要发布服务，
而且由于应用系统的复杂性，
服务的数量、类型也不断膨胀；

对于服务消费方，它最关心如何获取到它所需要的服务，
而面对复杂的应用系统，需要管理大量的服务调用。

而且，对于服务提供方和服务消费方来说，
他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。

通过将服务统一管理起来，
可以有效地优化内部应用对服务发布/使用的流程和管理。
服务注册中心可以通过特定协议来完成服务对外的统一。
Dubbo提供的注册中心有如下几种类型可供选择：

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

☆ 服务监控

无论是服务提供方，还是服务消费方，
他们都需要对服务调用的实际状态进行有效的监控，
从而改进服务质量。

☆ 远程通信与信息交换

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

• Mina
• Netty
• Grizzly

☆ 服务调用

下面从Dubbo官网直接拿来，
看一下基于RPC层，
服务提供方和服务消费方之间的调用关系，如图所示：

上图中，蓝色的表示与业务有交互，
绿色的表示只对Dubbo内部交互。
上述图所描述的调用流程如下：

• 服务提供方发布服务到服务注册中心；
• 服务消费方从服务注册中心订阅服务；
• 服务消费方调用已经注册的可用服务

接着，将上面抽象的调用流程图展开，详细如图所示：
dubbo-extension

☆ 注册/注销服务

服务的注册与注销，是对服务提供方角色而言，那么注册服务与注销服务的时序图，如图所示：

☆ 服务订阅/取消

为了满足应用系统的需求，
服务消费方的可能需要从服务注册中心订阅指定的
有服务提供方发布的服务，
在得到通知可以使用服务时，就可以直接调用服务。
反过来，如果不需要某一个服务了，可以取消该服务。
下面看一下对应的时序图，如图所示：

!dubbo-refer

☆ 协议支持

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

1. Dubbo协议
2. Hessian协议
3. HTTP协议
4. RMI协议
5. WebService协议
6. Thrift协议
7. Memcached协议
8. Redis协议

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