This is my 24th day of the August Genwen Challenge

This series code address: github.com/HashZhang/s…

The Eureka Server configuration is required by the Eureka Server, including the configuration of periodically checking instance expiration, self-protection, cluster configuration within the same zone, and cross-zone configuration. In Spring Cloud, the Eureka client configuration starts with Eureka. Server, and the corresponding configuration class is EurekaServerConfigBean

According to the analysis of Eureka client in the previous section, we know that the Eureka client mainly accesses the following interfaces:

  • Registration:POST /eureka/apps/appID
  • Heart rate:PUT /eureka/apps/appID/instanceID
  • Get all service instances:GET /eureka/apps
  • Incrementally get all service instances:GET /eureka/apps/delta

The core logic for Eureka Server to process these requests and the related configurations are shown below:

After an instance is registered, it needs to send a heartbeat to prove that the instance is alive. There are also periodic tasks in Eureka Server 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

There are timed expired tasks on the server. Check for instances of slow heartbeat and unregister them. Self-protection mainly applies to the situation that many instances in the cluster cannot send heartbeat messages and are abnormal due to network faults, but the actual instances are still working 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

As mentioned above, a Eureka server instance in the same zone receives client requests that are forwarded to other Eureka server instances in the same zone. 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

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

Eureka service instance information cache configuration

Eureka Server stores all service instance information in memory and has multiple layers of caching for responses.

Eureka: server: # Incremental instance queue instance expiration time, default 3 minutes retention-time-in-m-s-in-delta-queue: Default: 30s delta-overretention timer-interval-in-ms There are two main elements in the response cache: readOnlyCacheMap and readWriteCacheMap ReadWriteCacheMap use-readonly-response-cahce: True # Initial readWriteCacheMap size: 1000 initial-capacity-of-response-cache: 1000 # LoadingCache Cache expiration time 180s response-cache-auto-expiration-in-seconds 9 # Timed synchronization from LoadingCache to read-only cache (default: 30s response-cache-update-interval-ms: 3000Copy the code

This section examines the configuration of Eureka Server in detail. In the next section, we will provide you with a configuration template to start a Eureka Server cluster.

Wechat search “my programming meow” public account, a daily brush, easy to improve skills, won a variety of offers: