Foreword:
This article is a personal note, referring to Dubbo's official documents , plus your own understanding, the summary of the execution process of Dubbo registration to publishing (or Dubbo principle), the technology involved in the middle, if you are interested, please search by yourself;
Dubbo Architecture:
As can be seen from the figure, Dubbo is divided into ten layers: Service (service layer), Config (configuration layer), Proxy (service proxy layer), Registry (intermediate registration layer), Cluster (cluster layer, including cluster fault tolerance and soft load) Balance, service degradation), Monitor (monitoring layer), Protocol (remote call layer), Exchange (information exchange layer), Transport (network transport layer, default Dubbo protocol, based on TCP [NIO], long connection), Serialize (data sequence Layer, the immature serialization method developed by Dubbo itself is not recommended, and open source Hession, ProtoBuf, etc. are recommended)
Dubbo execution process
1. Load the configuration file and parse the configuration file
1.1) Based on the Meta-inf/spring.handlers configuration in dubbo.jar, when spring encounters the dubbo namespace, it will call back the DubboNamespaceHandler class. (Config [Configuration Layer])
1.2) All dubbo tags are parsed uniformly with DubboBeanDefinitionParser, and based on one-to-one attribute mapping, XML tags are parsed into Bean objects. (Config [Configuration Layer])
1.3) Produce proxy objects according to configuration files (Proxy [Service Proxy Layer])
1.4) Encapsulation service address registration and discovery (registry [registration center layer])
2. Get the cluster list of all services and the same service (cluster routing layer)
Encapsulate each service into a Provider (service provider, here the meaning of a single service, such as order service)
1. Get the list of services and the cluster under each service. Here, the single machine provider that will deploy the service becomes the Invoker
2. Assemble multiple Invokers into a Directory. The Directory here can be understood as a List<Invoker>, but unlike List, its value may change dynamically, such as registry push changes
3. Disguise multiple Invokers as one Invoker, and the disguised Invoker is called a Cluster
4. The Router is responsible for selecting a subset from multiple Invokers according to routing rules
5. LoadBalance is responsible for selecting a specific one from multiple Invokers for this call. The selection process includes the load balancing algorithm. After the call fails, it needs to be reselected.
Here is a supplement to the cluster content:
Cluster configuration:
Cluster fault tolerance:
a) Failover Cluster (default mode): failover automatically, when a failure occurs, retry other servers 1. Typically used for read operations, but retries incur longer delays. The number of retries (excluding the first time) can be set by retries="2".
b) Failfast Cluster: Fast failure, only one call is made, and an error is reported immediately upon failure. Usually used for non-idempotent write operations, such as adding new records
c) Failsafe Cluster: Failsafe, when an exception occurs, ignore it directly. Typically used for operations such as writing to audit logs
d) Failback Cluster: Automatically recover from failure, record the failed request in the background, and resend it regularly. Typically used for message notification operations
e) Forking Cluster: Call multiple servers in parallel, and return as long as one succeeds. It is usually used for read operations with high real-time requirements, but it needs to waste more service resources. The maximum number of parallels can be set with forks="2".
f) Broadcast Cluster: broadcast calls to all providers, call them one by one, if any one reports an error, error 2 is reported. Typically used to notify all providers to update local resource information such as caches or logs.
3. Expose service:
Publishing service process: serialize the object using the immature serialization developed by Dubbo itself (serialize data serialization layer), realize asynchronous communication through netty or mina (transport network transport layer), encapsulate the request response mode, synchronous to asynchronous, Encapsulates RPC calls (protocol remote call layer)
Release method:
a) Expose only the service port: In the case where the registry is not used, this situation is generally applicable in the development environment. The service call is provided on the same IP, and only the port of the service needs to be opened.
b) Expose the service to the registry: the IP and port of the service need to be exposed to the registry together
4. Filter: Permission Control
5. Citation Services
Citation:
A) Direct Reference Services
B) Discover citation services from the registry
Reference service process: encapsulate RPC calls (protocol remote call layer), implement asynchronous communication, encapsulate request response mode, synchronously transfer asynchronously through netty or mina (transport network transport layer), and use the immature serialization developed by Dubbo for serialization Serialize (serialize data serialization layer) to restore the object back
References: Dubbo implementation details , Dubbo framework design , Dubbo cluster fault tolerance , Dubbo load balancing