Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions. Simply put, dubbo is a service framework. If there is no distributed demand, it is actually unnecessary. Only when it is distributed, there is a demand for a distributed service framework like dubbo, and it is essentially a service call. Dongdong, to put it bluntly, is a distributed framework for remote service calls.
Its core parts include:
1. Remote communication: Provides abstract encapsulation of various long-connection-based NIO frameworks, including various threading models, serialization, and "request- Response" mode of information exchange.
2. Cluster fault tolerance: Provides transparent remote procedure calls based on interface methods, including multi-protocol support, and cluster support such as soft load balancing, failure tolerance, address routing, and dynamic configuration.
3. Automatic discovery: Based on the registry directory service, the service consumer can dynamically find the service provider, making the address transparent, so that the service provider can smoothly increase or decrease the machine.
Application Scenario
1. Transparent remote method call, just like calling a local method to call a remote method, just simple configuration, without any API intrusion.
2. Soft load balancing and fault tolerance mechanism can replace hardware load balancers such as F5 in the intranet, reduce costs and reduce single points.
3. The service is automatically registered and discovered, and it is no longer necessary to write the address of the service provider. The registration center queries the IP address of the service provider based on the interface name, and can smoothly add or delete service providers.
Dubbo adopts the full spring configuration method to transparently access the application without any API intrusion into the application. You only need to use Spring to load the configuration of Dubbo, and Dubbo is loaded based on Spring's Schema extension.
Node role description:
Provider: The service provider that exposes the service.
Consumer: The service consumer that invokes the remote service.
Registry: A registry for service registration and discovery. (recommended zookeeper)
Monitor: The monitoring center that counts the invocation times and invocation time of the service.
Container: The service runs the container.
Description of the calling relationship:
0. (start) The service container is responsible for starting, loading, and running the service provider.
1. (register) The service provider registers the services it provides with the registry at startup.
2. (subscribe) When the service consumer starts, it subscribes to the registry for the services it needs.
3. (notify) The registry returns the service provider address list to the consumer. If there is a change, the registry will push the change data to the consumer based on the persistent connection.
4. (invoke) The service consumer, from the provider address list, selects a provider to call based on the soft load balancing algorithm, and if the call fails, select another provider to call.
5. (count) Service consumers and providers, accumulate the number of calls and call time in memory, and regularly send statistical data to the monitoring center every minute.
Feature
(1) Connectivity:
The registration center is responsible for the registration and search of service addresses, which is equivalent to a directory service. Service providers and consumers only interact with the registration center at startup. The registration center does not forward requests, and the pressure is low. The
monitoring center is responsible for statistics The number of calls, call time, etc. of each service, statistics are first aggregated in memory and sent to the monitoring center server once a minute, and displayed in a report. The
service provider registers the services it provides with the registration center, and reports the calling time to the monitoring center. This time Does not include network overhead The
service consumer obtains the address list of service providers from the registration center, directly calls the provider according to the load algorithm, and reports the calling time to the monitoring center, which includes network overhead
. Registration center, service provider, service consumer three The
registration center senses the existence of the service provider through the long connection, and the service provider is down, and the registration center will immediately push the event to notify the consumer
. Both the registration center and the monitoring center are down, and the existing Running providers and consumers. The consumer caches the provider list locally. The
registration center and the monitoring center are optional, and the service consumer can directly connect to the service provider
(2) Health: the
monitoring center is down without affecting Use, only part of the sampled data is lost. After the
database down, the registry can still provide service list query through the cache, but cannot register new services
. The peer-to-peer cluster of the registry will automatically switch to another
registry After all are down, the service provider and the service consumer can still communicate through the local cache. The
service provider is stateless. After any one is down, it will not affect the use
. After all the service providers are down, the service consumer application will be unavailable. And reconnect indefinitely waiting for the service provider to restore
(3) scalability:
The registry is a peer-to-peer cluster, which can dynamically add machine deployment instances, and all clients will automatically discover the new registry.
Service providers are stateless, and machine deployment instances can be dynamically added. The registry will push new service provider information to consumers.
(4) Upgradability:
When the scale of the service cluster is further expanded, and the IT governance structure is further upgraded, dynamic deployment and mobile computing need to be implemented, and the existing distributed service architecture will not bring resistance.
source code structure
