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

This article focuses on "the underlying architecture principles of Spring Cloud". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the underlying architecture principles of Spring Cloud.

Eureka

First of all, we have to talk about the service registry Eureka, which should be the core of the SpringCloud technology stack.

How to implement service registration and discovery

Service registration and discovery is the core of Eureka.

For example, we now have a service consumer service An and a two-node service provider, service B. Both Service An and Service B register with the registry when they are started.

Service A will also regularly pull service registry information locally from the service registry. This process is called service discovery. The default is 30s. Of course, you can configure it yourself.

As shown below:

In fact, when the service is pulling the service registry, the client does not get the data directly from the service registry in Eureka.

Eureka does a two-level cache, the first level is called ReadOnly cache, and the second level is called ReadWrite cache.

The client reads the registry information directly from the ReadOnly cache.

When the service is registering, the registration information is first written to the service registry, which is updated, and a copy of the data is immediately synchronized to the ReadWrite cache.

So when will the data in the ReadWrite cache go to the ReadOnly cache?

At this time, a scheduled task will periodically check whether the ReadWrite is inconsistent with the ReadOnly, and synchronize the data to the ReadOnly.

This scheduled task also defaults to 30s. You can also configure it yourself.

You can think about the benefits of doing this, and why do you want to do secondary caching?

The advantage of this is that conflicts between concurrent reads and writes are optimized.

If the service registers and there are services to read and read registry information at the same time, there will be frequent read-write locking operations, which can not be read while writing, resulting in performance degradation, so we need to avoid a large number of read and write operations on a table.

So with these two layers, in fact, most of the read operations will go to the ReadOnly cache. You just need to write the data in the ReadWrite cache to ReadOnly regularly.

Heartbeat and Fault Detection

Another important function of the service registry is heartbeat and fault checking. Heartbeat and fault detection is actually to know whether the registered services are still alive.

Eureka will also start a scheduled task to check the heartbeat regularly, which is also 30 seconds by default, or you can set it yourself.

When there is a machine failure and does not report its status within the agreed time interval, then Eureka will delete the machine from the registry and update it to the ReadWrite cache. As shown in the figure:

But there is a time interval for synchronizing data from the ReadWrite cache to the ReadOnly cache. When the service consumer An only waits for the next request for an update, he will update the services in his list.

So sometimes it will occur that the service you registered is discovered by the service consumer in a timely manner, or that a node of the service fails and is not removed in time. Here is the problem of time difference of synchronization mechanism.

These are the core operating principles of Eureka.

Feign & Ribbon

Feign, which actually annotates an interface, generates a dynamic proxy object for the annotated interface, and then calls his method against your feign's dynamic proxy object, which is generated at the underlying level. Requests in http format such as: / order/create?productId=1

HttpClient, the HTTP communication framework used by Feign, first uses Ribbon to retrieve the list of machines to call the service from the local Eureka registry cache, and then selects a machine according to the load balancing algorithm, and then sends a Http request to the selected machine.

Zuul

Zuul configures the corresponding relationship between the request path and the service. When your request goes to the gateway, he directly finds the matching service, and then forwards the request directly to a machine of that service. Ribbon gets a machine from the Eureka local cache list, then selects one through the load balancing algorithm, and sends the request directly to the specified machine using the http communication framework.

Hystrix

In the architecture of micro-service, there will be a lot of service invocation. If a service fails, it will easily lead to the failure of the entire call chain and the occurrence of service avalanche.

For example, when a service fails or times out, but the service caller does not know it and keeps sending requests, more and more requests are waiting, resulting in a backlog of tasks, resulting in service crash and paralysis.

The emergence of Hystrix is to solve this problem. It provides powerful functions such as service degradation, service breaker, thread and signal isolation, request caching, request merging and service monitoring.

Hystrix uses the bulkhead pattern to isolate the thread pool, which creates a separate thread pool for each dependent service, so that even if the latency of a dependent service is too high, it only affects the invocation of that dependent service and does not slow down other dependent services.

At this point, I believe you have a deeper understanding of "the underlying architecture principles of Spring Cloud". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.