Introduction to Dubbo

Original text: http://blog.java1234.com/blog/articles/377.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. For details, please refer to Baidu Encyclopedia  https://baike.baidu.com/item/Dubbo/18907815?fr=aladdin

      Dubbo homepage address  http://dubbo.io/   

      Hosting GitHub  https://github.com/alibaba/dubbo    If we learn, we mainly look at this github homepage.

 

      Dubbo User Manual  http://dubbo.io/books/dubbo-user-book/   Dubbo introduction and usage plan and many examples;

      Dubbo Development  Guidehttp: //dubbo.io/books/dubbo-dev-book/   Introduction of Dubbo's underlying source code and design;

      Dubbo management manual  http://dubbo.io/books/dubbo-admin-book/   Dubbo registration center, installation and use of management console;

 

The download is an introduction to Dubbo, and the content comes from the Dubbo user manual;

 

background

With the development of the Internet, the scale of website applications continues to expand, and the conventional vertical application architecture can no longer cope. Distributed service architecture and mobile computing architecture are imperative, and a governance system is urgently needed to ensure the orderly evolution of the architecture.

single application architecture

When the website traffic is small, only one application is needed, and all functions are deployed together to reduce deployment nodes and costs. At this point, a data access framework (ORM) that simplifies CRUD workloads is key.

Vertical Application Architecture

When the number of visits gradually increases, the acceleration brought by adding a single application to the machine is getting smaller and smaller, and the application is divided into several applications that are not related to each other to improve efficiency. At this point, a web framework (MVC) for accelerating front-end page development is key.

Distributed Service Architecture

When there are more and more vertical applications, the interaction between applications is inevitable. The core business is extracted as an independent service, and a stable service center is gradually formed, so that front-end applications can respond more quickly to changing market demands. At this time, the distributed service framework (RPC) for improving business reuse and integration is the key.

Mobile Computing Architecture

When there are more and more services, problems such as capacity evaluation and waste of small service resources gradually appear, a dispatch center needs to be added to manage the cluster capacity in real time based on the access pressure to improve the cluster utilization. At this point, a Resource Scheduling and Governance Center (SOA) for improving machine utilization is key.

 

 

 

need

Before large-scale service, applications may simply expose and reference remote services through tools such as RMI or Hessian, call them by configuring the URL address of the service, and perform load balancing through hardware such as F5.

When there are more and more services, service URL configuration management becomes very difficult, and the single point of pressure on the F5 hardware load balancer is also increasing. At this time, a service registry is needed to dynamically register and discover services, so that the location of the service is transparent. And by obtaining the address list of service providers on the consumer side, it can realize soft load balancing and failover, reduce the dependence on the F5 hardware load balancer, and also reduce some costs.

With further development, the dependencies between services become complicated and misunderstood, and it is not even clear which application should be started before which application, and architects cannot fully describe the architectural relationship of the application. At this time, it is necessary to automatically draw a dependency relationship diagram between applications to help architects clean up the relationship.

Then, the call volume of the service is increasing, and the capacity problem of the service is exposed. How many machines does this service need? When should the machine be added? In order to solve these problems, the first step is to count the current daily call volume and response time of the service as a reference indicator for capacity planning. Secondly, it is necessary to dynamically adjust the weight. Online, increase the weight of a certain machine all the time, and record the change of the response time in the process of increasing, until the response time reaches the threshold, record the number of visits at this time, and then use This number of visits is multiplied by the number of machines to invert the total capacity.

The above are the most basic requirements of Dubbo.

 

Architecture

Node role description

node	Role description
Provider	The service provider that exposes the service
Consumer	Service consumer calling the remote service
Registry	Registry for Service Registration and Discovery
Monitor	A monitoring center that counts service calls and call times
Container	service running container

Description of calling relationship

1. The service container is responsible for starting, loading, and running the service provider.

2. When the service provider starts, it registers the service it provides with the registry.

3. When a service consumer is started, it subscribes to the registry for the services it needs.

4. 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.

5. 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, selects another to call.

6. Service consumers and providers accumulate the number of calls and call times in memory, and regularly send statistical data to the monitoring center every minute.

The Dubbo architecture has the following characteristics, namely connectivity, robustness, scalability, and upgradeability to future architectures.

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 small.

• The monitoring center is responsible for counting the number of service calls, call 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 services 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, directly calls the provider according to the load algorithm, and reports the calling time to the monitoring center, which includes network overhead.

• The registration center, service provider, and service consumer are all long-term connections, except for the monitoring center

• The registration center perceives the existence of the service provider through the long connection. If the service provider is down, 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 monitoring center are optional, and service consumers can directly connect to service providers

fitness

• The downtime of the monitoring center does not affect the use, but only part of the sampled data is lost

• After the database is down, the registry can still provide service list query through the cache, but cannot register new services

• Registry center peer-to-peer cluster, after any one goes down, it will automatically switch to another

• After all the registries are down, service providers and service consumers 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 service providers are down, the service consumer application will be unavailable, and will reconnect infinite times waiting for the service provider to recover

Scalability

• The registry is a peer-to-peer cluster, which can dynamically increase 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

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. The following figure is a possible architecture in the future:

Node role description

node	Role description
Deployer	Local proxy for auto-deployment services
Repository	The repository is used to store service application release packages
Scheduler	The dispatch center automatically increases or decreases service providers based on access pressure
Admin	Unified management console
Registry	Registry for Service Registration and Discovery
Monitor	A monitoring center that counts service calls and call times