Understanding Feign Remote Calls and Ribbon Load Balancing Strategies in Microservices

Before using Feign for remote calls, it is essential to understand its workflow, which involves a registration center, load balancing, and the relationship between FeignClient and the services registered in Eureka or Nacos. Feign relies on Ribbon for load balancing; Ribbon obtains the service list from the registry, caches it locally, and the FeignClient then invokes the target service.

Ribbon performs load balancing by first retrieving the service list from Nacos or Eureka, which is a critical step.

RibbonClientConfiguration

The RibbonClientConfiguration class uses a LoadBalancer . Ribbon’s load balancing is based on the ILoadBalancer interface, which provides methods to add new services, select a service, mark a server down, retrieve the service list, get reachable servers, and obtain all servers (both healthy and unhealthy).

ZoneAwareLoadBalancer

The default load balancer is ZoneAwareLoadBalancer , which extends DynamicServerListLoadBalancer . Its restOfInit method calls two important methods: enableAndInitLearnNewServersFeature and updateListOfServers .

The enableAndInitLearnNewServersFeature method contains the following logging and start logic:

LOGGER.info("Using serverListUpdater {}", serverListUpdater.getClass().getSimpleName());
serverListUpdater.start(updateAction);

Examining ServerListUpdater.start reveals that it creates a custom thread to fetch the service list.

Ribbon Load‑Balancing Strategies

Beyond obtaining the service list, Ribbon offers seven load‑balancing rules:

RoundRobinRule – cycles through services sequentially.

WeightedResponseTimeRule – prefers services with higher weight (shorter response time).

RandomRule – selects a service randomly.

BestAvailableRule – chooses the instance with the fewest active connections.

RetryRule – retries failed services within a timeout.

AvailabilityFilteringRule – filters out unhealthy instances.

ZoneAvoidanceRule – zone‑aware strategy.

Ribbon Eager‑Load (Pre‑load) Mode

Ribbon creates its client only when the first HTTP request occurs, which adds client‑creation latency to the initial call. To avoid this, enable eager‑load so the client is instantiated at application startup.

Example controller method that measures call latency:

@GetMapping("/requestSystem2Api")
public String requestSystem2Api(){
    long startTime = System.currentTimeMillis();
    R
stringR = iTestServiceClient.testRequestMethod();
    if (null !=stringR){
        log.info("接口返回："+stringR.getMsg());
    }
    long needTime = System.currentTimeMillis() - startTime;
    log.info("接口调用需要的时间："+needTime);
    return "";
}

Log analysis shows the first call incurs extra time due to Ribbon’s dynamic server list loading, while subsequent calls are fast.

Enabling Ribbon Eager‑Load

ribbon:
    nacos:
        enabled: true # enable nacos discovery
    eager-load:
        enabled: true  # turn on eager‑load to prevent first‑request timeout
        clients: Lxlxxx-system2 # specify services to pre‑load
        ReadTimeout: 10000
        ConnectTimeout: 10000
        MaxAutoRetries: 0
        MaxAutoRetriesNextServer: 1
        OkToRetryOnAllOperations: false

When the application starts, logs confirm that the Lxlxxx-system2 service is pre‑loaded, eliminating the first‑request timeout.

Conclusion

The eager‑load mode acts like a "client load pre‑heat" operation, loading services at startup to prevent timeouts caused by complex business logic or large data volumes during inter‑service calls; it is worth trying when service interactions are slow.