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

In this issue, the editor will bring you about whether the SEureka service instance will immediately register with EurekaServer. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Based on SpringCloud-Dalston.SR5

When the Eureka service instance starts, will it register with EurekaServer immediately?

Yes, right away.

EurekaClient has a Listener each time the state of the instance changes:

StatusChangeListener = new ApplicationInfoManager.StatusChangeListener () {@ Override public String getId () {return "statusChangeListener";} @ Override public void notify (StatusChangeEvent statusChangeEvent) {if (InstanceStatus.DOWN = = statusChangeEvent.getStatus () | | InstanceStatus.DOWN = = statusChangeEvent.getPreviousStatus ()) {/ / log at warn level if DOWN was involved logger.warn ("Saw local status change event {}", statusChangeEvent) } else {logger.info ("Saw local status change event {}", statusChangeEvent);} / / this triggers calling the register API to register the instance information with instanceInfoReplicator.onDemandUpdate ();}}

When the instance is initialized, an event with a status of UP will be sent to trigger the Listener (the status changes from STARTING to UP):

@ Overridepublic void register (EurekaRegistration reg) {maybeInitializeClient (reg); if (log.isInfoEnabled ()) {log.info ("Registering application" + reg.getInstanceConfig (). GetAppname () + "with eureka with status" + reg.getInstanceConfig (). GetInitialStatus ());} reg.getApplicationInfoManager () .setInstanceStatus (reg.getInstanceConfig (). GetInitialStatus ()) If (reg.getHealthCheckHandler ()! = null) {reg.getEurekaClient () .registerHealthCheck (reg.getHealthCheckHandler ());}}

So, what is the use of these two configurations on the official website: in fact, this Initially is another logic, that is, 40 seconds after the launch of the application, check whether the instance information is old, or whether the first registration failed, and if it fails, register again. And then perform this task every 30 seconds.

How to synchronize the information within the EurekaServer cluster?

First, EurekaClient will choose the first EurekaServer configured by eureka.client.service-url.defaultZone, and then will always use this if there are no network problems with this EurekaServer. When EurekaClient sends all events such as registration, offline, heartbeat, state change to EurekaServer, these will be synchronized on EurekaServer to all Server of the cluster (EurekaServer cluster configuration is eureka.client.service-url.defaultZone, every EurekaServer in the cluster)

Is there anything wrong with such a mechanism?

Is this synchronization to other EurekaServer synchronized with this EurekaClient request? Is not synchronous, for example, registering to EurekaServerA,EurekaServerA and synchronizing the registration request to EurekaServerB is asynchronous with the current registration request

How to compensate for the failure of an asynchronous synchronization request? For example, service instance A registers to EurekaServerA, but synchronization to EurekaServerB fails. At this time, EurekaServerB does not have this instance. When the next A heartbeat, EurekaServerA synchronous heartbeat requests to EurekaServerB, it will return 404, triggering re-registration inference: in order to reduce and uniform EurekaServer pressure and convenience of access, we configure Eureka clusters for different instances of each microservice in a different order, with the same priority as our own network segment.

When the network jitters, leading to access to another Eureka, restart can only be restored.

How does the service instance expire?

Check the expired instance task regularly within EurekaServer, scan the expired instance in Registry and delete it, and invalidate the corresponding ReadWriteMap cache. Note that the ReadOnlyMap does not immediately expire, but changes are perceived from ReadWriteMap to ReadOnlyMap through the next read-only cache refresh. Because EurekaClient acquires instance information only from ReadOnlyMap, there is also a delay in EurekaClient perception changes.

Why can the client still get through when EurekaServer is hung up?

In the SpringCloud environment, EurekaClient has a cache, and Ribbon also has a cache for the list of invoked services, so you can continue to call, but the list of services and instances will not be updated. According to the design idea of Eureka's self-preservation, it can be understood that this design is also in line with the original intention of Eureka (An in CAP).

The above is whether the SEureka service instance shared by the editor will register with EurekaServer immediately when it starts. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.