Master Spring Cloud: Deep Dive into Zuul, Eureka, Ribbon, Feign, Config & Sleuth

This article provides a comprehensive overview of Spring Cloud, detailing its core components—including Zuul, Eureka, Ribbon, Feign, Config, and Sleuth—their definitions, roles, underlying principles, and how they work together to enable robust microservice architectures.

Architect Chen
Architect Chen
Architect Chen
Master Spring Cloud: Deep Dive into Zuul, Eureka, Ribbon, Feign, Config & Sleuth

Spring Cloud Overview

Spring Cloud builds on Spring Boot to provide a collection of libraries that address common concerns in a microservice architecture, such as service discovery, centralized configuration, client‑side load balancing, declarative HTTP clients, API gateway, and distributed tracing.

Zuul API Gateway

Purpose

Acts as a single entry point for external clients.

Routes incoming requests to the appropriate backend service instances.

Executes a chain of filters (pre, routing, post, error) for authentication, logging, rate‑limiting, etc.

Supports dynamic routing and integrates with Ribbon for load‑balanced calls.

Typical Spring Boot configuration

@SpringBootApplication
@EnableZuulProxy // enables Zuul and registers it as a reverse proxy
@EnableDiscoveryClient // optional, to let Zuul discover services via Eureka
public class ZuulGatewayApplication {
    public static void main(String[] args) {
        SpringApplication.run(ZuulGatewayApplication.class, args);
    }
}

# application.yml
zuul:
  routes:
    user-service:
      path: /users/**
      service-id: user-service
    order-service:
      path: /orders/**
      service-id: order-service
Zuul architecture diagram
Zuul architecture diagram

Eureka Service Registry

Purpose

Provides a highly available registry where microservice instances register themselves.

Enables clients to discover service instances without hard‑coding host/port.

Supports multiple data‑centers and cross‑region replication.

Core components

Eureka Server : Exposes REST endpoints /eureka/apps for registration, renewal (heartbeat) and lookup.

Eureka Client : Embedded in each service; on startup it registers its metadata (instance ID, IP, port, health‑check URL) and periodically sends heartbeats.

Registry : In‑memory store of all registered instances; can be persisted to a peer node for HA.

Load balancer (e.g., Ribbon) : Consumes the registry to pick an instance based on a load‑balancing rule.

Example server and client setup

# Eureka Server
@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

# Eureka Client (any microservice)
@SpringBootApplication
@EnableDiscoveryClient // registers with Eureka automatically
public class UserServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserServiceApplication.class, args);
    }
}

# application.yml (client)
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/
    fetch-registry: true
    register-with-eureka: true
Eureka architecture diagram
Eureka architecture diagram

Ribbon Client‑Side Load Balancing

Purpose

Distributes outgoing requests across multiple instances of a target service.

Operates entirely on the client, eliminating the need for an external load‑balancer.

Supports pluggable rules: round‑robin, random, weighted response time, zone‑aware, etc.

Key concepts

LoadBalancerClient : Core interface used by Spring Cloud to choose a server.

IRule : Strategy implementation (e.g., RoundRobinRule, WeightedResponseTimeRule).

ServerList : Provides the current list of instances obtained from Eureka or another discovery source.

Configuration example

# Enable Ribbon for a specific service
my-service:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
    ConnectTimeout: 3000
    ReadTimeout: 5000
Ribbon architecture diagram
Ribbon architecture diagram

Feign Declarative HTTP Client

Purpose

Generates type‑safe HTTP clients from annotated Java interfaces.

Integrates with Ribbon and Eureka so that the service-id can be used instead of a concrete URL.

Handles request construction, serialization, deserialization, and error handling automatically.

Typical usage

@FeignClient(name = "order-service", configuration = OrderClientConfig.class)
public interface OrderClient {
    @GetMapping("/orders/{id}")
    OrderDto getOrder(@PathVariable("id") Long id);

    @PostMapping("/orders")
    OrderDto createOrder(@RequestBody OrderCreateRequest request);
}

// Optional custom configuration
@Configuration
public class OrderClientConfig {
    @Bean
    public Logger.Level feignLoggerLevel() {
        return Logger.Level.FULL; // log request/response details
    }
}

// Enable Feign in the application
@SpringBootApplication
@EnableFeignClients // scans for @FeignClient interfaces
public class OrderServiceConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceConsumerApplication.class, args);
    }
}
Feign dynamic proxy diagram
Feign dynamic proxy diagram

Spring Cloud Config

Purpose

Externalizes configuration properties to a central repository (Git, SVN, or local file system).

Supports versioned configuration files, profile‑specific overrides, and runtime refresh.

Clients can pull configuration at startup and, optionally, refresh it without restarting.

Server setup

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

# application.yml (Config Server)
spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/example/config-repo.git
          search-paths: '{application}'
          clone-on-start: true

Client usage

# bootstrap.yml (client)
spring:
  application:
    name: user-service
  cloud:
    config:
      uri: http://localhost:8888
      label: main
      profile: dev

# Enable refresh endpoint
management:
  endpoints:
    web:
      exposure:
        include: refresh

Sleuth Distributed Tracing

Purpose

Automatically adds trace identifiers (traceId, spanId) to logs and messaging headers.

Collects span data for each request and forwards it to a tracing backend such as Zipkin or Jaeger.

Helps visualize request flow across microservices.

Basic integration

@SpringBootApplication
@EnableDiscoveryClient
public class TracedApplication {
    public static void main(String[] args) {
        SpringApplication.run(TracedApplication.class, args);
    }
}

# application.yml
spring:
  sleuth:
    sampler:
      probability: 1.0   # sample all requests (adjust for production)
  zipkin:
    base-url: http://localhost:9411/   # Zipkin collector endpoint
Sleuth tracing flow diagram
Sleuth tracing flow diagram

These components—Zuul, Eureka, Ribbon, Feign, Config, and Sleuth—form a cohesive Spring Cloud ecosystem that simplifies the development, deployment, and observability of scalable microservice systems.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

load balancingservice discoveryapi-gatewaySpring Cloud
Architect Chen
Written by

Architect Chen

Sharing over a decade of architecture experience from Baidu, Alibaba, and Tencent.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.