How do Spring Cloud Eureka and Ribbon do service discovery?

Posted by mcerveni on Tue, 08 Feb 2022 23:25:13 +0100

Author: fredalxin

This article is based on spring cloud dalston, and the article is long. Please choose a comfortable posture to read.

What are Eureka and Ribbon? What does it have to do with service discovery?

Eureka and Ribbon are microservice components provided by Netflix, which are used for service registration and discovery and load balancing respectively. At the same time, both belong to the spring cloud netflix system and are seamlessly integrated with spring cloud, which is also known by everyone.

Eureka itself is a service registration and discovery component, which implements a complete Service Registry and Service Discovery.

Ribbon is a load balancing component. What does it have to do with service discovery? Load balancing is next to service discovery in the whole microservice invocation model, and the ribbon framework actually acts as a bridge between the developer's service consumption behavior and the underlying service discovery component Eureka.

Strictly speaking, Ribbon does not do service discovery, but due to the loose coupling of Netflix components, Ribbon needs to perform a similar behavior to "service discovery" on Eureka's cache service list, so as to build its own load balancing list and update it in time, that is, the object of "service discovery" in Ribbon becomes Eureka (or other service discovery components).

Eureka's service registration and discovery

We will first describe Eureka's service discovery, focusing on how Eureka client registers and discovers services. At the same time, we will not stay in Eureka's architecture, Eureka server implementation, Zone/Region and other categories.

Eureka client's service discovery is implemented by the DiscoveryClient class, which mainly includes the following functions:

  • Register a service instance with Eureka server
  • Update the lease term in Eureka server
  • Cancel the lease in Eureka server (service offline)
  • Discover service instances and update them regularly

Service registration

All scheduled tasks of DiscoveryClient are in the initScheduledTasks() method. We can see the following key codes:

