Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to use Eureka". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn how to use Eureka.

What is service registration and discovery

Governance center

Service registration

Service discovery

Heartbeat mechanism

All of the above can be achieved through Eureka

Basic concepts used by Eureka

Spring Cloud encapsulates the Eureka components developed by Netflix to realize service registration and discovery.

There are two roles in the architecture of Eureka: service registry Eureka Server and service client Eureka Client

Eureka registry Eureka Server

As the server of the service registration function, Eureka Server is the service registry. For other microservices in the system, clients using Eureka connect to the Eureka Server and maintain a heartbeat connection. In this way, the maintenance staff of the system can use Eureka Server to monitor whether the micro-services in the system are running properly.

Eureka client Eureka Client

EurekaClient is a Java client that simplifies Eureka Server interaction

After the application starts, a heartbeat is sent to the Eureka Server (the default period is 30 seconds). If EurekaServer does not receive a heartbeat from a node in multiple heartbeat cycles, EurekaServer will remove the service node from the service registry (default is 90 seconds)

Eureka Client caches the information in the service registry. This approach has certain advantages, first of all, it can reduce the pressure on Eureka Server, and secondly, when all Eureka Server goes down, the service caller can still complete the call.

Eureka registry building

Create a module in Project

Import dependency

Org.springframework.cloud spring-cloud-starter-netflix-eureka-server

Add comments to the startup class

Configuration file

Server: port: 8800eureka: client: # eureka.client. Register-with-eureka: set to false because the application is a registry Representatives do not register themselves with the registry registerWithEureka: false # do not actively discover others fetchRegistry: false # declare the address of the registry serviceUrl: defaultZone: http://localhost:8800/eureka/# give the current application a service name that cannot be accessed through the path this service name is used in the microservice to represent the current service spring: application: name: eureka-server

Start the registry to access the registry's monitoring page http://localhost:8800

Client build-user service

Take user service as an example

Create a project

