Eureka Current Status: Eureka 1.x is currently being updated, but no new functionality is expected, only existing functionality is being maintained, upgraded and compatible with required dependencies. Eureka 2.x was stillborn. But that doesn’t mean Eureka is dead. If you need a registry that’s easy to deploy, Eureka is also a good choice. In a cloud service environment, virtually all instance addresses and micro-service names are constantly changing, and there is little need for the persistence features that Eureka lacks. If your cluster is small to medium size (less than 1000 nodes), Eureka is still a good choice. When your cluster is large, Eureka’s synchronization mechanism may limit its performance.

The design of Eureka

The design of Eureka is relatively small, there is no complex synchronization mechanism, there is no complex persistence mechanism, the cluster relationship is simply to receive client requests to other Eureka instances in the cluster. Eureka itself is also registrie-only, unlike other types of registries that combine registries and configuration centers, such as Consul and Nacos.

The interaction flow of Eureka is as follows:

First, Service A sends A Register to Eureka Server 1 via the Eureka Client in the same available zone. Then Renew the heartbeat request to this Eureka Server 1. When Eureka Server 1 receives these requests, These requests are processed and forwarded to Eureka Server 2 and Eureka Server 3 on the other cluster. Eureka Server 2 and Eureka Server 3 do not forward the received Eureka Server 1 Forward the request. Then, Service B and Service C get the location of Service A via Eureka, and finally call Service A.

For microservices not found locally, Eureka Server will also get them from Eureka Server of remote Region. For example, for Service D, it is not found locally. The Eureka Server returns an instance of Service D of the remote Region. Since Service A exists locally, an instance of Service A of remote Region is definitely not returned. In addition, local is the list of remote Region services pulled on a regular basis, and is not queried at the time of each query.

Typically, micro-services are called to each other, not through Eureka and not involving Eureka clients, but through a load balancer, which we will discuss later.

Eureka related concepts

We are ignoring all AWS related terminology and configuration and associated logical processing here.

Terms used in Eureka:

1. Eureka instances: Each instance registered on Eureka is an Eureka instance.
2. Eureka instance status: Includes UP (can handle request), DOWN (failed health check, unable to handle request), STARTING (in process, unable to handle request), OUT_OF_SERVICE (offline, not processing request), UNKNOWN (UNKNOWN state).
3. Eureka Server: Run as a registry, it mainly provides instance management function (handle instance register request, handle instance cancel request, handle instance heartbeat request, internal handle instance expiration (EVICT)), instance query function (various query instance information interface, Instance list via AppName, instance information via instance id, etc.)
4. Eureka server cluster: A cluster of Eureka servers. Each Eureka server is configured with zones and available zones. Client requests received by the Eureka server are forwarded to other Eureka servers in the same zone. Eureka servers that are not in the same region are synchronized by a timed pull.
5. Eureka client: The client that requests the Eureka server. Encapsulate and send instance register requests, instance cancel requests, and instance renew requests.
6. VIP (or Virtual Hostname): There are two ways to get instances in Eureka, one is by service name, and the other is by VIP. Each instance has a service name, along with a VIP. The index mode in Eureka server is the index of service name as key, we can also get the relevant instance through VIP string matching by traversing all the instance information. In the Spring Cloud architecture, an instance’s VIP, SVIP (Secure VIP) and service name are the samespring.application.nameThe name of the specified service.

Eureka related configuration

1. Eureka instance configuration: Eureka instance. Each instance registered on Eureka is an Eureka instance. The Eureka instance contains the following elements, along with the associated configuration:

   1. Basic information: Includes IP, port, and other information needed to access the Eureka instance:

      Eureka: instance: # The EurekainStanceconfigBean constructor will retrieve the IP address #ip-address from inetUtils. The EurekainStanceconfigBean constructor will retrieve the hostname from inetUtils. Prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address: prefer-ip-address # Use server.port as non-security-port automatically instead of setting non-security-port # If secure-port-enabled is true, server.port is automatically used as secure-port; Secure-port: # Secure-port: # Secure-port: # Secure-port: # Non-secure-port-enabled: SSL secure-port-enabled: false # Personalize the instance ID, including IP: microservice name: port instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port} # The default is spring.application.name appname: Spring-cloud-Netflix ${spring.application.name} # app-group-name: common # namespace: public? # app-group-name: common #

   2. Basic link information: including home page path address and health check path address:

      / Actuator/Health Health -Check-Url-Path: 1. Actuator/Health Health -Check-Url-Path: 1. Actuator/Health -Check-Url-Path: 1. / Actuator/Health # : / Actuator/Info # status-page-url-path: / home-page-url-path: /

   3. Instance registration behavior, that is, the behavior after the instance is registered, and configuration such as heartbeat interval:

      eureka: instance: Service expiration time configuration, after this time does not receive a heartbeat Eurekaserver will exclude this instance Eurekaserver must be set eureka.server.eviction-interval-timer-in-ms otherwise this configuration is invalid # this configuration is generally three times the server refresh time configuration # default 90s Lease-expiration-during-in-seconds: 15 # service refresh time configuration, with an active heartbeat every 30 seconds, default 30 seconds lease-renewal-interval-in-seconds: 5 Registry: # please refer to wait - time - - - the when - sync - ms in the empty configuration instructions default - open - for - traffic - count: 1 # Number of instances expected to send a heartbeat request. Default is 1, +1 for new instance registration, -1 for logout. Initial defaults to 1 generally because they are registered to had been expected - number - of - clients - sending - renews: The default is false. Generally, some operations need to be done after registration, so the state of the registered instance is STARTING/STARTING. Up instance-enabled-onit: false when the state is changed

   4. Instance metadata:

      Eureka: instance: # Metadata Map. You can use this map by yourself and put some personalized metadata in it. Currently, only configPath and zone are useful. ConfigPath is using spring - cloud - config will be set when the metadata - map: # spring cloud system, the configuration in the metadata are available, and the key for the zone zone: zone1

