Current status of Eureka: Eureka is currently being updated to version 1.x, but there should be no new features, just maintenance of existing features, upgrades and compatibility with required dependencies. Eureka 2.x is stillborn. But that doesn’t mean Eureka isn’t working. If you need a registry that is simple and easy to deploy, Eureka is also a good choice. In a cloud service environment, where virtually all instance addresses and microservice names are constantly changing, there is little need for the persistence features that Eureka lacks. Eureka is still a good choice when your cluster is small to medium size (less than 1000 nodes). When your cluster is large, Eureka’s synchronization mechanism may limit its performance.

The design of Eureka

Eureka is small in design and has no complex synchronization mechanism, nor complex persistence mechanism. The cluster relationship simply forwards the received client requests to other Eureka instances in the cluster. Eureka itself also only functions as a registry, unlike other types of registries that combine registry and configuration centers, such as Consul and NACos.

Eureka’s interaction flow is as follows:

First, Service A sends A Register request through Eureka Client to Eureka Server 1 in the same availability area. Renew Eureka Server 1 by sending a heartbeat request to Renew the request. These requests are processed and forwarded to Eureka Server 2 and Eureka Server 3 in other clusters. Eureka Server 2 and Eureka Server 3 do not forward the received Eureka Server 1 A forwarded request. Service B and Service C then use Eureka to get the location of Service A and call Service A.

For microservices that are not queried locally, the Eureka Server obtains them from the Eureka Server of the remote Region. For example, Service D is not queried 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 the remote Region will not be returned. In addition, the local Region is the Service list of the remote Region that is pulled periodically. The local Region is not queried every time.

In general, microservices are called to each other, not through Eureka and not involving the Eureka client, but through the load balancer, which we’ll talk about later.

Eureka related concepts

We ignore all AWS terminology and configuration and logic here.

Terminology in Eureka:

  1. Eureka instance: Every instance registered to Eureka is an Eureka instance.
  2. Eureka instance status: UP (available to process requests), DOWN (unable to process requests due to health check failure), STARTING (unable to process requests due to STARTING), OUT_OF_SERVICE (offline), UNKNOWN (UNKNOWN status).
  3. Eureka server: As a registry, it mainly provides instance management functions (processing instance registration request, processing instance cancellation request, processing instance heartbeat request, internal processing instance expiration request), instance query functions (various interface for querying instance information, For example, get instance list by AppName, instance information by instance ID, etc.)
  4. Eureka server cluster: a cluster of Eureka servers. Each Eureka server is configured with an area and an availability zone. Client requests received by the Eureka server are forwarded to other Eureka servers in the same area. Eureka servers in different areas are synchronized by timed pull.
  5. Eureka client: The client that requests the Eureka server. Encapsulate send instance register request, instance cancel request, and instance heartbeat Renew request.
  6. VIP (or Virtual Hostname): There are two ways to get instances in Eureka, one by service name and the other by VIP. Each instance has a service name, and a VIP. The index method in Eureka server is the key index of the service name. We can also get related instances through VIP string matching by traversing all instance information. In Spring Cloud, an instance’s VIP, SVIP (Secure VIP), and service name arespring.application.nameSpecifies the name of the service.

Eureka configuration

  1. Eureka instance configuration: Eureka instances. Each instance registered to Eureka is an Eureka instance. The Eureka instance contains the following elements and associated configurations:
  2. Basic information: including IP, port and other information needed to access the Eureka instance:
The constructor of the eureka: instance: eureka: instance: eureka: instance: The EurekaInstanceConfigBean constructor will fetch hostname from InetUtils. # to register had been above for the other instance access IP address used for registration, other instances will be accessed via IP -- - IP address: - #non-secure-port = non-secure-port #non-secure-port = non-secure-port # if secure-port-enabled is true, server.port is automatically used as secure-port; Secure-port: non-secure-port: non-secure-port: non-secure-port: non-secure-port: non-secure-port: non-secure-port: non-secure-port: non-secure-port: non-secure-port [instance-id] [instance-id] [instance-id] [instance-id] ${spring.cloud.client.ip-address}:${spring.application. Name}:${server.port} # app name, Spring.application. Name AppName: ${spring.application. Name} # app-group-name: common # namespace: publicCopy the code
  1. Basic link information: Home page path and health check path:
IP address of the actuator in the zone using the same IP address as that in the zone using the same IP address as that in the zone using the same IP address as that in the zone using the same IP address as that in the zone using the same IP address /actuator/health # indicates the IP address of the device. The default is /actuator/info status-page-url-path: /actuator/info # indicates the IP address of the device. The default is /home/page-url-path: /Copy the code
  1. Instance registration behavior, that is, the behavior after instance registration, and heartbeat interval configuration:
