This is the 12th day of my participation in the First Challenge 2022
When we completed a simple microservice architecture, we observed the structure diagram and found a problem, that is, our Eureka Server occupies an important part of our entire service. If there is a problem with our Eureka Server, the whole service will be paralyzed
In order to solve this problem, we can make two Eureka Servers, which back up each other to ensure the reliability of our service
For convenience, we will only simulate two registries in one module
We only need to modify our YAML configuration to register the service on port 8000 with port 9000 and vice versa
Server: port: 9000 eureka: client: # register-with-eureka: false False # # whether information was obtained from the registry configuration exposed to address service registry request - url: defaultZone: http://127.0.0.1:8000/eureka/Copy the code
Server: port: 8000 Eureka: client: # register-with-eureka: false False # # whether information was obtained from the registry configuration exposed to address service registry request - url: defaultZone: http://127.0.0.1:9000/eureka/Copy the code
This is the configuration of our two services, they are only slightly different, in order to register with each other
Notice when we start the service, we’re using a module, we start one, and then we right click
Replication configuration, the new one service, we’ll go to modify our configuration file, to start another service, we will first start a service error, the problem is that we start the service, can’t find our another service (reason: we could go to start) when we start another service.
Viewing in a browser
Previously, our service was registered with only one service center, so do we need to register with two registries at the same time? The answer is no, once our two registries register with each other, the information in both registries is synchronized. You only need to register one
At this time, the problem comes again, if we only register one, if the registration of the registry error, then our service will not work, in order to ensure the security of our service, we still need to register our service to multiple registries, to ensure that our service can be safe and stable operation.
A few minor problems
IP address and service renewal time
Show the IP
We just need to modify it in our configuration file
eureka: client: service-url: defaultZone: http://localhost:9000/eureka/ instance: prefer-ip-address: true instance-id: ${spring.cloud.client.ip-address}:${server.port} # Register ID with the registryCopy the code
Whoever needs to display the IP modifies the configuration file
Eureka’s service culling problem
At the service provider, set heartbeat issues, set renewal expiration time
instance: prefer-ip-address: true instance-id: ${spring.cloud.client.ip-address}:${server.port} # Register ID lease-renewal-interval-in-seconds: ${server.port} # register ID lease-renewal-interval-in-seconds: 5 # Heartbeat interval lease-expiration-duration-in-seconds: 10 # Renewal expiration timeCopy the code
Self-protection mechanism
The Eureka server checks the normal heartbeat rate of all Eureka instances in the last 15 minutes and triggers the self-protection mechanism if it is lower than 85%. By triggering the protection mechanism, Eureka temporarily protects these failed services from expiration, but these services are not forever. Eureka checks the health status of services every 60 seconds after they are started, and removes them if they do not recover after a certain period of time (90 seconds by default). If the service is restored during this period and the instance heartbeat ratio exceeds 85%, the self-protection mechanism is automatically turned off.
Eureka: server: # Whether to enable self-preservation on the server (default true) enable-self-preservation: False # Scan interval for failed services 60 seconds eviction- interval-timer-in-MS: 2000Copy the code