2. Eureka client configuration:

   1. Eureka server address configuration, can specify the link directly, can be configured through region and zone, can be configured through DNS:

      Zones: region1: zone1, zone2 region2: zones: region1: zone1, zone2 region2 Zone3 # is located in a zone that is read availability-zones, And then reading service - from the zone url to obtain the corresponding eureka url # corresponding class is the logic ConfigClusterResolver and ZoneAffinityClusterResolver region: Region1 # key for the zone, the value of eureka links, comma-separated service - url: EurekAclientConfigBean DefaultZone is the default cluster in the EurekAclientConfigBean. The default cluster in the Eureka ConfigBean is DefaultZone. http://127.0.0.1:8211/eureka/ zone1: http://127.0.0.1:8212/eureka/ zone2: http://127.0.0.1:8213/eureka/ zone3: http://127.0.0.1:8214/eureka/ # if eureka server address configuration updates related to the above, how long will read again after perceived eureka - service - url - poll interval - seconds: If so, use the following DNS configuration instead of the service-url use-dns-for-fetching-service-urls above: # eureka-server-port # eureka-server-port # eureka-server-port # eureka-server-port # eureka-server-u-r-l-context # eureka-server-u-r-l-context # eureka-server-u-r-l-context If set to true, eureka in the same zone will go first. Default is true prefer-same-zone-eureka: true

   2. Pull service instance information related configuration:

      Eureka: instance: # Fetch-Registry: True # If you only want to get a list of instances of a specific virtual host name, configure register-refresh -single-VIP-address # register-refresh -single-VIP-address: The client request header specifies whether the instance information returned by the server is compressed or complete. The default is full information. Full # Eureka client refresh local cache time # 30s by default registry-fetch-interval-seconds: 5 # Eureka client Refresh local cache (periodically pull the list of Eureka instances) thread pool size, default is 2 cache-refresh-executor-thread-pool-size: 2 # Eureka Client flashes the local cache (regularly fetch the list of Eureka instances) and the maximum delay time of the thread pool task. This configuration is a multiple of the time delay of the timed fetch task (Registry -fetch-interval-seconds). Default: 10x cache-refresh -executor-optional -back-off-bound: 10 # Disables the incremental pull, which can be disabled if the network condition is not good, and disable the full amount of disable-delta: False # Fetch-remote-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries: Fetch-registries; Log-delta-diff: If you want to log each pull and the current instance in the cache True # In the Spring Cloud environment, DiscoveryClient uses a compositeDiscoveryClient. The compositeDiscoveryClient logic is composed of multiple DiscoveryClients, one of which is accessed first, and the next one is searched if it is not found. The # order determines the order, which defaults to 0 order: 0

   3. Current instance registration related configuration:

      Eureka: instance: # register yourself with eureka: register with eureka # If you want to use eureka as your server, set it to "false" because the instance is not available by using the public enforcement-at-init method. False # Whether or not to log off an instance when it is closed, default to true should-unregisterer-on-shutdown: True # Whether to limit the flow of instance status change updates, default to true on-demand-update-status-change: true # The amount of time between the instance information and the timing synchronization to the Eureka Server. At such intervals, check the instance information (i.e., eureka.instance configuration information) to see if there is any change. If there is any change, then synchronize to the eureka Server. Instance-info-replication-interval-seconds: "Instance-info-replication-interval-seconds"; Default: 40s initial-instance-info-replication-interval-seconds for instance information to be synchronized to Eureka Server at the same time

   4. HTTP connection configuration:

      Eureka: instance: # proxy-host: # proxy-port: # proxy-user-name: # proxy-password: HTTP request to Eureka Server with gzip enabled is currently expired. As long as the Eureka Server has gzip enabled, the request is gzip-compressed. G-Zip-content: Default 5S eureka-server-connect-timeout-seconds: eureka-server-connect-timeout-seconds: 5S eureka-server-read-timeout: Eureka-server-read-timeout = 5S eureka-server-read-timeout = 5S eureka-server-read-timeout = 5S eureka-server-read-timeout: (30 seconds) eureka-connection-idle-timeout-seconds (30 seconds) : 30 # total number of HttpClient connections, default 200 eureka-server-total-connections: Eureka-server-total-connections -per-host: 50 # TLS-related configuration, not enabled by default # TLS: # enabled: false # key-password: # key-store: # key-store-password: # key-store-type: # trust-store: # trust-store-password: # trust-store-type:

