The official Eureka documentation and the Spring Cloud Eureka documentation are full of ambiguations, and there are not many other sources, just read the source code to make a living…

Instead of going into every detail, this article will cover some of the key points for easy reference.

Some good references

  • An explanation of confusing regions and zones
  • Ctrip’s analysis of Eureka mechanism
  • Zhai Yongchao’s blog
  • Taro source code analysis
  • Hashi Chang’s column

Eureka-server accepts registration requests

Under normal circumstances will enter PeerAwareInstanceRegistryImpl# register (…). Methods:

@Override
public void register(final InstanceInfo info, final boolean isReplication) {
   // Lease expiration time
   int leaseDuration = Lease.DEFAULT_DURATION_IN_SECS;
   if(info.getLeaseInfo() ! =null && info.getLeaseInfo().getDurationInSecs() > 0) {
       leaseDuration = info.getLeaseInfo().getDurationInSecs();
   }
   // Register application instance information
   super.register(info, leaseDuration, isReplication);
   / / Eureka - Server replication
   replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication);
}
Copy the code

AbstractInstanceRegistry#register(…) Method completes the registration and copies the registration information to the peer node.

Let’s look at the registration part first.

The actual structure of registry

Registry declares in AbstractInstanceRegistry:

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry;
Copy the code

It is a ConcurrentHashMap where the Key is the AppID of the application and the Value is a Map where the key-value pairs are instances of the application. (Lease

>)

Lease indicates the registration period of an application Instance. InstanceInfo represents the state of an instance, which is basically provided by the client (the service instance itself). Obviously, because services can live and die, and the network environment is constantly changing, you need to know the status of services and decide whether they are available or not.

To get an idea of Lease and InstanceInfo from the previous figure:

2 Core registration process

AbstractInstanceRegistry#register(…) The method is very long, I will not post all of them here, otherwise I will be too tired to see. Just a few important snippets. The remaining details will be filled in as needed later.

  • Firstly, find the data corresponding to the application from Registry, which is denoted as gMap. If not, it has not been registered before (or has been deleted), then create a Map and add it to Registry.
Lease<InstanceInfo>> gMap = registry. Get (registrant.getAppName()); // Lease<InstanceInfo>> gMap = Registry. // If not, create and addCopy the code
  • Find the Lease corresponding to the registered instance in gMap. Pay attention to the relationship between application and instance. If yes, you need to use some of the informationserviceUpTimestampAnd so on. Then set lease’sregistrationTimestampandlastUpdateTimestampIs the current time.
  • After an OverriddenInstanceStatus calculation, get the current state of the application instance. The calculated input includes the lease state of the existing instance in Registry, the state declared by the registry, and a series of rules on the server. (Again, details will be covered later if necessary.) The final InstanceStatus has the following states:

  • Set the current InstanceInfolastUpdatedTimestamp
  • If it is the first registration, set leaseserviceUpTimestamp.
  • torecentlyChangedQueueAdd a current lease after packaging. We will talk about what this lease does later.
  • callinvalidateCache()Pass in the current application name and the virtual IP address of the instance. What does that do? Next time.

3 Process of copying registration information to peer nodes

The method is surprisingly simple: call the register interface of the peer node in turn.

Over.