Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "how to use Eureka as a registration center". In the operation of practical cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Current status of Eureka: the current 1.x version of Eureka is still being updated, but it should not update new features, but will only maintain, upgrade and be compatible with the required dependencies. Eureka 2.x is stillborn. But that doesn't mean Eureka just doesn't work. If you need a registry that is easy to deploy, Eureka is a good choice. In a cloud service environment, basically all instance addresses and micro-service names are constantly changing, and there is little need for the persistence feature that Eureka lacks. When your cluster belongs to small and medium-sized (less than 1000 nodes), Eureka is still a good choice. When your cluster is large, Eureka's synchronization mechanism may limit his performance.

The design of Eureka

The design of Eureka is relatively small, there is no complex synchronization mechanism and no complex persistence mechanism, and the cluster relationship simply forwards the received client requests to other Eureka instances in the cluster. Eureka itself only has the functions of a registry, unlike other types of registries, which combine a registry with a configuration center, such as Consul and nacos.

The interaction process of Eureka is as follows:

First, Service A sends a registration request (Register) to Eureka Server 1 in the same availability zone through Eureka Client. When these requests are received by sending heartbeat requests (Renew) to this Eureka Server 1. Eureka Server 1, these requests will be processed and forwarded to Eureka Server 2 and Eureka Server 3 in other clusters. Eureka Server 2 and Eureka Server 3 will no longer forward received Eureka Server 1 forwarded requests. Then, Service B and Service C get the location of Service A through Eureka, and finally call Service A.

For micro-services that are not queried locally, Eureka Server will also obtain them from the Eureka Server of the remote Region. For example, if Service D is not found locally, Eureka Server will return the instance of Service D of the remote Region. Since there is Service A locally, an instance of Service An of the remote Region will certainly not be returned. Moreover, the local Service list of remote Region is pulled regularly, and it is not queried every time.

In general, mutual calls between microservices do not go through Eureka and do not involve Eureka clients, but are called through load balancers, which we will talk about later.

Related concepts of Eureka

Here we ignore all AWS-related terminology and configuration and related logic processing.

Terms in Eureka:

Eureka instance: every instance registered with Eureka is an Eureka instance.

Eureka instance status: including UP (can process requests), DOWN (failed health check, unable to process requests normally), STARTING (initiating, unable to process requests), OUT_OF_SERVICE (artificial offline, do not process requests temporarily), UNKNOWN (unknown status).