3. Eureka server configuration:

   1. When an instance is registered, it needs to send a heartbeat to prove that the instance is alive. There is also a timer task in the Eureka server to check if the instance has expired:

      Eureka: server: # The interval between tasks used to actively check if a service instance is invalid. Default is 60s evictionary-interval-timer-in-ms: This configuration is used in two places: # If self-protection is enabled, then whether the number of heartbeat requests received within the specified period of time of renewal-threshold-update-interval ms is less than the number of instances multiplied by the renewal-percent-threshold # timing task checks for expired instances. At most, an instance of this number of percentages expires 1-renewal-percent-threshold at a time: 0.85

   2. Self-protection related configuration: Eureka server has expired tasks, check for delayed heartbeat instances, and log them out. Self-protection is mainly for the network problems in the cluster, resulting in many instances can not send heartbeat and many instances of abnormal state, but the actual instances are still working normally, do not let these instances not participate in the load balancing situation:

      Eureka: Server: # Note that it is best that all client instances are configured with the same heartbeat time relative to the configuration. This is the most accurate way to use the self-protection feature. # Close Self-protection # We do not use self-protection here because: # to protect themselves mainly in view of the problems in the cluster network, in which there are many instances not send abnormal heartbeat has caused many instance state, but the actual instance in the case of normal work, also don't let these instances do not participate in load balancing # enabled under the condition of self-protection, expired # but will stop for instance, if appear this kind of circumstance, This means that many instances cannot read the registry. There is also a case where Eureka is rebooted. It is not common, but updates to other components in the image are very frequent. I prefer to solve this problem by using the instance cache mechanism on the client side. If the returned instance list is empty, then load balancing will be performed using the last instance list, which will not only solve the case of Eureka restart. The self-protection mode is based on the number of renew (instance heartbeat) requests received per minute. If the self-protection mode is enabled, only the number of renew received in the last minute is greater than this value. Enable-self-preservation Enable-self-preservation: False # The number of renew (instance heartbeat) requests to be received per minute needs to be dynamically refreshed. The refresh interval is renewal -thresholds-update-interval-ms # update process is approximately as follows: Calculate the current number of instances. If it is greater than the previously expected number of instances * renewal-percent-threshold (or no self-protection mode is turned on), update the expected number of instances to the current number of instances #. Calculate the expected number of instance heartbeat requests to be received = the expected number of instances * (60 / Expected Client-Renewal-Interval-Seconds) * Renewal-Percent-Threshold # 60 represents one minute in the formula, Because the formula uses Expect-Client-Renewal-Interval-Seconds, or the average instance heartbeat interval, to make it accurate, # Defaults 900000ms = 900s = 15min Renewal-Threshold -Update-Interval -ms: 900000 # The above mentioned average heartbeat interval, or expected heartbeat interval, for this formula to be accurate, it is best to configure the same heartbeat time for each instance # Default 30s expected-client-renewal-interval-seconds: 30 # This configuration is used in two places: # If self-protection is enabled, then whether the number of heartbeat requests received within the specified period of time of renewal-threshold-update-interval ms is less than the number of instances multiplied by the renewal-percent-threshold # timing task checks for expired instances. At most, an instance of this number of percentages expires 1-renewal-percent-threshold at a time: 0.85

   3. Cluster configuration in the same region: As mentioned above, client requests received by Eureka server instances in the same region are forwarded to other Eureka server instances in the same region. At the same time, when an Eureka server instance is started, the instance list is synchronized from other Eureka servers in the same region. Also, forwarding to other Eureka server instances is asynchronous, so there is a dedicated thread pool for forwarding. At the same time, the forwarding is also HTTP request, which requires HTTP connection pooling:

      Eureka: server: # eureka server updates the list of other eureka server instances in the same area from the configuration interval, default 10 minutes peer-eureka-nodes-update-interval-ms: The maximum number of retries to synchronize service instance information from other Eureka servers on startup until the number of instances is not 0. This defaults to 0. This does not synchronize Registry -sync-retries: 0 # Retry interval register-sync-retry-wait-ms from other Eureka Server to synchronize service instance information on startup: The number of at least UP Eureka Server instances in the cluster. The current status of Eureka Server is UP. The default is -1, which means that the Eureka Server status does not take into account the number of other Eureka servers in the UP cluster. The maximum timeout required for a task in the same instance as for other instances of replication. The default is 30 seconds for max-time-for-replication: The number of threads used to handle synchronization tasks. There are two thread pools, one for batch synchronization tasks. The default size is 20 max-threads-for-peer-replication: The default size is 20 max-threads-for-status-replication, which handles non-batch tasks (not useful without the AWS Autoscaling feature) : The queue length of the thread pool for processing batch tasks, default is 10000 max-quota-in-peer-replication-pool: The queue length of the thread pool for processing non-batch tasks. The default is 10000 max-quota-in-status-replication-pool: #Eureka Server is using HttpClient to access a synchronization instance of another Eureka Server. The connection to HttpClient is timed out by 200ms peer-node-connect-timeout-ms: Peer-Node-read-Timeout-ms: Peer-Node-read-Timeout-ms: Peer-Node-read-Timeout-ms: Peer-Node-read-Timeout-ms: Peer-Node-read-Timeout-ms: 200 # HttpClient maximum number of total connections, default 1000 peer-node-total-connections: Default: 500 peer-node-total-connections-per-host: default: 500 peer-node-total-connections-per-host: 500 # HttpClient: default 30s peer-node-connection-idle-timeout-seconds: 30

   4. Cross-region correlation configuration. The Eureka server periodically pulls the list of service instances from other regions and cages them locally. When a local query fails to find a microservice, the cache of the remote locale service instance is queried. The relevant configuration is as follows:

      Eureka: server: # Request HttpClient of another Region to timeout, default: 1000ms remote-region-connect-timeout-ms: (1) Remote region-read-timeout (1) Remote region-read-timeout (2) Remote region-read-timeout (3) Remote region-read-timeout (3) Mysql > request the maximum total number of HttpClient connections from other regions, default to 1000 remote-region-total-connections: Set the default value of 500 remote-region-total-connection-per-host: Default 30s remote-region-connection-idle-timeout-seconds: This is the default 30s remote region-connection-idle-timeout-seconds. 30 # requests whether to open gzip in the HTTP request of other regions. For other regions, we think that the network connection is slow, so open compressed g-zip-content-remote-region by default: true # remote-region-urls-with-name: # region2eureka1: http://127:0:0:1:8212/eureka/ # region2eureka2: http://127:0:0:1:8213/eureka/ # remote-region-app-whitelist: Default to 30s remote-region-registrie-fetch-interval for instance data from other regions: The default thread pool for this task is 20 remote-region-fetch-thread-pool-size: 20, if you need to fetch instance information from another Region

