First of all, let me state that the article is quoted from someone else. I feel that it is very well written. It must be saved. URL link : http://blog.sina.com.cn/s/blog_493a84550102vlie.html
Dubbo is a high-performance and excellent service framework open sourced by Alibaba, which enables applications to realize the output and input functions of services through high-performance RPC, and can be seamlessly integrated with the Spring 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. Main core components:
Remoting: A network communication framework that implements sync-over-async and request-response message mechanisms.
RPC: An abstraction of remote procedure calls, supporting load balancing, disaster recovery and clustering functions
Registry: Service directory framework for service registration and service Event publish and subscribe
Connectivity Notes
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, so the pressure is small; the monitoring center is responsible for counting the number of service calls and calling Time, etc., the statistics are first aggregated in memory and sent to the monitoring center server every minute, and displayed in a report.
The service provider registers the service it provides with the registration center, and reports the calling time to the monitoring center, which does not include network overhead; the service consumer obtains the address list of service providers from the registration center, and directly calls the provider according to the load algorithm. Report the calling time to the monitoring center, and this time includes network overhead.
The registration center, service provider, and service consumer are all persistent connections, except for the monitoring center; the registration center perceives the existence of the service provider through the persistent connection, and the service provider is down, and the registration center will immediately push the event to notify the consumer ;The registration center and monitoring center are all down, which does not affect the 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 By.
Health description
The failure of the monitoring center does not affect the use, but only loses some sampled data; after the database is down, the registration center can still provide service list query through the cache, but cannot register new services.
In the peer-to-peer cluster of the registry, after any one goes down, it will automatically switch to the other; after all the registry goes down, the service provider and the service consumer can still communicate through the local cache. The service provider is stateless. After any one goes down, it will not affect the use. After all the service providers go down, the service consumer application will be unavailable, and it will reconnect infinitely and wait for the service provider to recover.
Scalability Notes
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 can dynamically add machine deployment instances, and the registry will push new service provider information to consumers By.
The above contents are some brief introductions provided by the Dubbo homepage. There are also special articles on the website for the detailed architecture analysis and introduction of Dubbo. I will not describe them in detail here, but simply summarize some of the architectural ideas and usage scenarios of Dubbo itself.
As can be seen from the Dubbo distributed service framework, it is quite beneficial to achieve complete componentized independent development in the system. Before this, the method we often used was to use the OSGI soft bus method to achieve internal componentized development and independent deployment. The Dubbo framework can achieve this more easily, that is, the methods of the logic layer are easily exposed as various types of services that can be called remotely. That is, the components are deployed completely independently, and the interaction between the components can only interact through the services exposed by the service proxy layer, and these services are registered in the service registry.
For the registration center and the monitoring center, there is a high-reliability design, that is, even if both are down and cannot be accessed, it will not affect the normal consumption and invocation of the service. This design is very important and directly reduces its own service framework and business. Strong coupling between system components. Of course, the registry itself also has a built-in zookeeper-based distributed coordination mechanism and dynamic heartbeat detection of the machine itself.
A key difference between the Dubbo distributed service framework and the traditional ESB is that the actual message flow does not go on Dubbo, that is, the invocation of the service as mentioned in the previous article is basically a two-invocation mode. That is, the first call first obtains the dynamic service call address from the registration center, and the second call is the direct handshake between the service provider and the consumer to solve the problem that the message flow does not need to be transmitted on the dubbo. The advantage of this is that dubbo itself will not have too much pressure on message transmission and performance, but the disadvantage is that dubbo cannot perform detailed auditing of the message transmission log, which can only be done by each business system itself.
Because of the two-way handshake, it is easy to implement a complete distributed service architecture mode, and this distributed cluster does not require any cluster software and load balancing equipment. This is another important advantage of the Dubbo framework, that is, there is a request allocation mechanism in the service registry itself, which can dynamically allocate service requests to different server-provided addresses according to various allocation strategies when obtaining service access addresses. That is to say, all service provider IP addresses and service addresses need to be configured to the service registration center, and the service registration center performs an average distribution of service requests according to a certain load balancing algorithm. Due to the stateless nature of the service itself, there is no need for a dedicated service state and session retention mechanism.
The heartbeat detection of the application is an important content. Note that this is not only the heartbeat check of the server itself, but may be the heartbeat detection of whether the service is available. Only by implementing the heartbeat at this level, the service registration and management center may not be able to work on the service provider side. When accessing, other accessible service provider addresses are dynamically allocated to form a high-availability architecture model. The commonly used method for heartbeat detection is still based on the long connection and status monitoring mechanism of sockets. However, the biggest problem with the tcp keepalive heartbeat detection mechanism is that it cannot detect whether the service itself is available. This problem is fundamentally solved.
Note that there are two important modules in dubbo, one is the dubbo-cluster cluster module, which disguises multiple service providers as one provider, including: load balancing, fault tolerance, routing, etc. The address list of the cluster can be statically configured , or it can be issued by the registration center. The other is the dubbo-registry registry module, which is based on the clustering method of addresses issued by the registry, and the abstraction of various registries. It should be noted that the actual invocation and message transmission of the service itself by the service registration center and service monitoring center corresponding to these two modules are completely decoupled, which is also a basis for dubbo itself to achieve high availability and high reliability.
Dubbo's current implementation mechanism can also be used for reference when designing ESB-type service buses, that is, its implementation ideas for clusters, and implementation ideas for monitoring centers and service registration centers. Through the realization of this idea, the ESB service bus can be thoroughly designed as a fully distributed and highly scalable distributed service bus architecture model. This will solve both the distributed cluster expansion to the ESB bus itself and the inability of traditional dubbo to monitor and audit message log transmission.