! [image-20200420164741922] (SpringCloud H version before class 07 / https://gitee.com/bingqilinpeishenme/blogimg/raw/master/img/image-20200420164741922.png)

Import related dependencies

Org.springframework.cloud spring-cloud-starter-netflix-eureka-client

Add comments to the startup class

Configuration file

Server: port: 880 specifies the name of the current service. This name is registered with the registry spring: application: name: cloud-user-8804# specifies the address of the service registry eureka: client: serviceUrl: defaultZone: http://localhost:8800/eureka

Through the above four steps, we have completed the construction of an Eureka client and directly launched the project, which can be seen through the Eureka registry.

Follow the above steps to transform the commodity service and order service into an Eureka client.

Eureka advanced using CAP theory

At present, almost all large websites are distributed. The biggest difficulty of distributed system is how to synchronize the state of each node. CAP theorem is not only the basic theorem in this aspect, but also the starting point for understanding distributed systems.

In 1998, Eric Brewer, a computer scientist at the University of California, proposed that there are three indicators for distributed systems.

Consistency consistency

Availability availability

Fault tolerance of Partition tolerance partitions

Their first letters are C, An and P, respectively.

Eric Brewer says it is impossible to achieve all three indicators at the same time. This conclusion is called CAP theorem.

Partition fault tolerance

Most distributed systems are distributed in multiple subnetworks. Each subnetwork is called a partition. Partition fault tolerance means that interval communication may fail. For example, if one server is in China and the other is in the United States, these are the two zones that may not be able to communicate with each other.

Node1 and Node2 are two cross-zone servers. Node1 sends a message to Node2 and Node2 may not be able to receive it. This situation must be taken into account when designing the system.

Generally speaking, partition fault tolerance is unavoidable, so it can be considered that the P of CAP is always true. The CAP theorem tells us that the rest of C and A cannot be done at the same time.

Data consistency

Due to system problems, the data of Node1 cannot be immediately synchronized to Node2. If data is obtained, inconsistent data will be obtained. In order to ensure the consistency of data outside the distributed system, choose not to return any data [or all nodes do not respond to any requests].

Usability

The nodes in the system are required to respond immediately when they receive the request, that is, on the one hand, they need to give a response within a reasonable time, on the other hand, even if some of the nodes are down, then other nodes that are not down also need to be able to handle requests normally, and there is something wrong with the data returned immediately.

Why can't consistency and availability be established at the same time?

The answer is simple, because communication may fail (that is, partition fault tolerance), so for distributed systems, we can only consider how to choose consistency and availability when partition errors occur.

It should be emphasized that the choice between C and An occurs when there is a partition problem, and under normal circumstances, the system should have perfect data consistency and availability.

Example:

For example, we have a distributed system that consists of three nodes a, b, and c. Node a stores the data of table A, b stores the data of table B, and c stores the data of table C.

If there is a business whose intention is to insert a new piece of data into table A, delete an existing piece of data in table B and update an old piece of data in table C, how should the distributed system handle this kind of business?

Technically, we tend to package it as a transaction in a situation where we want to do more than one thing. When we are packaged as a transaction, we may return success by executing first on node a, then on node b, and finally on node c until all are successful.

But what happens when partitioning occurs? When nodes an and b are successful, it is found that there is a communication failure in c.

At this point, according to the CAP theorem, you have two choices, either directly return a partially successful result to the client, or simply jam and wait for the client to time out or return failure to the client. When the return is partially successful, this is when usability (A) is selected, and when the return fails to the client, consistency (C) is selected.

According to the choice of consistency and availability, open source distributed systems are often divided into CP systems and AP systems.

When a system has a partition failure, any request from the client is stuck or timed out, but each node of the system always returns consistent data, then the system is the CP system, such as Zookeeper.

If a system has a partition failure, the client can still access the system, but the data obtained is either new data or old data, then the system is AP system, such as Eureka.

Most of the time, consistency and usability are not a choice between the two. Most of the time, the system design will try to achieve two points as much as possible, and make a compromise between the two. when consistency is emphasized, it does not mean that usability is completely unavailable. For example, Zookeeper may be unavailable for dozens of seconds only when there is a problem with master, while other times, it will ensure the availability of the system in various ways. When emphasizing usability, some technical means are often used to ensure that the data is ultimately consistent.

Self-protection mechanism

The output warning of the Eureka home page is shown in the figure:

By default, if Eureka Server does not receive the heartbeat of the service instance within a certain period of time, Eureka will log out the instance (default is 90 seconds). However, when the network partition fails, the microservice client and Eureka Server cannot communicate properly. The above behavior can become particularly dangerous because the microservice itself is healthy and the service instance cannot be unregistered at this time.

Eureka solves this problem through self-protection mechanism. When Eureka Server loses too many service instances in a short time (network partition failure may occur), then Eureka Server enters self-protection mode. Once entering this mode, Eureka Server will protect the information in the service registry and no longer delete the data in the service registry (that is, no longer log out any service instances). When the network failure is restored, Eureka Server automatically exits self-protection mode.

To sum up, self-protection mode is a security measure to deal with network failures. Its architectural philosophy is that it would rather keep all micro-services at the same time than blindly cancel any healthy micro-services. Using self-protection mode can make Eureka more robust and stable.

Bottom line: when the client goes missing in a large area, the Eureka registry enters self-protection mode and does not log out any instances

Configuration of self-protection mechanism [understanding]

Configure the turn-off self-protection mechanism in Eureka Server

# disable self-protection mechanism and enable eureka.server.enable-self-preservation=false by default

If you want to eliminate failed eureka services in time, in addition to turning off the self-protection mechanism, you can lower the heartbeat value of eureka.

In the eureka-server server configuration file, we add the following configuration # shutdown protection mechanism to ensure that the registry correctly removes eureka.server.enable-self-preservation=false# from unavailable instances (for 5 seconds) (unit is millisecond, interval between cleaning up failed services) in the eureka.server.eviction-interval-timer-in-ms=5000 client configuration file, we add the following configuration # heartbeat detection detection and renewal time # set the value lower during the test to ensure that the registry can kick out the service in time after the service is turned off # configuration Note # lease-renewal-interval-in-seconds sends a heartbeat to the server every 10s Prove that you are still "alive" # lease-expiration-duration-in-seconds tells the server that if I don't give you a heartbeat within 20 seconds, it means I'm "dead" and kick me out. Eureka.instance.lease-renewal-interval-in-seconds=10eureka.instance.lease-expiration-duration-in-seconds=20Eureka cluster building

Registry cluster to prevent registry stand-alone failure.

Create a new registry eureka-server-8801

Create a project

Import dependency

Startup class annotations

Write configuration file

Modify the configuration file of registry Eureka-server-8800

Modify the configuration of all clients so that clients can register with both registries at the same time

Start all clients and registries to see if they can register properly

At this point, I believe you have a deeper understanding of "how to use Eureka". 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.