|The provider exposes remote services|
|The consumer calls the remote services|
|The registry is responsible for service discovery and configuration|
|The monitor counts the number of service invocations and time-consuming|
|The container manages the services’s lifetime|
Containeris responsible for launching, loading, and running the service
Providerregisters its services to
Registerat the time it starts.
Consumersubscribes the services it needs from the
Registerwhen it starts.
Providers list to
Consumer, when it changes, the
Registerwill push the changed data to
Consumerthrough long connection.
Consumerselects one of the
Providers based on soft load balancing algorithm and executes the invocation, if fails, it will choose another
Providerwill count the number service invocations and time-consuming in memory, and send the statistics to
Dubbo has the following features: Connectivity, Robustness, Scalability and Upgradeability.
Registeris responsible for the registration and search of service addresses, like directory services,
Consumeronly interact with the registry during startup, and the registry does not forward requests, so it is less stressed
Consumer’s memory first and then sent to
Registry, call the provider directly according to the LB algorithm, report the time-consuming statistic to
Monitor, which includes network overhead
Consumerare long connections,
Moniteris an exception
Registeris aware of the existence of
Providerthrough the long connection, when
Registerwill push the event to
Consumereven all of the
Monitorget down, since
Consumergot a cache of
Monitor’s downtime doesn’t affect the usage, only lose some sampling data
Registercan return service
Providers list to
Consumerby checking its cache, but new
Providercannot register any services
Registeris a peer cluster, it will automatically switch to another when any instance goes down
Register’s instances go down,
Consumercan still conmunicate by checking their local cache
Providers are stateless, one instance’s downtime doesn’t affect the usage
Providers of one service go down,
Consumercan not use that service, and infinitely reconnect to wait for service
Registeris a peer cluster that can dynamically increases its instances, all clients will automatically discover the new instances.
Provideris stateless, it can dynamically increases the deployment instances, and the registry will push the new service provider information to the
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:
|Local proxy for automatic services deployment|
|The repository is used to store application packages|
|The scheduler automatically increases or decreases service providers based on the access pressure|
|Unified management console|
|the registry is responsible for service discovery and configuration|
|The monitor counts the service call times and time-consuming|
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.