eureka: instance: EurekaServer will reject this instance if no heartbeat is received after this time. EurekaServer must be set eurekag.server. Eviction -interval-timer-in-ms, any configuration will be invalid. The configuration is designed to be three times the configured service refresh time Lease -expiration-duration-in-seconds: 15 # Configure the service refresh time, at which the active heartbeat will be performed at this interval. # default 30s lease-renewal-interval-in-seconds: 5 registry: Default-open-for-traffic-count: wait-time-in-ms-when-sync-empty: 1 # The initial number of instances expected to send heartbeat requests. The default value is 1, +1 when a new instance is registered and -1 when a new instance is unregistered. Expected -number-of-clients-sending-renews: The default value is false. The default value is "STARTING". After the status changes, it will be changed to UP instance-enabled-onit: falseCopy the code
  1. Instance metadata:
Eureka: instance: # metadata map, we can use it ourselves, put some personalized metadata, currently only configPath and zone are useful. Metadata-map: # Spring Cloud configPath: metadata-map: # Spring Cloud configPath: Metadata-map: # Spring Cloud configPathCopy the code
  1. Eureka client configuration:
  2. You can configure the Eureka server address by directly specifying the link, region, zone, or DNS:
Eureka: instance: # List of available zones. Key is region and value is zone availability- Zones: region1: zone1, zone2 region2: Zone3 # fetch zone from 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 = zone, value = eureka, service-url = service-url EurekaClientConfigBean defaultZone = EurekaClientConfigBean (); 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: 300 # Whether to fetch fetch from DNS or not, if this is the case then fetch from DNS configuration instead of service-url use-dns-for-service urls: # eureka server port # eureka server port # eureka server port Context # eureka-server-u-r-l-context # eureka-server-u-r-l-context If set to true, eureka in the same zone will run first. Default: true prefer-same-zone-eureka: trueCopy the code
  1. Configurations related to pull service instance information:
Eureka: instance: True #registry refresh- single-VIP-address = registry refresh- single-VIp-address = registry refresh- single-VIp-address The client request header specifies whether the instance information returned by the server is compressed or complete. The default is complete. Default 30s registry-fetch-interval-seconds: Cache-refresh -executor-thread-pool-size = 2; 2 # Maximum delay time for eureka client to refresh the local cache (timed fetch eureka instance list) thread pool task. This configuration is a multiple of registry-fetch-interval-seconds. Default value: 10x cache-refresh-executor-exponential-back-off-bound: 10 #fetch-remote- registries-registry = true #fetch-remote- registries-registry = true Log-delta-diff: log-delta-diff: log-delta-diff: True # In the Spring Cloud environment, DiscoveryClient uses a CompositeDiscoveryClient, The CompositeDiscoveryClient logic is composed of multiple DiscoveryClients, which are accessed first and then searched for the next one. The order determines the order, which defaults to 0 order: 0Copy the code
  1. Current instance registration configuration:
Eureka: instance: # Register with eureka Set this parameter to false because the instance is not available yet: shoulder-registration-at-init The default value is true: should-unregister-on-shutdown The default value is true on-demand-update-status-change: true # Specifies the interval between instance information and scheduled synchronization to the Eureka Server. Every so long, check whether the instance information (i.e. eureka. Instance configuration information) has changed. If it has changed, it will be synchronized to eureka Server. Instance-info-replication-interval-seconds: 40 40 initial-instance-info-replication-interval-seconds: 40Copy the code
  1. HTTP connection configuration:
Eureka: instance: # proxy-host: # proxy-port: # proxy-user-name: # proxy-password: Gzip is a gzip compressed g-zip-content for HTTP requests sent to Eureka Server. Eureka-server-connect-timeout-seconds eureka-server-connect-timeout-seconds eureka-server-read-timeout-seconds Eureka-connection-idle-timeout-seconds = 30 seconds eureka-connection-idle-timeout-seconds Eureka-server-total-connections: Eureka-server-totals-connections-per-host: 50 # TLS: enabled false # key-password: # key-store: # key-store-password: # key-store-type: # trust-store: # trust-store-password: # trust-store-type:Copy the code
  1. Eureka server configuration:
  2. The Eureka server also has a scheduled task to check whether the instance has expired:
Eureka: server: / / eureka: server: / / eureka: server: / / eureka: server: / / 3000 # This configuration is used in two places: If self-protection is enabled, whether the number of received heartbeat requests within the specified period of time is less than the number of instances times the std-threshold-update-interval-ms The maximum expiration time is 1-stD-Percent-threshold For instances of this number of proportions, stD-Percent-threshold: 0.85Copy the code
  1. Self-protection configuration: Eureka server has scheduled expiration tasks, check the instances that do not have heartbeat, and deregister them. Self-protection refers to the situation that many instances cannot send heartbeat messages and are abnormal due to network faults in the cluster. However, actual instances still work properly. Do not exclude these instances from load balancing.