Eureka server: runs as a registry, and mainly provides instance management functions (processing instance registration (register) requests, instance logout (cancel) requests, instance heartbeat (renew) requests, internal processing of instance expiration (evict), instance query functions (various interfaces for querying instance information, such as obtaining instance list through AppName, obtaining instance information through instance id, etc.)

Eureka server cluster: a cluster of Eureka servers. Each Eureka server is configured with a zone and an availability zone. Client requests received by Eureka servers are forwarded to other Eureka servers in the same zone. You can configure Eureka servers that are sent to the same availability zone first. Eureka servers that are not in the same area are synchronized by pulling them at regular intervals.

Eureka client: the client that requests the Eureka server. Encapsulates sending instance registration (register) requests, instance logout (cancel) requests, and instance heartbeat (renew) requests.

VIP (or Virtual Hostname): instances can be obtained in Eureka in two ways, one through the service name and the other through VIP. Each instance has a service name, as well as VIP. The index in the Eureka server is based on the service name key. We can also get the relevant instances by traversing all the instance information through VIP string matching. In the Spring Cloud system, the VIP, SVIP (actually Secure VIP, that is, the address of https) and the service name of an instance are all service names specified by spring.application.name.

Eureka related configuration

Eureka instance configuration: Eureka instance. Each instance registered with Eureka is an Eureka instance. The Eureka instance contains the following elements and related configurations:

Basic information: including IP, port and other information needed to access this Eureka instance:

Eureka: instance: # generally, we do not need to set eureka: instance: # generally, the constructor of EurekaInstanceConfigBean will obtain the ip address through InetUtils # ip-address: # generally, we do not need to set it. The constructor of EurekaInstanceConfigBean will obtain hostname # hostname: # registered to the address on eureka for access by other instances using ip, and other instances will access prefer-ip-address through ip: true # do not need to set non-secure-port Automatically use server.port as non-secure-port # non-secure-port: # if secure-port-enabled is true, server.port is automatically used as secure-port We generally do not use ssl for internal calls, so we do not need to configure secure-port # secure-port: # non-secure-port-enabled with non-secure-port enabled by default: true # does not enable secure-port by default, and we generally do not use ssl secure-port-enabled: false # personalized instance id for internal calls Including ip: micro service name: Port instance-id: ${spring.cloud.client.ip-address}: ${spring.application.name}: ${server.port} # app name. If left empty, the default is spring.application.name appname: ${spring.application.name} # app group name under Spring-cloud-netflix system. Currently, there is nothing to use app-group-name: common # instance namespace. Namespace: public is not useful at the moment.

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

Eureka: instance: # Health check address. Default is / actuator/health health-check-url-path: / actuator/health # instance status address, default is / actuator/info status-page-url-path: / actuator/info # homepage address, default is / home-page-url-path: /

Instance registration behavior, that is, the behavior of the instance after registration and the configuration of heartbeat interval:

Eureka: instance: # Service expiration time configuration. If EurekaServer does not receive a heartbeat after this time, the instance will be removed # Note: EurekaServer must set eureka.server.eviction-interval-timer-in-ms, otherwise the configuration is invalid # this configuration is generally three times the service refresh time configuration # default 90s lease-expiration-duration-in-seconds: 15 # service refresh time configuration Active heartbeats every other time # default 30s lease-renewal-interval-in-seconds: 5 registry: # Please refer to the wait-time-in-ms-when-sync-empty configuration description default-open-for-traffic-count: 1 # the number of instances that initially expect to send heartbeat requests, default is 1, when new instances are registered, they will be + 1, and when there are logouts, they will be-1 The initial default is 1 because you are also registered on eureka. Expected-number-of-clients-sending-renews: 1 # whether to start the service immediately after registration. The default is false. Generally, some operations need to be done after registration, so the status of registering the instance is STARTING. After changing the status, it will be updated to UP instance-enabled-onit: false

Instance metadata:

Eureka: instance: # metadata map, we can use it ourselves and put some personalized metadata. Currently, only configPath and zone are more useful. ConfigPath sets metadata-map: # spring cloud system when using spring-cloud-config. The configuration of the availability zone is put into metadata, and the key is zone zone: zone1.

Eureka client configuration:

Eureka server address configuration. You can specify the link directly, or configure it through region and zone, or through DNS:

Eureka: instance: # list of availability zones, key is the region where region,value is zone availability-zones: region1: zone1, zone2 region2: zone3 #, get zone by reading availability-zones, and then read service-url by zone to get the corresponding eureka url # where the logical corresponding classes are ConfigClusterResolver and ZoneAffinityClusterResolver region: region1 # key is zone,value and eureka link Separate service-url: # default eureka cluster with a comma. This must be defaultZone. Uppercase cannot be replaced with -. It is different from other configurations. Because the dead 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/ # written in EurekaClientConfigBean, if the configuration related to the eureka server address above is updated How long will it take to re-read the perceived eureka-service-url-poll-interval-seconds: 300 # whether to use dns to get it, and if specified, get it through the following dns configuration Instead of the above service-url use-dns-for-fetching-service-urls: false # dns configuration # eureka-server-d-n-s-name: # dns configured eureka server's port # eureka-server-port: # dns configured eureka server's uri prefix context # eureka-server-u-r-l-context: # if set to true, the eureka under the same zone will go ahead and have priority access. Default is true prefer-same-zone-eureka: true

Pull the configuration related to service instance information:

Eureka: instance: # whether to pull instances from eureka fetch-registry: true # if you only want to get a list of instances for a specific virtual host name, configure registry-refresh-single-vip-address # registry-refresh-single-vip-address: # client request header to specify whether the instance information returned by the server is compressed information or complete information Default is full information # full, compact client-data-accept: full # eureka client refresh local cache time # default 30s registry-fetch-interval-seconds: 5 # eureka client refresh local cache (regularly pull eureka instance list) thread pool size, default is 2 cache-refresh-executor-thread-pool-size: 2 # eureka client refresh local cache (regularly pull eureka instance list) maximum thread pool task delay This configuration is a multiple of the scheduled pull task delay (registry-fetch-interval-seconds). Default is 10 times cache-refresh-executor-exponential-back-off-bound: whether incremental pull is disabled by default. If the network condition is not good, it can be disabled. Every time, full disable-delta: false # only retains the instance with the status of UP. The default is true filter-only-up-instances: true # you can specify whether to pull service instances from some region # fetch-remote-regions-registry: # whether to log the changes between each pull instance information and the current cache instance information log-delta-diff: true # in the spring cloud environment, DiscoveryClient actually uses CompositeDiscoveryClient, this CompositeDiscoveryClient logic is actually the coexistence of multiple DiscoveryClient Visit one first, and then determine the order by looking for the next order, which defaults to 0 order: 0

The current instance registers relevant configurations:

Eureka: instance: # whether to register yourself with eureka register-with-eureka: whether true # registers to eureka at initialization time. It is generally set to false, because the instance cannot provide service normally. Should-enforce-registration-at-init: false # whether to log out the instance when it is closed The default is true should-unregister-on-shutdown: true # whether to limit the update of instance status. By default, it defaults to the interval between true on-demand-update-status-change: true # instance information and timing synchronization to Eureka Server. Every such a long time, check whether the instance information (that is, eureka.instance configuration information) has changed. If so, it will be synchronized to Eureka Server. By default, 30s # 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 # instance information synchronized with timing to the initial delay time of Eureka Server Default 40s initial-instance-info-replication-interval-seconds: 40

Configuration related to http connection:

Eureka: instance: # proxy 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 gzip is enabled in Eureka Server, the request is gzip compressed g-zip-content: true # httpclient link timed out Default 5s eureka-server-connect-timeout-seconds: read timeout for 5 # httpclient, default 5s eureka-server-read-timeout-seconds: 8 # httpclient idle connection timeout, default 30s eureka-connection-idle-timeout-seconds: total number of connections for 30 # httpclient, default number of connections per host for 200s eureka-server-total-connections: 200 # httpclient eureka-server-total-connections-per-host: 50 # tls related configuration # tls:# enabled: false# key-password:# key-store:# key-store-password:# key-store-type:# trust-store:# trust-store-password:# trust-store-type is not enabled by default:

Eureka server configuration:

Regularly check the configuration related to the expiration of the instance: after the instance is registered, you need to send a heartbeat to prove that the instance is alive. There are also scheduled tasks in the Eureka server to check whether the instance has expired:

Eureka: server: # Task execution interval to actively check whether the service instance is invalid. The default is 60s eviction-interval-timer-in-ms: 3000 # this configuration is used in two places: # if self-protection is enabled, it will renewal-threshold-update-interval-ms within the specified time Whether the number of heartbeat requests received is less than the number of instances multiplied by this renewal-percent-threshold # scheduled task to check expired instances. The maximum number of expired instances is 1-renewal-percent-threshold.

Self-protection related configuration: there are regularly expired tasks in the Eureka server, check for instances that have no heartbeat, and log them out. Self-protection is mainly aimed at network problems in the cluster, resulting in many instances unable to send heartbeats, resulting in abnormal status of many instances, but the actual instances are still working normally. Do not allow these instances not to participate in load balancing:

Eureka: server: # Note that it is best for all client instances to configure the heartbeat time-related configuration that is the same. This is the most accurate way to use the characteristics of self-protection. # disable self-protection # We do not use self-protection here, because: # self-protection is mainly aimed at network problems in the cluster, resulting in many instances unable to send heartbeats, resulting in abnormal state of many instances, but the actual instances are still working normally. Do not let these instances do not participate in load balancing # when self-protection is enabled, it will stop the expiration of instances # but If this happens, it also means that many instances cannot read the registry. # and there is another situation where Eureka is restarted. Although not common, we update frequently for other components in the image # I tend to solve this problem from the client for instance caching mechanism. If the returned instance list is empty, then use the last instance list for load balancing, which can solve the situation of Eureka restart. Can also handle some cases of Eureka network isolation # self-protection mode is based on the number of renew (instance heartbeat) requests per minute. If self-protection mode is enabled, only the number of renew received in the last minute is greater than this value, the instance will be logged out enable-self-preservation: false # the number of renew (instance heartbeat) requests per minute needs to be dynamically refreshed The refresh interval is renewal-threshold-update-interval-ms # update process: calculate the current total number of instances. If it is greater than the expected number of instances * renewal-percent-threshold (or self-protection mode is not enabled), the expected number of updated instances is the current total number of instances # according to the expected number of instances Calculate the number of heartbeat requests expected 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 expected-client-renewal-interval-seconds, that is, the average heartbeat interval of instances, in order to make this formula accurate It is best to configure the same heartbeat time for each instance # default 900000ms = 900s = 15min renewal-threshold-update-interval-ms: 900000 # average heartbeat interval, or expected heartbeat interval for the above-mentioned instances, in order to make this formula 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, it will renewal-threshold-update-interval-ms whether the number of heartbeat requests received within the specified time is less than the number of instances multiplied by this renewal-percent-threshold # scheduled task to check expired instances The proportion of instances with a maximum of 1-renewal-percent-threshold expired each time: renewal-percent-threshold: 0.85

Cluster configuration in the same region is related: as mentioned above, client requests received by Eureka server instances in the same region will be forwarded to other Eureka server instances in the same region. At the same time, when an Eureka server instance is started, the list of instances is synchronized from other Eureka servers in the same zone. Also, forwarding to other Eureka server instances is forwarded asynchronously, so there is a special thread pool for forwarding. At the same time, the HTTP request is also forwarded, which requires HTTP connection pool:

Eureka: server: # Eureka Server updates the list interval of other Eureka Server instances in the same area from the configuration. Default is 10 minutes peer-eureka-nodes-update-interval-ms: 600000 # maximum number of retries to synchronize service instance information from other Eureka Server at startup until the number of instances is not 0. Default is 0. This is actually out of sync registry-sync-retries: 0 # retry interval from other Eureka Server synchronization service instance information registry-sync-retry-wait-ms: 30000 # the number of Eureka Server instances of at least UP in the cluster. The current Eureka Server status is UP. The default of-1, that is, the Eureka Server status, does not take into account the number of other Eureka Server in the UP cluster. Min-available-instances-for-peer-replication:-1 # the maximum timeout for requesting other instance tasks. Default is 30 seconds max-time-for-replication: 30000 # the number of threads used to process synchronization tasks. There are two thread pools and one handles batch synchronization tasks. The default size is 20 max-threads-for-peer-replication: 20 # another thread pool queue length for non-batch tasks (not useful if AWS Autoscaling docking is not used). The default size is 20 max-threads-for-status-replication: 20 # thread pool queue length for batch tasks, and default is 10000 max-elements-in-peer-replication-pool: 10000 # thread pool queue length for non-batch tasks Default is 10000 max-elements-in-status-replication-pool: 10000 # Eureka Server to access other Eureka Server synchronous instances through httpclient. Httpclient connection timed out. Default 200ms peer-node-connect-timeout-ms: 200 # httpclient read timeout, default 200ms, generally not too long peer-node-read-timeout-ms: 200 # httpclient maximum total number of connections Default 1000 peer-node-total-connections: 1000 # httpclient maximum total number of connections for a host, default 500 peer-node-total-connections-per-host: 500 # httpclient connection idle time, default 30s peer-node-connection-idle-timeout-seconds: 30

Cross-region related configurations. The Eureka server periodically pulls the list of service instances in other regions and caches them locally. When a local query cannot find a microservice, the cache of the remote area service instance is queried. The relevant configurations are as follows:

Eureka: server: # request connection timeout of other Region's httpclient. Default 1000ms remote-region-connect-timeout-ms: 1000 # request other Region's httpclient read timeout, default 1000ms remote-region-read-timeout-ms: 1000 # request other Region's maximum total number of connections, default 1000 remote-region-total-connections: 1000 # request other Region's httpclient's maximum total number of connections to a certain host By default, 500 remote-region-total-connections-per-host: 500 # requests the idle time of the connection of other Region's httpclient. By default, 30s remote-region-connection-idle-timeout-seconds: 30 # requests whether gzip is enabled for the http request of other Region. For other Region, we think the network connection is slow. So compression g-zip-content-from-remote-region: 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 obtain instance information from other Region, this acquisition interval Default is 30s remote-region-registry-fetch-interval: 30 # if you need to obtain instance information from other Region, the thread pool for this task defaults to 20 remote-region-fetch-thread-pool-size: 20 to start an Eureka Server

Starting an Eureka registry server is very simple, and we are using a startup package packaged by Spring Cloud. Eureka Server of Eureka 1.x is a pure servlet-based application. In order to work with Spring Cloud, you need to glue the module, which is called spring-cloud-netflix-eureka-server. In spring-cloud-netflix-eureka-server, there is also a startup class that is very similar to com.netflix.eureka.EurekaBootStrap code, namely org.springframework.cloud.netflix.eureka.server.EurekaServerBootstrap. When we start the EurekaServer instance, we only need to add the dependency on spring-cloud-starter-eureka-server. An Eureka server instance can then be started with the @ EnableEurekaServer annotation.

Eureka Server dependencies:

Pom.xml

Spring-cloud-iiford com.github.hashjang 1.0-SNAPSHOT 4.0.0 spring-cloud-iiford-eureka-server com.github.hashjang spring-cloud-iiford-service-common ${project.version} org.springframework.cloud spring-cloud-netflix-eureka-server

Eureka Server configuration: refer to our above configuration: application.yml

Startup class of EurekaServer: 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@EnableEurekaServerpublic class EurekaServerApplication {public static void main (String [] args) {SpringApplication.run (EurekaServerApplication.class, args);}} "how to use Eureka as a registry" ends here. Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.