Shulou(Shulou.com)06/03 Report--

This article mainly introduces the concept, architecture and Load Balancer of Apache Dubbo. In daily operation, I believe many people have doubts about the concept, architecture and Load Balancer of Apache Dubbo. I have consulted all kinds of materials and sorted out simple and easy operation methods. I hope to help you answer the doubts about the concept, architecture and Load Balancer of Apache Dubbo! Next, please follow the small series to learn together!

An important concept.

1.1 What is Dubbo?

Apache Dubbo (incubating) |ˈdʌbəʊ| 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 Balancer, and automatic service registration and discovery. Dubbo is a distributed services framework dedicated to providing high-performance and transparent RPC remote service invocation solutions and SOA service governance solutions.

Dubbo currently has close to 25k Star, Dubbo Github address: https://www.example.com. github.com/apache/incubator-dubbo In addition, in the 2018 Most Popular Chinese Open Source Software held in Open Source China, Dubbo won the third place with its high popularity after vue.js and ECharts.

Dubbo was open-sourced by Ali and later joined Apache. Due to the advent of Dubbo, more and more companies are beginning to use and accept distributed architectures.

We said above that Dubbo is actually an RPC framework, so what is RPC?

1.2 What is RPC? What is RPC principle?

What is RPC?

RPC(Remote Procedure Call) is a protocol for requesting services from remote computer programs over a network without knowledge of the underlying network technology. For example, two different services A and B are deployed on two different machines, so what if service A wants to call a method in service B? Using HTTP requests is fine, but it can be slow and some optimizations don't work well. RPC was created to solve this problem.

What is RPC principle?

i'm here to briefly mention it. Details can be found in the following article:

http://dubbo.apache.org/zh-cn/blog/rpc-introduction.html

RPC Schematic

service client invocation Invocation of a service as a local invocation;

After receiving the call, the client stub is responsible for assembling the methods and parameters into a message body that can be transmitted on the network;

client stub finds the service address and sends the message to the server;

The server stub decodes the message after receiving it;

server stub invokes local services according to decoding results;

local service executes and returns the results to the server stub;

the server stub packages the returned result into a message and sends the message to the consumer;

The client stub receives the message and decodes it.

Service consumers get the final result.

Below is a timeline posted online:

RPC schematic timing diagram

So, why do we use Dubbo?

1.3 Why Dubbo?

The birth of Dubbo has a lot to do with the popularity of SOA distributed architecture. SOA (Service Oriented Architecture), that is, the project is divided into two projects: service layer and presentation layer according to business logic. The service layer contains business logic and only needs to provide services to the outside world. The presentation layer only needs to handle interactions with pages, and the business logic is implemented by invoking services of the service layer. There are two main roles in SOA architecture: service provider and service consumer.

Why Dubbo?

If you're developing distributed programs, you can also communicate directly over HTTP interfaces, but why Dubbo?

I think it can be mainly from the following four features provided by Dubbo why use Dubbo:

HarmonyOS Technology Community

Load Balancer--When the same service is deployed on different machines, the service on which machine should be invoked

Service invocation link generation-With the development of the system, there are more and more services, and the dependencies between services become complicated. It is even unclear which application should be launched before which application. Architects cannot fully describe the architectural relationship of applications. Dubbo can solve for us how services call each other.

Service access pressure and duration statistics, resource scheduling and governance--Manage cluster capacity in real time based on access pressure to improve cluster utilization.

Service degradation--invoke standby service after a service is down

In addition, Dubbo can be applied to distributed systems, but also to microservice systems that are now relatively hot. However, since Spring Cloud is more widely used in microservices, I think we generally mention Dubbo, most of which are distributed systems.

We have just mentioned the concept of distribution, let us introduce you to what is distributed? Why distribute?

1.4 What is distributed?