Eureka: server: # Note that it is desirable that all client instances are configured with the same heartbeat time-dependent configuration. This is the most accurate way to use the self-protection feature. We don't 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, It also means that many instances cannot read the registry. There is also a case where Eureka restarts. I prefer to use the client-side instance caching mechanism to solve this problem. If the returned instance list is empty, the last instance list is used for load balancing. This can not only solve the Eureka restart situation, but also solve the problem of the Eureka restart. Based on the number of renew requests received per minute, if self-protection mode is enabled, only the number of renew requests received in the last minute is greater than this value. The instance will be deregistered only when it expires. False # Renew requests received every minute need to be renewed dynamically. The update interval is renewal-threshold-update-interval-ms Calculate the number of instances currently in use. If the number of instances is greater than the previously expected * renewal-percent-threshold (or if self-protection mode is not enabled), update the expected number of instances to the number of instances currently in use. Calculate the expected number of heartbeat requests = Expected number of instances * (60 / expected-client-renewal-interval-seconds) * renewal-percent-threshold # In the formula, 60 represents one minute. Because the formula uses prior-client-renewal -interval-seconds, which is the average heartbeat interval between instances, to make the formula accurate, It is better to configure the same heartbeat duration for each instance. # Default 900000ms = 900s = 15min In order to make this formula accurate, it is better to configure the same heartbeat time for each instance. This configuration is used in two places: If self-protection is enabled, whether the number of received heartbeat requests within the specified period of time is less than the number of instances times the std-threshold-update-interval-ms The maximum expiration time is 1-stD-Percent-threshold For instances of this number of proportions, stD-Percent-threshold: 0.85Copy the code
  1. Cluster configuration within the same region: As mentioned above, Eureka server instances in the same region receive client requests that are forwarded to other Eureka server instances in the same region. At the same time, when a Eureka server instance is started, the instance list is synchronized from other Eureka servers in the same zone. Also, forwarding to other Eureka server instances is done asynchronously, with a dedicated thread pool for forwarding. Also, HTTP requests are forwarded, which requires HTTP connection pooling:
Eureka: server: #Eureka Server Updates the list of other Eureka server instances in the same area from the configuration. Default: 10 minutes peer-eureka-nodes-update-interval-ms: The maximum number of retries to synchronize a service instance from another Eureka Server at startup until the number of instances does not reach 0. The default value is 0. 0 # Registry -sync-retry-wait-ms sync service instance information from other Eureka servers at startup 30000 # Number of UP Eureka Server instances in the cluster. The current Eureka Server status is UP. The default value is -1, indicating the number of other Eureka servers in the cluster whose Eureka Server status is not considered UP. Min-available-instance-for-peer-replication: -1 # Maximum timeout period for requesting other instance tasks. Default: 30 seconds max-time-for-replication: There are two thread pools, one for batch synchronization and the default size is 20 max-threads-for-peer-replication: The default size is 20 max-threads-for-status-replication for non-batch tasks (which is useless if AWS Autoscaling is not used) : [root@localhost] [root@localhost] [root@localhost] [root@localhost] [root@localhost] [root@localhost] [root@localhost] 10000 # Thread pool queue length for processing non-batch tasks (default: 10000) max-elems-in-status-replication-pool: 10000 #Eureka Server httpClient connection timed out (default: 200ms peer-node-connect-timeout-ms) 200 # httpClient read timeout (default: 200ms) peer-node-read-timeout-ms 200 # Maximum number of httpClient connections, default 1000 peer-node-total-connections: 1000 # httpClient's default maximum number of connections to a host is 500 peer-node-totals-connections-per-host: 500 # HttpClient connection idle keeptime (default: 30s peer-node-connection-idle-timeout-seconds: 30Copy the code
  1. Related configurations across regions. The Eureka server periodically pulls the list of service instances from other regions and caches them locally. When a microservice cannot be queried locally, the cache of the remote regional service instance is queried. Related configurations are as follows:
Eureka: server: # HttpClient connection of another Region timed out. Default: 1000ms remote-region-connect-timeout-ms: Remote - Region -read-timeout-ms remote- Region -read-timeout-ms 1000 # Maximum number of httpclient connections for another Region (default: 1000 remote-region-total-connections) 1000 # Request the maximum number of connections to a host from the httpClient of another Region by default 500 remote-region-totals-connections-per-host: Remote -region-connection-idle-timeout-seconds Gzip is enabled for HTTP requests from other regions. For other regions, network connections are slow. Therefore, g-zip-content-from-remote-region is enabled 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: If you need to fetch instance information from other regions, this interval is 30s by default. Remote-region-registry-fetch -interval The default thread pool for this task is 20 remote-region-fetch-thread-pool-size: 20Copy the code

Start a Eureka Server

Starting a Eureka registry server is very simple, and we are using the startup package packaged in Spring Cloud. Eureka 1. X Eureka Server is a pure servlet-based application. In order to work with Spring Cloud, you need the glue 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 on spring-Cloud-starter-Eureka-Server. A 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>Copy the code

Eureka Server configuration: refer to our above configuration: 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);
    }
}

Copy the code