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