private void initScheduledTasks() {
    if (clientConfig.shouldRegisterWithEureka()) {
         // InstanceInfo replicator
        instanceInfoReplicator = new InstanceInfoReplicator(
                2); // burstSize

We can see that an instanceInfoReplicator instance is created in the if judgment branch, which will execute a scheduled task through start:

public void run() {
    try {

        Long dirtyTimestamp = instanceInfo.isDirtyWithTime();
        if (dirtyTimestamp != null) {
    } catch (Throwable t) {
        logger.warn("There was a problem with the instance info replicator", t);
    } finally {
        Future next = scheduler.schedule(this, replicationIntervalSeconds, TimeUnit.SECONDS);

We can find this paragraph in the run() method of InstanceInfoReplicator class. At the same time, we can find that the key point of its registration is discoveryclient Register (), let's go in and have a look:

boolean register() throws Throwable { + appPathIdentifier + ": registering service...");
    EurekaHttpResponse<Void> httpResponse;
    try {
        httpResponse = eurekaTransport.registrationClient.register(instanceInfo);
    } catch (Exception e) {
        logger.warn("{} - registration failed {}", PREFIX + appPathIdentifier, e.getMessage(), e);
        throw e;
    if (logger.isInfoEnabled()) {"{} - registration status: {}", PREFIX + appPathIdentifier, httpResponse.getStatusCode());
    return httpResponse.getStatusCode() == 204;

It can be found here that the instanceinfo instance information is registered on Eureka server through HTTP REST (jersey client) request. Let's take a brief look at the instanceinfo object. The attributes can basically see the name and meaning:

public InstanceInfo(
    @JsonProperty("instanceId") String instanceId,
    @JsonProperty("app") String appName,
    @JsonProperty("appGroupName") String appGroupName,
    @JsonProperty("ipAddr") String ipAddr,
    @JsonProperty("sid") String sid,
    @JsonProperty("port") PortWrapper port,
    @JsonProperty("securePort") PortWrapper securePort,
    @JsonProperty("homePageUrl") String homePageUrl,
    @JsonProperty("statusPageUrl") String statusPageUrl,
    @JsonProperty("healthCheckUrl") String healthCheckUrl,
    @JsonProperty("secureHealthCheckUrl") String secureHealthCheckUrl,
    @JsonProperty("vipAddress") String vipAddress,
    @JsonProperty("secureVipAddress") String secureVipAddress,
    @JsonProperty("countryId") int countryId,
    @JsonProperty("dataCenterInfo") DataCenterInfo dataCenterInfo,
    @JsonProperty("hostName") String hostName,
    @JsonProperty("status") InstanceStatus status,
    @JsonProperty("overriddenstatus") InstanceStatus overriddenstatus,
    @JsonProperty("leaseInfo") LeaseInfo leaseInfo,
    @JsonProperty("isCoordinatingDiscoveryServer") Boolean isCoordinatingDiscoveryServer,
    @JsonProperty("metadata") HashMap<String, String> metadata,
    @JsonProperty("lastUpdatedTimestamp") Long lastUpdatedTimestamp,
    @JsonProperty("lastDirtyTimestamp") Long lastDirtyTimestamp,
    @JsonProperty("actionType") ActionType actionType,
    @JsonProperty("asgName") String asgName) {
    this.instanceId = instanceId;
    this.sid = sid;
    this.appName = StringCache.intern(appName);
    this.appGroupName = StringCache.intern(appGroupName);
    this.ipAddr = ipAddr;
    this.port = port == null ? 0 : port.getPort();
    this.isUnsecurePortEnabled = port != null && port.isEnabled();
    this.securePort = securePort == null ? 0 : securePort.getPort();
    this.isSecurePortEnabled = securePort != null && securePort.isEnabled();
    this.homePageUrl = homePageUrl;
    this.statusPageUrl = statusPageUrl;
    this.healthCheckUrl = healthCheckUrl;
    this.secureHealthCheckUrl = secureHealthCheckUrl;
    this.vipAddress = StringCache.intern(vipAddress);
    this.secureVipAddress = StringCache.intern(secureVipAddress);
    this.countryId = countryId;
    this.dataCenterInfo = dataCenterInfo;
    this.hostName = hostName;
    this.status = status;
    this.overriddenstatus = overriddenstatus;
    this.leaseInfo = leaseInfo;
    this.isCoordinatingDiscoveryServer = isCoordinatingDiscoveryServer;
    this.lastUpdatedTimestamp = lastUpdatedTimestamp;
    this.lastDirtyTimestamp = lastDirtyTimestamp;
    this.actionType = actionType;
    this.asgName = StringCache.intern(asgName);

    // ---------------------------------------------------------------
    // for compatibility

    if (metadata == null) {
        this.metadata = Collections.emptyMap();
    } else if (metadata.size() == 1) {
        this.metadata = removeMetadataMapLegacyValues(metadata);
    } else {
        this.metadata = metadata;

    if (sid == null) {
        this.sid = SID_DEFAULT;

The whole process is summarized as follows:

Service renewal

Service renewal may be obscure. In fact, it is to make regular calls on the client side to let eureka server know that it is still alive. The comments in eureka code are interpreted as heart beat.

Here are two important configurations to note:

  • instance. Lease renew alintervalinseconds indicates the update frequency of the client. The default is 30s, that is, the update operation will be initiated to Eureka server every 30s.
  • instance.leaseExpirationDurationInSeconds this is the expiration time of the server's perspective. The default is 90s, that is, if Eureka server does not receive a renew operation from the client within 90s, it will be rejected.

Let's look directly from the code point of view. Similarly, the related scheduled tasks are in the initScheduledTasks() method:

private void initScheduledTasks() {
    if (clientConfig.shouldRegisterWithEureka()) {
         // Heartbeat timer
                    new TimedSupervisorTask(
                            new HeartbeatThread()
                    renewalIntervalInSecs, TimeUnit.SECONDS);

You can see that a HeartbeatThread() thread is created here to perform operations:

private class HeartbeatThread implements Runnable {

    public void run() {
        if (renew()) {
            lastSuccessfulHeartbeatTimestamp = System.currentTimeMillis();

Let's look directly at the renew() method:

boolean renew() {
    EurekaHttpResponse<InstanceInfo> httpResponse;
    try {
        httpResponse = eurekaTransport.registrationClient.sendHeartBeat(instanceInfo.getAppName(), instanceInfo.getId(), instanceInfo, null);
        logger.debug("{} - Heartbeat status: {}", PREFIX + appPathIdentifier, httpResponse.getStatusCode());
        if (httpResponse.getStatusCode() == 404) {
  "{} - Re-registering apps/{}", PREFIX + appPathIdentifier, instanceInfo.getAppName());
            return register();
        return httpResponse.getStatusCode() == 200;
    } catch (Throwable e) {
        logger.error("{} - was unable to send heartbeat!", PREFIX + appPathIdentifier, e);
        return false;

It is relatively simple here. It can be found that it is similar to service registration. It also uses HTTP REST to initiate a heartbeat request, and the bottom layer uses jersey client.

The whole process is summarized as follows:

Service logoff

The logic of service logoff is relatively simple. It is not triggered in the scheduled task itself. Instead, it is triggered by calling the shutdown method by marking the method @ PreDestroy. Finally, it will call the unRegister() method to logoff. Similarly, this is also an HTTP REST request. You can simply see the following code:

public synchronized void shutdown() {
    if (isShutdown.compareAndSet(false, true)) {"Shutting down DiscoveryClient ...");

        if (statusChangeListener != null && applicationInfoManager != null) {


        // If APPINFO was registered
        if (applicationInfoManager != null && clientConfig.shouldRegisterWithEureka()) {

        if (eurekaTransport != null) {

        registryStalenessMonitor.shutdown();"Completed shut down of DiscoveryClient");

     * unregister w/ the eureka service.
void unregister() {
    // It can be null if shouldRegisterWithEureka == false
    if(eurekaTransport != null && eurekaTransport.registrationClient != null) {
        try {
  "Unregistering ...");
            EurekaHttpResponse<Void> httpResponse = eurekaTransport.registrationClient.cancel(instanceInfo.getAppName(), instanceInfo.getId());
   + appPathIdentifier + " - deregister  status: " + httpResponse.getStatusCode());
        } catch (Exception e) {
            logger.error(PREFIX + appPathIdentifier + " - de-registration failed" + e.getMessage(), e);

Service discovery and update

Let's look at the key logic as a service consumer, that is, discovering services and updating services.

First, the consumer will get all the service lists from Eureka server at startup and cache them locally. At the same time, since there is a local cache, it needs to be updated regularly, and the update frequency can be configured.

At startup, the fetchRegistry() method will be called in discoveryClient by the consumer:

private boolean fetchRegistry(boolean forceFullRegistryFetch) {
    if (clientConfig.shouldDisableDelta()
            || (!Strings.isNullOrEmpty(clientConfig.getRegistryRefreshSingleVipAddress()))
            || forceFullRegistryFetch
            || (applications == null)
            || (applications.getRegisteredApplications().size() == 0)
            || (applications.getVersion() == -1)) //Client application does not have latest library supporting delta
    } else {

Here you can see that there are two judgment branches in fetchRegistry, corresponding to the first update and subsequent updates. The first update will call the getAndStoreFullRegistry() method. Let's take a look:

 private void getAndStoreFullRegistry() throws Throwable {
     long currentUpdateGeneration = fetchRegistryGeneration.get();"Getting all instance registry info from the eureka server");

     Applications apps = null;
     EurekaHttpResponse<Applications> httpResponse = clientConfig.getRegistryRefreshSingleVipAddress() == null
         ? eurekaTransport.queryClient.getApplications(remoteRegionsRef.get())
         : eurekaTransport.queryClient.getVip(clientConfig.getRegistryRefreshSingleVipAddress(), remoteRegionsRef.get());
     if (httpResponse.getStatusCode() == Status.OK.getStatusCode()) {
         apps = httpResponse.getEntity();
     }"The response status is {}", httpResponse.getStatusCode());

     if (apps == null) {
         logger.error("The application is null for some reason. Not storing this information");
     } else if (fetchRegistryGeneration.compareAndSet(currentUpdateGeneration, currentUpdateGeneration + 1)) {
         logger.debug("Got full registry with apps hashcode {}", apps.getAppsHashCode());
     } else {
         logger.warn("Not updating applications as another thread is updating it already");

It can be seen that similar to before, if there is no special specification, we will launch an HTTP REST request to pull the information of all Applications and cache it. The cache object is Applications. You can check it further if you are interested.

Next, in the familiar initScheduledTasks() method, we will also start a task to update the application information cache:

private void initScheduledTasks() {
    if (clientConfig.shouldFetchRegistry()) {
        // registry cache refresh timer
        int registryFetchIntervalSeconds = clientConfig.getRegistryFetchIntervalSeconds();
        int expBackOffBound = clientConfig.getCacheRefreshExecutorExponentialBackOffBound();
            new TimedSupervisorTask(
                new CacheRefreshThread()
            registryFetchIntervalSeconds, TimeUnit.SECONDS);

In the run method of the task CacheRefreshThread(), we will still call the fetchRegistry() method before us. At the same time, when judging, we will go to another branch, that is, call the getAndUpdateDelta() method:

private void getAndUpdateDelta(Applications applications) throws Throwable {
    long currentUpdateGeneration = fetchRegistryGeneration.get();

    Applications delta = null;
    EurekaHttpResponse<Applications> httpResponse = eurekaTransport.queryClient.getDelta(remoteRegionsRef.get());
    if (httpResponse.getStatusCode() == Status.OK.getStatusCode()) {
        delta = httpResponse.getEntity();

    if (delta == null) {
        logger.warn("The server does not allow the delta revision to be applied because it is not safe. "
                    + "Hence got the full registry.");
    } else if (fetchRegistryGeneration.compareAndSet(currentUpdateGeneration, currentUpdateGeneration + 1)) {
        logger.debug("Got delta update with apps hashcode {}", delta.getAppsHashCode());
        String reconcileHashCode = "";
        if (fetchRegistryUpdateLock.tryLock()) {
            try {
                reconcileHashCode = getReconcileHashCode(applications);
            } finally {
        } else {
            logger.warn("Cannot acquire update lock, aborting getAndUpdateDelta");
        // There is a diff in number of instances for some reason
        if (!reconcileHashCode.equals(delta.getAppsHashCode()) || clientConfig.shouldLogDeltaDiff()) {
            reconcileAndLogDifference(delta, reconcileHashCode);  // this makes a remoteCall
    } else {
        logger.warn("Not updating application delta as another thread is updating it already");
        logger.debug("Ignoring delta update with apps hashcode {}, as another thread is updating it already", delta.getAppsHashCode());

As you can see, HTTP REST is used to initiate a getDelta request, and the local Applications cache object will be updated in the updateDelta() method.

To sum up, the whole process of service discovery and update is as follows:

Ribbon's "service discovery"

Next, let's take a look at how Ribbon performs "service discovery" based on Eureka. As we said before, "service discovery" here is not service discovery in the strict sense, but how Ribbon builds its own load balancing list based on Eureka and updates it in time, At the same time, we don't pay attention to other specific logic of Ribbon load balancing (including IRule routing and IPing judging availability).

We can make some conjectures first. Firstly, Ribbon must be based on Eureka's service discovery. As described above, Eureka will pull all service information into the local cache Applications, so Ribbon must build the load balancing list based on the Applications cache. At the same time, the load balancing list also needs a regular update mechanism to ensure consistency.

Service invocation

First of all, from the initial use of developers, we can start the Ribbon logic by opening the @ LoadBalanced annotation on the RestTemplate. Obviously, this is a method similar to interception. In the loadbalancenautoconfiguration class, we can see the relevant codes:

    public SmartInitializingSingleton loadBalancedRestTemplateInitializer(
    final List<RestTemplateCustomizer> customizers) {
    return new SmartInitializingSingleton() {
        public void afterSingletonsInstantiated() {
            for (RestTemplate restTemplate : LoadBalancerAutoConfiguration.this.restTemplates) {
                for (RestTemplateCustomizer customizer : customizers) {

static class LoadBalancerInterceptorConfig {
    public LoadBalancerInterceptor ribbonInterceptor(
        LoadBalancerClient loadBalancerClient,
        LoadBalancerRequestFactory requestFactory) {
        return new LoadBalancerInterceptor(loadBalancerClient, requestFactory);

    public RestTemplateCustomizer restTemplateCustomizer(
        final LoadBalancerInterceptor loadBalancerInterceptor) {
        return new RestTemplateCustomizer() {
            public void customize(RestTemplate restTemplate) {
                List<ClientHttpRequestInterceptor> list = new ArrayList<>(

You can see that during initialization, the interceptor LoadBalancerInterceptor is added to RestTemplate by calling the customize() method. LoadBalancerInterceptor uses loadBalancer(RibbonLoadBalancerClient class) in the interception method to complete the request call:

public ClientHttpResponse intercept(final HttpRequest request, final byte[] body,
                                    final ClientHttpRequestExecution execution) throws IOException {
    final URI originalUri = request.getURI();
    String serviceName = originalUri.getHost();
    Assert.state(serviceName != null, "Request URI does not contain a valid hostname: " + originalUri);
    return this.loadBalancer.execute(serviceName, requestFactory.createRequest(request, body, execution));

Service discovery

So far, our request call has been encapsulated by the RibbonLoadBalancerClient, and its "service discovery" also occurs in the RibbonLoadBalancerClient.

We click on its execute() method:

public <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException {
    ILoadBalancer loadBalancer = getLoadBalancer(serviceId);
    Server server = getServer(loadBalancer);
    if (server == null) {
        throw new IllegalStateException("No instances available for " + serviceId);
    RibbonServer ribbonServer = new RibbonServer(serviceId, server, isSecure(server,
                                                                             serviceId), serverIntrospector(serviceId).getMetadata(server));

    return execute(serviceId, ribbonServer, request);

Here, an ILoadBalancer is built according to the serviceId, and the final instance server information is obtained from the loadBalancer. ILoadBalancer is an interface that defines load balancing. Its key method, chooseServer(), is to select a server from the load balancing list according to the routing rules. Of course, our main concern is how the load balancing list is built.

Through the source code tracking, we find that after the ILoadBalancer object is built through the getLoadBalancer() method, the service list has been included in the object. So let's take a look at how the ILoadBalancer object is created:

protected ILoadBalancer getLoadBalancer(String serviceId) {
    return this.clientFactory.getLoadBalancer(serviceId);

So this is actually the clientFactory encapsulated by spring cloud, which will find the corresponding bean in the applicationContext container.

Through source code tracing, we can find the corresponding code in the automatic configuration class RibbonClientConfiguration:

public ILoadBalancer ribbonLoadBalancer(IClientConfig config,
                                        ServerList<Server> serverList, ServerListFilter<Server> serverListFilter,
                                        IRule rule, IPing ping, ServerListUpdater serverListUpdater) {
    if (this.propertiesFactory.isSet(ILoadBalancer.class, name)) {
        return this.propertiesFactory.get(ILoadBalancer.class, config, name);
    return new ZoneAwareLoadBalancer<>(config, rule, ping, serverList,
                                       serverListFilter, serverListUpdater);

We can see that ILoadBalancer is finally built here. Its implementation class is ZoneAwareLoadBalancer. We observe the initialization of its superclass:

public DynamicServerListLoadBalancer(IClientConfig clientConfig, IRule rule, IPing ping,
                                     ServerList<T> serverList, ServerListFilter<T> filter, ServerListUpdater serverListUpdater) {
    super(clientConfig, rule, ping);
    this.serverListImpl = serverList;
    this.filter = filter;
    this.serverListUpdater = serverListUpdater;
    if (filter instanceof AbstractServerListFilter) {
        ((AbstractServerListFilter) filter).setLoadBalancerStats(getLoadBalancerStats());

Finally, restOfInit() method is executed to further trace:

void restOfInit(IClientConfig clientConfig) {
    boolean primeConnection = this.isEnablePrimingConnections();
    // turn this off to avoid duplicated asynchronous priming done in BaseLoadBalancer.setServerList()

    if (primeConnection && this.getPrimeConnections() != null) {
    this.setEnablePrimingConnections(primeConnection);"DynamicServerListLoadBalancer for client {} initialized: {}", clientConfig.getClientName(), this.toString());

The updateListOfServers() method is used to get all the serverlists, which are ultimately determined by serverListImpl Getupdatedlistofservers() gets the list of all services. In this serverListImpl, the implementation class is DiscoveryEnabledNIWSServerList.

DiscoveryEnabledNIWSServerList has getInitialListOfServers() and getUpdatedListOfServers() methods. The specific code is as follows

public List<DiscoveryEnabledServer> getInitialListOfServers(){
    return obtainServersViaDiscovery();

public List<DiscoveryEnabledServer> getUpdatedListOfServers(){
    return obtainServersViaDiscovery();

At this time, we can see that the obtainserverviadiscovery () method is basically close to the essence of things. It creates an EurekaClient object, which is Eureka's DiscoveryClient implementation class, calls its getInstancesByVipAddress() method, and finally selects the corresponding service information from the Applications cache of DiscoveryClient according to the serviceId:

private List<DiscoveryEnabledServer> obtainServersViaDiscovery() {
    List<DiscoveryEnabledServer> serverList = new ArrayList<DiscoveryEnabledServer>();

    if (eurekaClientProvider == null || eurekaClientProvider.get() == null) {
        logger.warn("EurekaClient has not been initialized yet, returning an empty list");
        return new ArrayList<DiscoveryEnabledServer>();

    EurekaClient eurekaClient = eurekaClientProvider.get();
    if (vipAddresses!=null){
        for (String vipAddress : vipAddresses.split(",")) {
            // if targetRegion is null, it will be interpreted as the same region of client
            List<InstanceInfo> listOfInstanceInfo = eurekaClient.getInstancesByVipAddress(vipAddress, isSecure, targetRegion);
            for (InstanceInfo ii : listOfInstanceInfo) {
                if (ii.getStatus().equals(InstanceStatus.UP)) {

                            logger.debug("Overriding port on client name: " + clientName + " to " + overridePort);

                        // copy is necessary since the InstanceInfo builder just uses the original reference,
                        // and we don't want to corrupt the global eureka copy of the object which may be
                        // used by other clients in our system
                        InstanceInfo copy = new InstanceInfo(ii);

                            ii = new InstanceInfo.Builder(copy).setSecurePort(overridePort).build();
                            ii = new InstanceInfo.Builder(copy).setPort(overridePort).build();

                    DiscoveryEnabledServer des = new DiscoveryEnabledServer(ii, isSecure, shouldUseIpAddr);
            if (serverList.size()>0 && prioritizeVipAddressBasedServers){
                break; // if the current vipAddress has servers, we dont use subsequent vipAddress based servers
    return serverList;

Service update

We already know how Ribbon combined with Eureka to complete the construction of load balancing list during the initial startup. Similar to Eureka, we also need to update the service list in time to ensure consistency.

When building ILoadBalancer in RibbonClientConfiguration automatic configuration class, we can see that there is ServerListUpdater object in its constructor, and this object is also built in the current class:

public ServerListUpdater ribbonServerListUpdater(IClientConfig config) {
    return new PollingServerListUpdater(config);

Let's observe the start() method in this object to see how the update is completed:

public synchronized void start(final UpdateAction updateAction) {
    if (isActive.compareAndSet(false, true)) {
        final Runnable wrapperRunnable = new Runnable() {
            public void run() {
                if (!isActive.get()) {
                    if (scheduledFuture != null) {
                try {
                    lastUpdated = System.currentTimeMillis();
                } catch (Exception e) {
                    logger.warn("Failed one update cycle", e);

        scheduledFuture = getRefreshExecutor().scheduleWithFixedDelay(
    } else {"Already active, no-op");

There are two configurations here, that is, initialDelayMs first detection defaults to 1s, and refreshIntervalMs detection interval defaults to 30s (consistent with Eureka). A scheduled task is created to execute updateaction Doupdate() method.

Let's go back to the previous restOfInit() method and check the enableandinitrlearnnewserversfeature() method. We can see that the start method of ServerListUpdater is triggered here and the updateAction object is passed in:

public void enableAndInitLearnNewServersFeature() {"Using serverListUpdater {}", serverListUpdater.getClass().getSimpleName());

In fact, updateAction has been created from the beginning. It still calls the previous updateListOfServers method for subsequent updates:

protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
    public void doUpdate() {

To sum up, the overall process of Ribbon's three parts of service discovery is as follows:

reference material:

Recent hot article recommendations:

1.600 + Java interview questions and answers (2021 latest edition)

2.Finally got the IntelliJ IDEA activation code through the open source project. It's really fragrant!

3.Ali Mock tools are officially open source and kill all Mock tools on the market!

4.Spring Cloud 2020.0.0 is officially released, a new and subversive version!

5.Java development manual (Songshan version) is the latest release. Download it quickly!

Feel good, don't forget to like + forward!