Popular Dubbo Tutorial (1): What is Dubbo?

Most of the following from Dubbo official document, the document addresses user documentation

1 What is Dubbo?

Workers must first sharpen their tools to do their best, so what exactly is Dubbo? We need to define it.

Dubbo is an open source distributed service framework that enables applications to implement service output and input functions through high-performance RPC, and can be seamlessly integrated with the Spring framework.

Dubbo is a high-performance, lightweight open source Java RPC framework that provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.

2 Why do we need Dubbo?

With the development of the Internet, the scale of website applications may continue to expand. The good days that only required one server to complete all functions are gone. A distributed service architecture is imperative. We urgently need a governance system to ensure The methodical evolution of the architecture.

Before large-scale service, the application may simply expose and reference the remote service, call it by configuring the URL of the service, and load balance through hardware such as F5.

With the increase of traffic and the iteration of business, the relationship between applications and applications gradually becomes more complicated, and the following problems may occur:

  1. When there are more and more services, service URL configuration management becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing
  2. When it develops further, the dependencies between services become complex and missing, and it is impossible to tell which application should be started before which application, and the architect cannot fully describe the architectural relationship of the application.
  3. Then, the amount of service calls is getting larger and larger, and the capacity problem of the service is exposed. How much machine support is needed for this service? When should I add the machine?

So how should it be solved? The above three problems are also the most basic needs of Dubbo. The solutions to the three problems are as follows:

  1. A service registration center is needed to dynamically register and discover services to make the location of services transparent. And by obtaining the service provider address list on the consumer side, soft load balancing and failover are realized, reducing the dependence on the F5 hardware load balancer, and can also reduce some costs
  2. Need to automatically draw the dependency graph between applications to help architects sort out the relationship
  3. The daily call volume and response time of the service are counted as a reference index for capacity planning; the weight can be dynamically adjusted, and the weight of a certain machine has been increased online, and the response time is recorded during the increase Changes until the response time reaches the threshold, record the number of visits at this time, and then multiply the number of visits by the number of machines to infer the total capacity

Insert picture description here
Dubbo's main purpose is to solve the above three problems. From Dubbo's service governance diagram, we can find that Duboo solves a series of problems caused by the evolution of the architecture.

3 Dubbo architecture

Insert picture description here
The description of node roles is as follows:

  1. Provider: Service provider that exposes the service
  2. Consumer: Service consumer that invokes remote services
  3. Registry: Registry for service registration and discovery
  4. Monitor: a monitoring center that counts the number and time of service calls
  5. Container: Service running container

The calling relationship is as follows:

  1. The service container is responsible for starting, loading, and running the service provider
  2. When the service provider starts, it registers its own service with the registration center
  3. When service consumers start, they subscribe to the registration center for the services they need
  4. The registration center returns the service provider address list to the consumer. If there is a change, the registration center will push the changed data to the consumer based on the long connection
  5. Service consumers, from the provider address list, based on the soft load balancing algorithm, choose a provider to call, if the call fails, then choose another call
  6. Service consumers and providers, accumulate call times and call time in memory, and send statistical data to the monitoring center regularly every minute
Published 151 original articles · praised 317 · 40,000+ views

Guess you like

Origin blog.csdn.net/Geffin/article/details/105543478
Recommended