Eureka learning and quick use

1. What is it

When talking about Eureka, we should first understand service governance.
spring cloud encapsulates the Eureka module developed by Netflix to realize service governance. In the traditional rpc remote invocation framework, it is complex to manage the dependency relationship between each service and service, and the management is complex. All need to use service governance to manage the dependency relationship between services, which can realize service invocation, load balancing, fault tolerance, etc., and realize service registration and discovery. In a word, Eureka is the implementation of service governance, which is responsible for managing the dependencies, calls, fault tolerance, etc. between various services.

2. Principle architecture

Eureka adopts the design architecture of CS. Eureka Server is the server of service registration function, and it is the service registration center. Other microservices in the system use Eureka's client to connect to Eureka Server and maintain heartbeat connection. In this way, the maintenance personnel of the system can monitor whether each micro service in the system is running normally through Eureka Server. In service registration and discovery, there is a registry. When the server starts, it will register its current server information, such as service address and mailing address, in the registration center in the form of alias. The other party (consumer | service provider) uses this alias to obtain the actual service communication address from the registry, and then implements local RPC calls. The core design idea of the RPC remote call framework lies in the registry, because the registry is used to manage a dependency between each service and the service (service governance concept). In any RPC remote framework, there will be a registry (storing service address related information (interface address)).

Eureka's two components:
1.Eureka Server provides service registration service
After each micro service node is started through configuration, it will be registered in EurekaServer. In this way, the service registry in EurekaServer will store the information of all available service nodes, and the information of service nodes can be seen intuitively in the interface.
2.EurekaClient accesses through the registry
It is a java client to simplify the interaction of Eureka Server. The client also has a built-in load balancer using polling load algorithm. After the application starts, it will send a heartbeat to Eureka Server (the default cycle is 30 seconds). If Eureka Server does not receive the heartbeat of a node in multiple heartbeat cycles, Eureka Server will remove the service node from the service registry (the default is 90 seconds).

3. Single Eureka fast build

Step 1: build Eureka Server-side registry in your own project
1.idea construction project

2. Import jar package

<!--eureka server end-->

3. Configuration yml file

  port: 7001

    hostname: localhost  #eureka server instance name
    #false means that you do not register yourself with the registry
    register-with-eureka: false
    #It means that my client is the registry. My responsibility is to maintain instances without retrieving services
    fetch-registry: false
      #defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka
      #Stand alone version, pointing to yourself
      defaultZone: http://localhost:7001/eureka

4. Add @ EnableEurekaServer annotation to the main startup class

public class EurekaMain7001 {
    public static void main(String[] args) {, args);

5. Test whether Eureka Server is successfully built (start the service, localhost:7001 test)

Step 2: register other services (Eureka Client) into Eureka Server
1. Add jar package

<!--eureka client-->

2. Modify yml file

  port: 8000

    name: cloud-order-service

    #Indicates whether to register yourself with EurekaServer. The default value is true
    register-with-eureka: true
    #Whether to retrieve the existing registration information from EurekaServer. The default value is true. Single node doesn't matter. The cluster must be set to true to use load balancing with the Ribbon
    fetch-registry: true
      defaultZone: # stand alone

3. Add annotations to the main startup class and start the service

public class OrderMain80 {
    public static void main(String[] args) {,args);

4. Enter the web interface of Eureka Server again

4.Eureka's self-protection

![Insert picture description here](,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h4eHh1NTgxMQ==,size_16,color_FFFFFF,t_70)
Protection mode is mainly used for a group of clients and users Eureka Server There is protection in the network partition scenario.**Once in protected mode, Eureka Server It will try to protect the information in its service registry and will not delete the data in the service registry, that is, it will not log off any microservices**. By default, if EurekaServer The heartbeat of a service instance is not received within a certain period of time, EurekaServer The instance will be unregistered (90 seconds by default). However, the network partition failure (delay, jam, congestion) is caused by the microservice and EurekaServer The above behaviors may become very dangerous because the micro service itself is actually healthy. At this time, the micro service should not be cancelled. Eureka Solve this problem through "self-protection mode", when EurekaServer When a node loses too many clients in a short time (network partition failure may occur), the node will enter the self-protection mode.

How to prohibit self-protection:
1.Eureka Server side
By default, the self-protection mechanism is enabled
eureka.server.enable-self-preservation: true
Use Eureka server. Enable self preservation: false to disable the self-protection mode

		enable-self-preservation: false  #Turn off self-protection mode

2.Eureka Client
Modify the time interval of Eureka client sending heartbeat to the server (the default is 30 seconds) 1
Modify the upper limit of waiting time of Eureka server after receiving the last heartbeat (the default is 90 seconds). The timeout will eliminate the service eureka.instance.leave-expiration-duration-in-seconds: 2

		#The time interval between Eureka client sending heartbeat to server (30 seconds by default)
		lease-renewal-interval-in-seconds: 1
		#The maximum waiting time of Eureka server after receiving the last heartbeat (the default is 90 seconds), and the service will be rejected when it times out
		lease-expiration-duration-in-seconds: 2

Added by webaddict on Sun, 02 Jan 2022 21:01:05 +0200