dubbo进阶--基本概念

   随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行。Dubbo就是其中一种分布式服务架构，在使用Dubbo之前，我们有必要了解一下Dubbo的基本概念。

   Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合。它致力于提供高性能和透明化的RPC远程调用方案，以及SOA服务治理方案，因此得到众多企业的青睐。

   总体架构：

     

   从上图可以看出，Dubbo框架设计分了10层，其最上面的Service层是开发者实现业务逻辑的接口层。下面根据Dubbo文档来介绍一下各个层的设计要点：

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

     2、配置层（Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心，可以直接new 配置类，也可以通过 spring 解析配置生成配置类。

     3、服务代理层（Proxy）：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton，以ServiceProxy 为中心，扩展接口为 ProxyFactory。

     4、服务注册层（Registry）：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为RegistryFactory、Registry 和 RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。

     5、集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster、Directory、Router 和 LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。

     6、监控层（Monitor）：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为
MonitorFactory、Monitor 和 MonitorService。

     7、远程调用层 （Protocol） ： 封将 RPC 调用， 以 Invocation 和 Result 为中心， 扩展接口为 Protocol、Invoker 和 Exporter。Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker的生命周期管理。Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。

     8、信息交换层（Exchange）：封装请求响应模式，同步转异步，以 Request 和 Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer。

     9、网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为Channel、Transporter、Client、Server 和 Codec。

     10、数据序列化层（Serialize）：可复用的一些工具，扩展接口为 Serialization、 ObjectInput、
ObjectOutput 和 ThreadPool。

      

     各层之间的关系如下：

       在 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的核心就是服务的调用，架构如下：

     

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

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

    刚开始接触Dubbo时，看到这些内容难免会感觉头大，虽然内容很多，有种高大上的赶脚。但是，从这些内容上来看，其核心还是提供分布式的服务，只要牢牢的抓住这个核心，再对比之前学习的分布式架构，相信用不了多久就能完全掌握该框架。