Eureka profile

Eureka is an open source service registration discovery tool for Netflix, which provides services based on the REST protocol. Also added to the Spring Cloud subproject. This article introduces the Quick use of Eureka based on SpringBoot, as well as the description of Eureka components and related configurations.

Eureka service role

Each Eureka service is an instance. An instance has two roles in Eureka: Eureka Server and Eureka Client

  • Eureka Server: The registry itself, which is responsible for listening and maintaining Eureka client-related information. For example, adding and exiting hosts
  • Eureka Client: Divided into two types,Service ProviderandService Consumer
    • Service Provider: the Service Provider performs registration, renewal, and login and logout operations on the Eureka Server
    • Service Consumer: A Service Consumer that invokes a list of services from Eureka Server (updated periodically)

Of course, these roles are not absolute, but a logical classification. An instance can be both Provider and Service

Eureka architecture

Eureka is easy to use

I’m not going to build a single node here, I’m going to build a pseudo-cluster. Start a SpringBoot project and introduce the following dependencies in POM.xml

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
Copy the code

Add @enableeurekaserver annotation to the startup class:

@SpringBootApplication
@EnableEurekaServer
public class EurekaApplication {

    public static void main(String[] args) { SpringApplication.run(EurekaApplication.class, args); }}Copy the code

To establish application – v1. The properties, application – v2. The properties, application – v3. Content of the properties are:

spring.application.name=eureka-server
server.port=7001
eureka.instance.hostname=peer1
eureka.client.service-url.defaultZone=http://localhost:7002/eureka/,http://localhost:7003/eureka/
Copy the code
spring.application.name=eureka-server
server.port=7002
eureka.instance.hostname=peer1
eureka.client.service-url.defaultZone=http://localhost:7001/eureka/,http://localhost:7003/eureka/
Copy the code
spring.application.name=eureka-server
server.port=7003
eureka.instance.hostname=peer1
eureka.client.service-url.defaultZone=http://localhost:7001/eureka/,http://localhost:7002/eureka/
Copy the code

As you can see, the difference is just ports. For example, port 7001 serves as the Eureka Server and also serves as the Client of The Eureka Server on ports 7002 and 7003, thus creating a Eureka cluster

Project into jar package, execute respectively

Java -jar eureka-0.0.1 -snapshot.jar -- spry.profiles. Active =v1 & java-jar eureka-0.0.1 -snapshot.jar Active = v2&java -jar eureka-0.0.1- snapshot.jar -- spry.profiles. Active = v3&Copy the code

To start the project, visit localhost:7001 and see:

The Eureka-Server service has been registered with three nodes. The Eureka cluster is now set up, but this is just a very simple Demo

Eureka related parameters and processes

First Registration

When a Service Provider registers with the Eureka Server for the first time, it sends its information to the Eureka Server, including the Service name, IP address, and port number. Eureka Server receives this information and writes it to its cache

The Service Consumer pulls the list of services from the Eureka Server at a certain frequency (full for the first time, incremental for the next). Once it gets the list of services, Select an instance from a list of services to send a request using a specific method (the Ribbon uses polling for client load balancing, for example)

Configuration:

Eureka Server: spring.application. eureka-service eureka.client.serviceUrl.defaultZone=http://localhost:7002/eureka/,http://localhost:7003/eureka/ # Register-with-eureka: true # Register with Eureka Server trueCopy the code

The heartbeat detection

Provider

The Eureka Server checks the real-time status of the Provider by heartbeat detection. The default heartbeat detection frequency is 30 seconds. When Eureka Server receives a heartbeat packet, a renewal is performed. If the corresponding service status changes (for example, a machine goes offline, or a new machine is added), the update is written to a “lease Change queue” for subsequent comSumers to pick up

How does Eureka Server know if an instance is offline? If Eureka Server does not receive a heartbeat packet for an instance within 90 seconds, the instance is considered offline and this record is updated to the Lease Change queue

In fact, a Client can be offline in two cases. One is that a Client is offline normally. Before being offline, the Client notifies the Eureka Server of the message. The other is abnormal offline, such as process crash, outage, network exceptions, etc. In this case, Eureka server does not receive heartbeat packets within 90 seconds, the instance is considered offline

Lease -renewal-interval-in-seconds: 30 # How long does the Eureka server receive no heartbeat message? If the eureka server receives no heartbeat message, the instance is expired, in seconds. eureka.instance.lease-expiration-duration-in-seconds: : 90sCopy the code

Consumer

The communication between the Consumer and Eureka Server is mainly to obtain a list of services for consistency. When a Consumer first connects to the Eureka Server, a full fetch is performed, followed by incremental fetch every 30 seconds. Where does the incremental fetch information come from? Remember that “lease change queue” we talked about earlier? In effect, the Eureka Server retrieves the information from the queue and synchronizes it

Of course, in this process, because the synchronization time is 30s, information inconsistency may occur in 30s. Of course, for most clients, this inconsistency is not a huge problem, because it is impossible to do without retry. If there is a real need for greater consistency, this can be reduced, but it also means that the Consumer mentality becomes more frequent, which may lead to some additional network overhead, which needs to be noted. And no matter how short that time is, there is bound to be inconsistency. And Eureka implements AP instead of C (strong consistency), so there’s no need to set the frequency too fast in this regard

The default value is true. Eureka.client.fetch -registry: Default: 30 seconds eureka.client. registrie-fetch -interval-seconds Eureka. DisableDelta: false specifies whether to disable incremental access to service instance registration information. If this parameter is set to true, eurekaCopy the code

Self-protection mechanism

Consider this situation: The network communication between the Eureka Server and the Provider fails, but the Provider is still running and still serving the Consumer. However, because the heartbeat packets it sends cannot reach the Eureka Server, the Eureka Server thinks that it is offline and removes the service from the service list. In this way, when consumers get the new service list, they mistakenly think that the Provider service is unavailable, which leads to some problems

Self-protection mechanisms are designed to solve this problem. When the number of heartbeat packets received by The Eureka Server is less than one threshold in a minute, the Eureka Server starts to protect itself. In this state, the Eureka Server does not remove instances from the service list (so the list may have expired instances, which are still sent to consumers). When the number of received heartbeat packets reaches the threshold, the system exits the self-protection state.

# Whether to enable self-protection mode. Eureka.server. enable-self-preservation: false # Enable the self-preservation mode proportion threshold. When the ratio of received heartbeat packets to the expected heartbeat packets is lower than the threshold, the system enters the self-preservation mode. Eureka. Server. Renewal -percent - threshold: 0.85Copy the code