Distributed or SOA distributed is important for service-oriented, simple distribution is that we split the whole system into different services and then put these services on different servers to reduce the pressure of single services and improve concurrency and performance. For example, an e-commerce system can be simply split into an order system, a commodity system, a login system, etc. Each service after splitting can be deployed on different machines, and if a service has a large number of visits, it can also be deployed on multiple machines at the same time.

1.5 Why distribute?

From a development perspective, the code of a monolithic application is centralized, while the code of a distributed system is divided according to the business. Therefore, each team can be responsible for the development of a service, which improves development efficiency. In addition, the code is easier to maintain and extend after it is split according to the business.

In addition, I think that splitting the system into distributed parts will not only facilitate system expansion and maintenance, but also improve the performance of the entire system. Think about it? Splitting the entire system into different services/systems, and then deploying each service/system separately on a server, does it greatly improve system performance?

II. Structure of Dubbo

2.1 Architecture diagram of Dubbo

Dubbo architecture

A brief description of the above nodes:

Provider: The service provider that exposes the service

Consumer: service consumer that invokes remote services

Registry: Registry for service registration and discovery

Monitor: A monitoring center that counts the number and time of service calls

Container: Service running container

Call relationship description:

Service containers are responsible for starting, loading, and running service providers.

A service provider registers its services with the registry at startup.

At startup, service consumers subscribe to the registry for the services they need.

The registry returns the list of service provider addresses to the consumer and if there are changes, the registry will push the change data to the consumer based on the long connection.

The service consumer selects one provider from the provider address list to invoke based on the soft Load Balancer algorithm, and selects another provider to invoke if the invocation fails.

Service consumers and providers accumulate the number of calls and call time in memory, and send statistical data to the monitoring center every minute at regular intervals.

Summary of important knowledge points:

Registry is responsible for registration and lookup of service addresses, equivalent to directory services, service providers and consumers only interact with registry at startup, registry does not forward requests, less pressure

The monitoring center is responsible for counting the times and time of each service invocation. The statistics are summarized in memory and sent to the monitoring center server once a minute, and displayed in reports.

Registry, service provider and service consumer are all long-term connections, except monitoring center.

The registry senses the presence of the service provider through a long connection, the service provider goes down, and the registry will immediately push the event notification to the consumer

Registry and monitoring center all down, does not affect the running providers and consumers, consumers locally cached provider list

Both the registry and monitoring center are optional, and service consumers can connect directly to service providers

Service providers are stateless, and any one of them fails without affecting usage.

After all service providers are down, the service consumer application becomes unusable and reconnects indefinitely waiting for the service provider to recover

2.2 How Dubbo Works

How Dubbo Works

The figure is divided into ten layers from bottom to top, each layer is one-way dependency, the black arrow on the right represents the dependency relationship between layers, each layer can be stripped of the upper layer to be multiplexed, where the Service and Config layers are API, and the other layers are SPI.

Description of each layer:

The first layer: service layer, interface layer, for service providers and consumers to implement

The second layer: config layer, configuration layer, mainly dubbo for various configurations

Layer 3: proxy layer, transparent proxy for service interface, client Stub and server skeleton for generating service

The fourth layer: registry layer, service registration layer, responsible for service registration and discovery

Layer 5: Cluster Layer, encapsulating routing for multiple service providers and Load Balancer, combining multiple instances into a single service

The sixth layer: monitor layer, monitoring the number of calls and call time of rpc interface

Layer 7: protocol layer, remote call layer, encapsulating rpc calls

Layer 8: exchange layer, information exchange layer, encapsulation request response mode, synchronous to asynchronous

Layer 9: transport layer, network transport layer, abstract mina and netty for unified interface

Layer 10: serialize layer, data serialization layer. Network transmission is required.

Three Dubbo Load Balancer Strategies

3.1 Let's first explain what Load Balancer is

Let's start with an official explanation.

Wikipedia definition of Load Balancer: Load Balancer improves workload distribution across multiple computing resources (e.g. computers, computer clusters, network links, central processing units, or disk drives). Load balancing aims to optimize resource usage, maximize throughput, minimize response time, and avoid overloading any individual resource. Using multiple components with load balancing rather than a single component can improve reliability and availability through redundancy. Load balancing usually involves dedicated software or hardware

