Dubbo is Alibaba's open source distributed service framework. Its biggest feature is that it is structured in a layered manner, which can decouple (or maximize loose coupling) between layers. From the perspective of service model, Dubbo adopts a very simple model, either the provider provides the service, or the consumer consumes the service, so based on this, the service provider (Provider) and the service consumer can be abstracted (Consumer) Two roles. For details about the registry, protocol support, service monitoring, etc., please refer to the following description.
Overall architecture
The overall architecture of Dubbo is shown in the figure: The 
Dubbo framework design is divided into 10 layers, and the top Service layer is the interface layer for developers who actually want to use Dubbo to develop distributed services to implement business logic. The light blue background on the left in the figure is the interface used by the service consumer, the light green background on the right is the interface used by the service provider, and the interface located on the central axis is the interface used by both parties.
Below, combined with Dubbo's official documents, let's understand the design points of each level in the framework's layered architecture:
- Service interface layer (Service): This layer is related to the actual business logic, and the corresponding interface and implementation are designed according to the business of the service provider and service consumer.
- Configuration layer (Config): External configuration interface, centered on ServiceConfig and ReferenceConfig, you can directly create new configuration classes, or you can generate configuration classes through spring parsing configuration.
- Service Proxy Layer (Proxy): Transparent proxy of service interface, which generates the client Stub and server Skeleton of the service, with ServiceProxy as the center, and the extension interface is ProxyFactory.
- Service registration layer (Registry): Encapsulates the registration and discovery of service addresses, centered on the service URL, and the extended interfaces are RegistryFactory, Registry, and RegistryService. There may be no service registry, in which case the service provider directly exposes the service.
- Cluster layer (Cluster): encapsulates routing and load balancing of multiple providers, and bridges the registration center, with Invoker as the center, and the extended interfaces are Cluster, Directory, Router, and LoadBalance. Combining multiple service providers into one service provider realizes transparency to service consumers and only needs to interact with one service provider.
- Monitoring layer (Monitor): Monitoring the number of RPC calls and call time, with Statistics as the center, and the extended interfaces are MonitorFactory, Monitor and MonitorService.
- Remote call layer (Protocol): Encapsulates RPC calls, centered on Invocation and Result, and extends the interface to Protocol, Invoker, and Exporter. Protocol is the service domain, it is the main function entry exposed and referenced by Invoker, and it is responsible for the life cycle management of Invoker. Invoker is the entity domain, it is the core model of Dubbo, other models rely on it, or convert to it, it represents an executable body, and can initiate invoke calls to it, it may be a local implementation, or it may be Is a remote implementation, and possibly a cluster implementation.
- Information exchange layer (Exchange): encapsulates the request response mode, synchronously to asynchronous, centered on Request and Response, and the extended interfaces are Exchanger, ExchangeChannel, ExchangeClient and ExchangeServer.
- Network transport layer (Transport): abstract mina and netty as unified interfaces, with Message as the center, and extended interfaces as Channel, Transporter, Client, Server, and Codec.
- Data serialization layer (Serialize): Some reusable tools, extended interfaces are Serialization, ObjectInput, ObjectOutput and ThreadPool.
从上图可以看出，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支持多种协议，如下所示：
- Dubbo协议
- Hessian协议
- HTTP协议
- RMI协议
- WebService协议
- Thrift协议
- Memcached协议
- Redis协议
在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。
参考补充
Dubbo以包结构来组织各个模块，各个模块及其关系，如图所示：
可以通过Dubbo的代码（使用Maven管理）组织，与上面的模块进行比较。简单说明各个包的情况：
- dubbo-common 公共逻辑模块，包括Util类和通用模型。
- dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。
- dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
- dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡、容错、路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。
- The dubbo-registry registry module, based on the clustering method of addresses issued by the registry, and the abstraction of various registries.
- The dubbo-monitor monitoring module, which counts the number of service calls, the call time, and the service tracked by the call chain.
- The dubbo-config configuration module is Dubbo's external API. Users can use Dubbo through Config to hide all the details of Dubbo.
- The dubbo-container container module is a standalone container that loads Spring Boot with a simple Main, because services usually do not need the features of web containers such as Tomcat/JBoss, so there is no need to use a web container to load services.
Reference link
- https://github.com/alibaba/dubbo
- http://alibaba.github.io/dubbo-doc-static/Home-zh.htm
- http://alibaba.github.io/dubbo-doc-static/User+Guide-zh.htm
- http://alibaba.github.io/dubbo-doc-static/Developer+Guide-zh.htm
- http://alibaba.github.io/dubbo-doc-static/Administrator+Guide-zh.htm
- http://alibaba.github.io/dubbo-doc-static/FAQ-zh.htm