Code address of this series: https://github.com/HashZhang/spring-cloud-scaffold/tree/master/spring-cloud-iiford

Eureka client configuration refers to the client configuration related to accessing Eureka Server, including Eureka Server address configuration, pull service instance information configuration, current instance registration configuration and http connection configuration. In Spring Cloud, Eureka client is configured to Eureka Starting with client, the corresponding configuration class is EurekaClientConfigBean

Among them, Eureka client has three important timing tasks and related configurations, which are shown here in the form of diagrams:

Read service instance related processes:

Regularly check the instance information and instance status and synchronize to Eureka Server:

Timed heartbeat related processes:

The address of Eureka Server can be directly specified, and these configurations can be dynamically modified, and the refresh time can be configured. For example:

eureka:
    client:
      service-url:
        # The default eureka cluster must be defaultZone here, and cannot replace uppercase with - which is different from other configurations, because it is written dead in eureka clientconfigbean
        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 the configuration related to the above eureka server address is updated, how long will it be read again
      eureka-service-url-poll-interval-seconds: 300

Eureka Server can also be obtained through DNS, for example:

eureka:
    client:
      # Whether to use dns to obtain. If it is specified, obtain it through the dns configuration below instead of the service URL above
      use-dns-for-fetching-service-urls: true
      # dns configuration
      # eureka-server-d-n-s-name: eureka.com
      # port of eureka server configured by dns
      # eureka-server-port: 80
      # uri prefix context after port of eureka server configured by dns
      # eureka-server-u-r-l-context: /eureka

At the same time, different Eureka servers may be deployed in different available zones. The zone configuration of Eureka Client can also be configured here:

eureka:
    client:
      # List of available zones. key is region and value is zone
      availability-zones:
        region1: zone1, zone2
        region2: zone3
      # In the region, read the availability zones to get the zone, and then read the service URL through the zone to get the corresponding eureka url
      # The logical corresponding classes here are ConfigClusterResolver and ZoneAffinityClusterResolver
      region: region1
      # If it is set to true, eureka in the same zone will run ahead and give priority to access. The default is true
      prefer-same-zone-eureka: true

We can configure whether to pull the service instance information from Eureka. Generally, during local testing, we may not want to use the registered instance information on Eureka, so we can disable Eureka Client to obtain the micro service instance information from Eureka through this configuration.

eureka:
    client:
      # Pull instance from eureka
      fetch-registry: true

For the request to pull service instance information, you can also configure whether to pull compressed information or complete information, and whether to obtain instance information through incremental pull. Eureka incremental pull mechanism is simple to implement, that is, newly registered or eliminated instances will be put into the recently modified queue, and the information in the queue will be returned as a response to incremental pull. Incremental pull may lose the updates of some instances, but it can save network traffic. Incremental pull can be used when the network is bad. There is version control in incremental pull. If there are differences in versions, full pull will still be used, and then incremental pull will be carried out.

eureka:
    client:
      # Whether to disable incremental pull. If the network conditions are bad, it can be disabled and the full amount will be pulled every time. There is version control in incremental pull. If there are differences in versions, full pull will still be used, and then incremental pull will be carried out.
      disable-delta: false
      # The client request header specifies whether the instance information returned by the server is compressed information or complete information. The default is complete information
      # full, compact
      client-data-accept: full
      # For incremental pull, do you log differences every time
      log-delta-diff: true

The pulled instance will be saved to the local cache. The local cache has an expiration time:

eureka:
    client:
      # eureka client refresh local cache time
      # Default 30s
      registry-fetch-interval-seconds: 5
      # Only instances in UP status are reserved. The default value is true
      filter-only-up-instances: true
      # eureka client flushes the local cache (periodically pulls eureka instance list) and the thread pool size is 2 by default
      cache-refresh-executor-thread-pool-size: 2
      # The maximum delay time of eureka client refreshing the local cache (regularly pulling eureka instance list) thread pool task. This configuration is a multiple of the regularly pulling task delay (registry fetch interval seconds). By default, it is 10 times
      cache-refresh-executor-exponential-back-off-bound: 10

Meanwhile, in the Spring Cloud environment, As long as the microservice implementation is based on Spring Cloud Commons (in fact, all Spring Cloud implementations are based on this implementation), the service discovery Client: DiscoveryClient (synchronous environment) and ReactiveDiscoveryClient (asynchronous environment) are implemented using Composite, that is, there are multiple service discovery clients inside. Service discovery calls each service discovery Client in a certain order. The order of Eureka Client can also be configured here.

eureka:
    client:
      #In the spring cloud environment, the DiscoveryClient actually uses CompositeDiscoveryClient. The logic of CompositeDiscoveryClient is that multiple discoveryclients coexist. Visit one first and find the next one if you don't find it
      #This order determines the order and defaults to 0
      order: 0

When testing locally, we may not want to register the local instance with Eureka Server, which can also be configured:

eureka:
    client:
      # Do you want to register yourself with eureka
      register-with-eureka: true

Meanwhile, in Eureka's own design, Eureka instance information and configuration can be changed, so how long will it be synchronized to Eureka Server? Note that this is different from the heartbeat request. This can be configured separately:

eureka:
    client:
	  # The interval between synchronization of instance information to Eureka Server at the same time. Every so long, check whether the instance information (i.e. eureka.instance configuration information) has changed. If it has changed, synchronize to Eureka Server, which is 30s by default
      # It mainly checks two types of information, namely service address related information and service expiration time and refresh time configuration information
      instance-info-replication-interval-seconds: 30
      # The initial delay time for synchronizing instance information to Eureka Server at the same time. The default is 40s
      initial-instance-info-replication-interval-seconds: 40

There are other configurations that we may also use:

eureka:
    client:
	  # Whether to register with eureka during initialization is generally set to false because the instance cannot provide services normally
      should-enforce-registration-at-init: false
      # Whether to log off the instance when it is closed. The default value is true
      should-unregister-on-shutdown: true
      # Whether to limit the current for instance state change update. The default value is true
      on-demand-update-status-change: true

Eureka Client obtains service instance information based on Http requests, which can be configured for Http clients:

eureka:
    client:
      # Agent related configuration
      # proxy-host:
      # proxy-port:
      # proxy-user-name:
      # proxy-password:
      # Whether to enable gzip for http requests sent to Eureka Server has expired. As long as Eureka Server enables gzip, the requests are gzip compressed
      g-zip-content: true
      # The link of httpclient timed out. The default is 5s
      eureka-server-connect-timeout-seconds: 5
      # Reading timeout of httpclient, 5s by default
      eureka-server-read-timeout-seconds: 8
      # The idle connection timeout of httpclient is 30s by default
      eureka-connection-idle-timeout-seconds: 30
      # The total number of connections of httpclient. The default is 200
      eureka-server-total-connections: 200
      # Number of connections per host for httpclient
      eureka-server-total-connections-per-host: 50
	  # tls related configurations are 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:

In this section, we analyze the client configuration of Eureka in detail. In the next section, we will start to analyze the configuration related to Eureka Server.