Start an Eureka Server

Starting an Eureka registry server is simple, using the Spring Cloud packaged startup package. Eureka 1.x Eureka Server is a pure servlet-based application. To work with the Spring Cloud, you need to glue the module, which is spring-cloud-Netflix-eureka-server. In the spring — cloud – netflix – eureka – server, there is also a and com.net flix. Eureka. EurekaBootStrap code is very similar to start the class, The org.springframework.cloud.net flix. Eureka. Server. EurekaServerBootstrap. When we start the Eurekaserver instance, we simply add the dependency for spring-cloud-starter-eureka-server. An Eureka server instance can then be started with the @EnableEurekaserver annotation.

Eureka Server dependencies:

pom.xml

<? The XML version = "1.0" encoding = "utf-8"? > < project XMLNS = "http://maven.apache.org/POM/4.0.0" XMLNS: xsi = "http://www.w3.org/2001/XMLSchema-instance" Xsi: schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" > < the parent > < artifactId > spring - cloud - iiford < / artifactId > < groupId > com. Making. Hashjang < / groupId > < version > 1.0 - the SNAPSHOT < / version > < / parent > < modelVersion > 4.0.0 < / modelVersion > < artifactId > spring -- cloud - iiford - eureka - server < / artifactId > < dependencies > <dependency> <groupId>com.github.hashjang</groupId> <artifactId>spring-cloud-iiford-service-common</artifactId> <version>${project.version}</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-netflix-eureka-server</artifactId> </dependency> </dependencies> </project>

Eureka Server Configuration: Refer to our configuration above: Application.yml

Eureka Server startup categories: EurekaServerApplication. Java

package com.github.hashjang.iiford.eureka.server;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}