What you said above may not be easy to understand, so let me tell you in common terms.

For example, a certain service in our system has a particularly large number of visits. We deploy this service on multiple servers. When the client initiates a request, multiple servers can handle this request. How to choose the right server to handle the request is critical. If you want a single server to handle requests for the service, there is no point in deploying the service on multiple servers. Load Balancer is to avoid problems such as server downtime and crash caused by single server responding to the same request. We can obviously feel its significance from these four words of Load Balancer.

3.2 Let's look at the Load Balancer strategy provided by Dubbo

When cluster Load Balancer is used, Dubbo provides multiple balancing strategies, and random is invoked by default. The Load Balancer policy can be extended on its own, see: Load Balancer Extension.

Note: The image below is from: Shang Silicon Valley 2018Dubbo video.

3.2.1 Random LoadBalance(default, weight-based random Load Balancer mechanism)

Random, sets random probability by weight.

The probability of collision on a section is high, but the larger the call amount, the more uniform the distribution, and the weight is more uniform after using the probability, which is beneficial to dynamically adjust the weight of the provider.

Random Load Balancer Mechanism Based on Weight

3.2.2 RoundRobin LoadBalance(not recommended, weight-based polling Load Balancer mechanism)

Rotation, which sets the rotation ratio by weight after the convention.

There is a problem with slow providers accumulating requests, such as: the second machine is slow, but it doesn't hang up, and when the request is transferred to the second machine, it gets stuck, and over time, all requests get stuck on the second machine.

Weighted Polling Load Balancer Mechanism

3.2.3 LeastActive LoadBalance

Minimum number of active calls, random for the same active number, active number refers to the difference in count before and after the call.

Make slower providers receive fewer requests, because slower providers have larger before-and-after count differences.

3.2.4 ConsistentHash LoadBalance

Consistent Hash: Requests with the same parameters are always sent to the same provider. (If what you need is not random Load Balancer, but one type of request to a node, then follow this consistent hash strategy.)

When a provider is down, requests originally destined for that provider are spread evenly across other providers based on virtual nodes without causing dramatic changes.

Algorithm: en.wikipedia.org/wiki/Consistent_hashing

By default, only the first parameter is hashed. If you want to modify it, please configure it.

160 virtual nodes are used by default. Please configure if you want to modify them.

3.3 configuration mode

XML configuration mode

server-side service level

Client Service Level

server-side method level

Client Method Level

Annotations Configuration:

Consumer annotation-based service level configuration:

Four zookeeper downtime and dubbo direct connection

Zookeeper downtime and dubbo direct connection may be frequently asked in interviews, so pay attention to it.

In production, if the zookeeper registry goes down, the service consumer will still be able to invoke the provider's service for a while, and it will actually use the local cache for communication, which is just a manifestation of dubbo robustness.

Dubbo robustness performance:

Monitoring center down does not affect the use, just lost part of the sampling data

After a database crash, the registry can still provide service list queries through the cache, but cannot register new services

Register peer-to-peer cluster. After any one of them goes down, it will automatically switch to another one.

Service providers and service consumers can still communicate through local caches after all registries are down

Service providers are stateless, and any one of them fails without affecting usage.

After all service providers are down, the service consumer application becomes unusable and reconnects indefinitely waiting for the service provider to recover

As we mentioned earlier, the registry is responsible for the registration and lookup of service addresses, which is equivalent to a directory service. Service providers and consumers only interact with the registry at startup. The registry does not forward requests, and the pressure is small. So we can bypass the registry entirely--dubbo direct, which configures the location of the service provider at the service consumer.

At this point, the study of "Apache Dubbo concept, architecture and Load Balancer" is over, hoping to solve everyone's doubts. Theory and practice can better match to help you learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.