Spring Cloud Eureka Detailed description

Before learning how to configure Eureka registries, consumers, etc., for more details on some of the commonly used configurations are explained here.

1, the registration center of self-protection mode

When we debug Eureka's registry, visit the registry page and often see the following tips.

This hint indicates that the registry is now in protected mode, what is protected mode: Eureka Service after registering to the registry, will periodically send a heartbeat to the registry to prove that they are still alive, the registry during the run, will be counted within 15 minutes of the heartbeat failure ratio is less than 85%, if present, The registry enters protected mode, in which the registry does not remove the failed nodes, and the instances do not expire, and a prompt appears. Because the failure node is not removed in time, there may be an impossible instance in the list of services obtained by the client, which can be implemented through mechanisms such as client load balancing and fuses.

Self-protection mode is useful in real-world situations where the instance is actually available to prevent network problems caused by network partitioning or if the heartbeat renewal network is unstable, but the registry rejects it. For example, a instance in zone A, registry B, due to network failure, a instance cannot send a heartbeat to the registry in a timely manner, causing the registry to remove it, but the actual a instance is available at this time. Of course, the registry can also remove the non-renewal service by turning off the self-protection mode. eureka.server.enable-self-preservationTurn off self-protection mode with =false configuration. It is recommended that you turn on the self-protection mode unless you are asked to remove the failed instance in time. The service side can set the failure detection time period by eureka.server.eviction-interval-timer-in-ms=6000, in Ms.

The development environment can turn off the protection mode, the instance offline will be aware of in time, the production environment, you can open the protection mode, the service extension registry can immediately know that the service failure, should locate the problem and restart, if the need to remove the service, in the high-availability registry, you can restart the registration center, the failure node culling, and the consumer-side ribbon should configure the retry mechanism.

2, service provider's service renewal

Once the service provider registers itself with the registry, it needs to send a heartbeat through the cycle (default of 30 seconds), letting the registry know if it is still alive and preventing it from being removed by the registry, which typically has two configuration items to control.

Eureka.instance.lease-renewal-interval-in-seconds=30, control the heartbeat cycle interval time;

Eureka.ins Seven ance.lease-expiration-duration-in-seconds=90, control the time of service limitation, specify that the last heartbeat time is not renewed after 90 seconds, Then let the registry reject the instance (you need to turn off protected mode at the same time to get rid of expired nodes).

3, the service consumer inventory update cycle

When we start the service consumer, the consumer sends a REST request to the registry for a list of service instances. You need to make sure that eureka.client.fetch-registry=true, which indicates that you need to get the manifest.

Service consumers will periodically update the service list (default 30 seconds) or configure their own update cycles, which can be configured via eureka.client.registry-fetch-interval-seconds=60.

4. Service invocation

service calls we use the Ribbon, and by default we invoke the service by polling (in other ways there will be another article description). Here is the concept of region and zone, region roughly meaning is the center, a service can only belong to a region, defaults to default, to its own settings can be defined by eureka.client.region. Zone represents an area that is commonly used to implement configuration of instances of different network partitions and has achieved a load-balanced regional affinity. A region can contain more than one zone. The Defaultzone we configured earlier is the zone's default key value, so we can specify a zone. The so-called regional affinity, refers to the ribbon at the time of implementation, will give priority to access to the consumer in the same zone below the service instance, in the current zone does not exist instances to access other zone instances. The following is a simple configuration and description.

1. Service registries, service providers, and service consumers are required to configure the following content.

   Eureka:  client:    prefer-same-zone-eureka:true    region:chengdu    availability-zones:      Chengdu: Zone-1,zone-2    service-url:      zone-1: http://localhost:30000/eureka/      zone-2: http://localhost:30001/eureka/

   Eureka.client.prefer-same-zone-eureka=true indicates that the URL for the first zone configured in the available zone specified in Availability-zones will be registered. The service registry configures another registered Central address that is highly available in Service-url. Service providers and consumers can specify two registries in a single zone URL to make them highly available.

2. The service caller and provider have the following configuration, which specifies which zone to belong to. When the Ribbon consumer pulls the list of services from the registry, it matches the zone specified in the following configuration, giving priority to the same instance of zone.

   Eureka:  instance:    metadata-map:      zone:zone-1

Spring Cloud Eureka Detailed description