Understanding Spring Cloud Components: Eureka, Ribbon, OpenFeign, Hystrix, Zuul, Config, and Bus
This article provides a comprehensive overview of Spring Cloud's core modules—including service discovery with Eureka, client‑side load balancing via Ribbon, declarative REST calls using OpenFeign, fault tolerance with Hystrix, API gateway features of Zuul, centralized configuration with Config, and dynamic updates through Spring Cloud Bus—illustrated with diagrams and code examples.
Spring Cloud offers a suite of tools to simplify building resilient, distributed microservice systems. It builds on Spring Boot and provides patterns for service discovery, configuration, load balancing, fault tolerance, and gateway routing.
Service Discovery – Eureka : Acts as a registry where providers (servers) register their metadata and consumers discover services. It supports registration, renewal (heartbeat), fetching registries, cancellation, and eviction, analogous to a real‑world rental agency.
Client‑Side Load Balancing – Ribbon : Runs on the consumer side, fetching the list of service instances from Eureka and applying algorithms such as RoundRobinRule, RandomRule, or RetryRule to distribute requests. Unlike centralized load balancers like Nginx, Ribbon balances traffic within the client process.
Declarative REST Calls – OpenFeign : Wraps RestTemplate calls behind annotated interfaces, automatically integrating with Ribbon for client‑side load balancing. Example code shows a @FeignClient interface and its usage in a controller.
@FeignClient(value = "eureka-client-provider")
public interface TestClient {
@RequestMapping(value = "/provider/xxx", method = RequestMethod.POST)
CommonResponse<List<Plan>> getPlans(@RequestBody PlanGetRequest request);
}
@RestController
public class TestController {
@Autowired
private TestClient testClient;
@RequestMapping(value = "/test", method = RequestMethod.POST)
public CommonResponse<List<Plan>> get(@RequestBody PlanGetRequest request) {
return testClient.getPlans(request);
}
}Fault Tolerance – Hystrix : Provides circuit‑breaker and fallback mechanisms to prevent cascading failures. It isolates remote calls, defines timeout thresholds, and offers fallback methods for graceful degradation.
@HystrixCommand(fallbackMethod = "getHystrixNews")
@GetMapping("/get/news")
public News getNews(@PathVariable("id") int id) {
// call remote news service
}
public News getHystrixNews(@PathVariable("id") int id) {
// return fallback response
return new News("Service overloaded, please try later.");
}API Gateway – Zuul : Serves as the entry point for all microservices, handling routing, filtering, authentication, rate limiting, and more. Configuration examples demonstrate setting a server port, enabling @EnableZuulProxy, defining a global prefix, custom routes, service name masking, and path ignoring.
server:
port: 9000
eureka:
client:
service-url:
defaultZone: http://localhost:9997/eureka
zuul:
prefix: /zuul
routes:
consumer1: /FrancisQ1/**
consumer2: /FrancisQ2/**
ignore-services: "*"
ignore-patterns: **/auto/**Zuul filters can be implemented by extending ZuulFilter. Example pre‑filter records request start time, while a post‑filter logs request URI and duration. A token‑bucket rate‑limiting filter using Guava's RateLimiter demonstrates limiting to two requests per second.
@Component
public class PreRequestFilter extends ZuulFilter {
@Override
public String filterType() { return FilterConstants.PRE_TYPE; }
@Override
public int filterOrder() { return 0; }
@Override
public boolean shouldFilter() { return true; }
@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
ctx.set("startTime", System.currentTimeMillis());
return null;
}
}
@Component
public class AccessLogFilter extends ZuulFilter {
@Override
public String filterType() { return FilterConstants.POST_TYPE; }
@Override
public int filterOrder() { return FilterConstants.SEND_RESPONSE_FILTER_ORDER - 1; }
@Override
public boolean shouldFilter() { return true; }
@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
Long start = (Long) ctx.get("startTime");
long duration = System.currentTimeMillis() - start;
log.info("uri: " + request.getRequestURI() + ", duration: " + duration + "ms");
return null;
}
}
@Component
public class RouteFilter extends ZuulFilter {
private static final RateLimiter RATE_LIMITER = RateLimiter.create(2);
@Override
public String filterType() { return FilterConstants.PRE_TYPE; }
@Override
public int filterOrder() { return -5; }
@Override
public boolean shouldFilter() {
RequestContext ctx = RequestContext.getCurrentContext();
if (!RATE_LIMITER.tryAcquire()) {
ctx.setSendZuulResponse(false);
ctx.setResponseStatusCode(429);
return false;
}
return true;
}
@Override
public Object run() { return null; }
}Centralized Configuration – Spring Cloud Config : Stores configuration files in a shared repository (Git/SVN) and serves them to client applications at startup. Dynamic refresh can be achieved via Spring Cloud Bus, which propagates configuration change events across the cluster.
spring:
cloud:
config:
uri: http://config-server:8888
name: application
profile: devMessage Bus – Spring Cloud Bus : Broadcasts events such as configuration updates to all services, enabling them to refresh @RefreshScope beans without manual restarts.
In summary, the article walks through the essential Spring Cloud components—Eureka, Ribbon, OpenFeign, Hystrix, Zuul, Config, and Bus—showing how they work together to build a robust, scalable microservice architecture.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Top Architect
Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
