Dubbo Architecture


Specification of Node’s Role
NodeRole Spec
ProviderThe provider exposes remote services
ConsumerThe consumer calls the remote services
RegistryThe registry is responsible for service discovery and configuration
MonitorThe monitor counts the number of service invocations and time-consuming
ContainerThe container manages the services’s lifetime
Service relationship
  1. Container is responsible for launching, loading, and running the service Provider.
  2. Provider registers its services to Register at the time it starts.
  3. Consumer subscribes the services it needs from the Register when it starts.
  4. Register returns the Providers list to Consumer, when it changes, the Register will push the changed data to Consumer through long connection.
  5. Consumer selects one of the Providers based on soft load balancing algorithm and executes the invocation, if fails, it will choose another Provider.
  6. Both Consumer and Provider will count the number service invocations and time-consuming in memory, and send the statistics to Monitor every minute.

Dubbo has the following features: Connectivity, Robustness, Scalability and Upgradeability.


  • Register is responsible for the registration and search of service addresses, like directory services, Provider and Consumer only interact with the registry during startup, and the registry does not forward requests, so it is less stressed
  • ‘Monitor’ is responsible for counting the number of service invocations and time-consuming, the statistics will assembles in Provider’s and Consumer’s memory first and then sent to Monitor
  • ‘Provider’ registers services to ‘Register’ and report time-consuming statistic(not include network overhead) to ‘Monitor’
  • ‘Consumer’ gets a list of service provider addresses from Registry, call the provider directly according to the LB algorithm, report the time-consuming statistic to Monitor, which includes network overhead
  • The connections between Register, Provider and Consumer are long connections, Moniter is an exception
  • Register is aware of the existence of Provider through the long connection, when Provider gets down, Register will push the event to Consumer
  • It doesn’t affect the already running instances of Provider and Consumer even all of the Register and Monitor get down, since Consumer got a cache of Providers list
  • Register and Monitor are optional, Consumer can connect Provider directly


  • Monitor’s downtime doesn’t affect the usage, only lose some sampling data
  • When the DB server goes down, Register can return service Providers list to Consumer by checking its cache, but new Provider cannot register any services
  • Register is a peer cluster, it will automatically switch to another when any instance goes down
  • Even all Register’s instances go down, Provider and Consumer can still conmunicate by checking their local cache
  • Service Providers are stateless, one instance’s downtime doesn’t affect the usage
  • After all the Providers of one service go down, Consumer can not use that service, and infinitely reconnect to wait for service Provider to recover


  • Register is a peer cluster that can dynamically increases its instances, all clients will automatically discover the new instances.
  • Provider is stateless, it can dynamically increases the deployment instances, and the registry will push the new service provider information to the Consumer.


When the service cluster is further expanded and the IT governance structure is further upgraded, dynamic deployment is needed, and the current distributed service architecture will not bring resistance. Here is a possible future architecture:


Specification of Node’s Role
NodeRole Spec
DeployerLocal proxy for automatic services deployment
RepositoryThe repository is used to store application packages
SchedulerThe scheduler automatically increases or decreases service providers based on the access pressure
AdminUnified management console
Registrythe registry is responsible for service discovery and configuration
MonitorThe monitor counts the service call times and time-consuming

Last modified December 22, 2020: clean up website (6e41905afab)