Dubbo 的三大领域模型

=============

为了对 Dubbo 整体架构叙述的方便，Dubbo 抽象出了三大领域模型。

  • Protocol 服务域 ：是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。
  • Invoker 实体域 ：是 Dubbo 的核心模型，其它模型都向它靠拢，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
  • Invocation 会话域 ：它持有调用过程中的变量，比如方法名，参数等。

Dubbo 的四大组件


  • Provider ：服务提供者。
  • Consumer ：服务消费者。
  • Registry ：服务注册与发现的中心，提供目录服务。
  • Monitor ：服务监控，统计服务的调用次数、调用时间等信息的日志服务，并可以对服务设置权限、降级处理等，称为服务管控中心。

Dubbo 的十层架构

===========

dubbo ScopeModel是怎么注入的 dubbo invoker详解_提供方

Dubbo 的架构设计划分为了 10 层。图中左边淡蓝色背景为服务 Consumer 使用的接口，右边淡绿色背景为服务 Provider 使用的接口，位于中轴线的为双方都要用到的接口。对于这10 层，根据其总体功能划分，可以划分为三大层：

Business 层

==========

该层仅包含一个 service 服务层 ，该层与实际业务逻辑有关，根据服务消费方和服务提供方的业务设计，实现对应的接口。

RPC 层

=====

该层主要负责整个分布式系统中各个主机间的通讯。该层包含了以下 6 层。

  • config 配置层 ：一 ServiceConfig 和 ReferenceConfig 为中心，用于加载并解析 Spring 配置文件中的 Dubbo标签。
  • proxy 服务代理层 ：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton以 ServiceProxy 为中心，扩展接口为 ProxyFactory。Proxy 层封装了所有接口的透明化代理，而在其它层都以 Invoker 为中心只有到了暴露给用户使用时，才用 Proxy 将 Invoker 转成接口，或将接口实现转成 Invoker，也就是去掉 Proxy 层 RPC 是可以运行的只是不那么透明，不那么看起来像调本地服务一样调远程服务。
  • registry 注册中心层 ：封装服务地址的注册和发现，以服务 URL 为中心，扩展接口为 RegistryFactory、Registry、RegistryService，可能没有服务注册中心，此时服务提供方直接暴露服务。
  • cluster 路由层 ：封装多个提供者的路由和负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为Cluster、Directory、Router 和 LoadBalance，将多个服务提供方组合为一个服务提供方，实现对服务消费通明。只需要与一个服务提供方进行交互。Dubbo 官方指出，在 Dubbo 的整体架构中，Cluster 只是一个外围概念。Cluster 的目的是将多个 Invoker 伪装成一个 Invoker，这样用户只需关注 Protocol 层 Invoker 即可，加上Cluster 或者去掉 Cluster 对其它层都不会造成影响，因为只有一个提供者时，是不需要Cluster 的。