How Ribbon Powers Client‑Side Load Balancing in Spring Cloud Microservices

Hello, I am Su San.

Today we explore Ribbon, a crucial client‑side load‑balancing component in Spring Cloud microservices.

Load balancing distributes network traffic across multiple servers, enabling horizontal scaling.

Key design considerations include obtaining and synchronizing the server list, choosing a distribution strategy, and intercepting client requests for forwarding.

1. Load Balancing

1.1 Concept

Load balancing is a core element of high‑availability networks, ensuring traffic is spread across servers.

Two basic points:

Select which server handles a client request.

Forward the client request to the chosen server.

The core principle is maintaining a service list and routing requests based on a load‑balancing algorithm.

1.2 Characteristics

High performance : automatically distributes traffic according to rules.

Scalability : easily adds servers or links.

Reliability : failures of individual devices do not interrupt service.

Ease of configuration : simple to set up and maintain.

Transparency : users are unaware of the balancing process.

1.3 Classification

Load‑balancing techniques can be classified by hardware vs. software and by server‑side vs. client‑side.

1.3.1 Hardware Load Balancing

Example: F5. Advantages: stable performance, advanced features such as session exchange and health monitoring. Disadvantages: expensive, less flexible than software solutions.

1.3.2 Software Load Balancing

Nginx : high performance, supports over 10,000 requests, operates at layer 7, suitable for HTTP/HTTPS and email.

LVS (Linux Virtual Server) : IP‑level balancing, high throughput, works at layer 4, includes Keepalived for failover.

1.3.3 Server‑Side Load Balancing

Implemented by Nginx, F5, etc., where the server list resides on a backend server.

1.3.4 Client‑Side Load Balancing

Ribbon belongs here; it maintains its own server list, fetching data from Eureka and removing unavailable instances.

2. Balancing Strategies

Common strategies include:

2.1 Round Robin

Sequentially selects servers in order.

2.2 Weighted Round Robin

Assigns weights based on server capacity and distributes requests accordingly.

2.3 Random

Randomly selects a server for each request.

2.4 Response Time

Chooses the server with the fastest response measured by probing.

3. Ribbon Core Components

Ribbon consists of five major functional components: ServerList, Rule, Ping, ServerListFilter, and ServerListUpdater.

3.1 LoadBalancer

Manages load‑balancing logic, initialized from YAML configuration.

3.2 ServerList

Obtains and stores service addresses, supporting static (config file) and dynamic (service registry) modes.

3.3 ServerListFilter

Filters the retrieved list based on rules such as Eureka partitioning, health metrics, or region.

Filter by Eureka partition.

Remove instances with high failure or concurrency.

Keep instances in the same region.

3.4 ServerListUpdater

Updates the server list from the registry, either via periodic polling (PollingServerListUpdater) or Eureka event listeners (EurekaNotificationServerListUpdater).

3.5 Ping

Health‑check interface; implementations include PingUrl, PingConstant, NoOpPing, DummyPing, NIWSDiscoveryPing. Default strategy is round‑robin probing.

3.6 Rule

Defines load‑balancing algorithms. Common rules are:

RoundRobinRule : simple sequential selection.

AvailabilityFilteringRule : skips unhealthy or overloaded servers.

WeightedResponseTimeRule : weights based on response latency.

ZoneAvoidanceRule : prefers servers in the same zone (default in Spring Cloud).

RetryRule : retries failed requests on other nodes.

BestAvailableRule : selects the least concurrent server.

RandomRule : random selection.

4. Ribbon Request Interception

Steps:

Ribbon intercepts RestTemplate methods annotated with

@LoadBalanced

.

LoadBalancerInterceptor is added to RestTemplate.

An

ILoadBalancer

instance is created.

Ribbon configures IRule, IPing, ServerList via

RibbonClientConfiguration

.

The selected server receives the forwarded request.

5. Ribbon Initialization

The entry point is the

@LoadBalanced

annotation on a RestTemplate bean.

@LoadBalanced<br/>@Bean<br/>public RestTemplate getRestTemplate() {<br/>    return new RestTemplate();<br/>}

Initialization flow:

LoadBalancerAutoConfiguration triggers Ribbon setup.

Annotated RestTemplate beans are collected.

RestTemplateCustomizer adds LoadBalancerInterceptor.

Server list is fetched from Eureka.

YAML configuration is applied and an

ILoadBalancer

instance is created.

6. Ribbon Service List Synchronization

After the initial full fetch from Eureka, Ribbon periodically polls the registry (default every 30 seconds) using

PollingServerListUpdater

.

7. Eureka Heartbeat Mechanism

Eureka expects each instance to send a heartbeat every 30 seconds; missing three consecutive heartbeats marks the instance as down.

Self‑protection activates when the actual heartbeat rate falls below 85 % of the expected rate, preventing mass removal.

Service removal is gradual, up to 15 % per attempt.

8. Ribbon Heartbeat Mechanism

Ribbon checks the status of cached servers locally using the

isAlive

method (status ==

InstanceStatus.UP

) every 30 seconds.

isAlive = status.equals(InstanceStatus.UP);

9. Common Ribbon Configuration

9.1 Disable Eureka

# Disable Eureka<br/>ribbon.eureka.enabled=false

9.2 Configure Server List

ribbon-config-passjava.ribbon.listOfServers=localhost:8081,localhost:8083

9.3 Other Settings

10. Summary

Six core components of Ribbon.

How Ribbon intercepts and forwards requests.

Initialization process.

Synchronization with Eureka.

Eureka and Ribbon heartbeat mechanisms.

Common configuration options.