Demystifying Spring Cloud: From Clusters to Service Discovery and Beyond

1. Introduction

Only a "bald head" can become stronger. I recently started an internship at a company that claims to use Spring Cloud (though the usage seems limited). This article serves as my learning notes on basic Spring Cloud concepts, and I welcome corrections in the comments.

GitHub demo for Spring Cloud: https://github.com/ZhongFuCheng3y/msc-Demo

2. What Are Cluster/Distributed/Microservice/SOA?

For beginners, terms like cluster, distributed, microservice, SOA can feel intimidating, similar to early encounters with aspect‑oriented programming.

Below is a simple explanation of each term.

2.1 What Is a Cluster?

According to Wikipedia, a computer cluster is a set of loosely integrated computers that work closely together to perform computing tasks, often appearing as a single system. Nodes usually connect via LAN, improving speed and reliability.

Key characteristics:

Multiple machines cooperate to complete the same work, achieving higher efficiency.

All machines run identical workloads; if one fails, another takes over.

Example: Two developers ("Xiao Zhou" and "3y") share the same Java project on two servers; if one server goes down, the other continues processing.

2.2 What Is Distributed?

A distributed system is a group of computers that communicate over a network to coordinate their behavior and achieve a common goal.

Example: Separate front‑end and back‑end responsibilities are assigned to different developers, reducing coupling and improving scalability.

Benefits of splitting modules:

Rational resource utilization: low‑traffic modules can run on weaker servers, high‑traffic modules on stronger ones.

Reduced coupling: each module can be developed and scaled independently.

In a distributed setup, a business is divided into multiple sub‑businesses deployed on different servers.

2.3 Cluster vs Distributed

Clusters and distributed systems can coexist, forming a "distributed cluster".

2.4 Distributed / Microservice / SOA

These three concepts are similar; understanding one gives a good grasp of the others.

3. CAP Theory

In a distributed system, the CAP theorem states that you cannot simultaneously achieve strong consistency (C), high availability (A), and partition tolerance (P). You must choose between AP or CP, but not abandon either completely.

C – All nodes have the latest data version (strong consistency).

A – Data is highly available.

P – The system tolerates network partitions.

Examples illustrate how a network partition forces a trade‑off between consistency and availability.

Consistency levels include weak consistency and eventual consistency.

4. Spring Cloud Basics

Spring Cloud simplifies building distributed/microservice systems by providing a suite of tools.

Service discovery: Eureka

Client‑side load balancing: Ribbon

Circuit breaker: Hystrix

Declarative HTTP client: Feign

API gateway: Zuul

Distributed configuration: Config

5. Eureka

Eureka solves the problem of hard‑coded IP addresses by allowing services to register themselves and discover others via service names.

Typical configuration for an Eureka server:

register-with-eureka: false  # do not register itself
fetch-registry: false      # act as registry only

Eureka client can be a provider, a consumer, or both. Registration, heartbeat, and deregistration mechanisms keep the registry up‑to‑date.

6. RestTemplate and Ribbon

Instead of hard‑coding IPs, use RestTemplate together with Ribbon for client‑side load balancing.

// private static final String REST_URL_PREFIX = "http://localhost:8001";
private static final String REST_URL_PREFIX = "http://MICROSERVICECLOUD-DEPT";
@Autowired
private RestTemplate restTemplate;
@RequestMapping(value = "/consumer/dept/add")
public boolean add(Dept dept) {
    return restTemplate.postForObject(REST_URL_PREFIX + "/dept/add", dept, Boolean.class);
}

Ribbon’s default strategy is round‑robin; custom strategies can be defined by implementing IRule.

@Configuration
public class MySelfRule {
    @Bean
    public IRule myRule() {
        return new RandomRule_ZY(); // custom rule
    }
}

7. Hystrix

Hystrix provides circuit breaking and thread isolation to prevent cascading failures (the "snowball" effect) in high‑concurrency scenarios.

Fallback: quickly return an error instead of waiting.

Thread‑pool isolation: each dependency gets its own pool.

Key parameters: sliding window size (20), circuit‑breaker open interval (5 s), error threshold (50%).

7.1 Hystrix Dashboard

Real‑time monitoring of Hystrix metrics helps detect problems early.

8. Feign

Feign offers a declarative HTTP client, integrating Ribbon and Hystrix, allowing remote calls to look like local method invocations.

@FeignClient(value = "MICROSERVICECLOUD-DEPT", fallbackFactory = DeptClientServiceFallbackFactory.class)
public interface DeptClientService {
    @RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
    Dept get(@PathVariable("id") long id);
    @RequestMapping(value = "/dept/list", method = RequestMethod.GET)
    List<Dept> list();
    @RequestMapping(value = "/dept/add", method = RequestMethod.POST)
    boolean add(Dept dept);
}

Fallback factory provides graceful degradation when a service is unavailable.

9. Zuul

Zuul acts as an API gateway, integrating with Eureka for dynamic routing, handling authentication, and providing client‑side load balancing, circuit breaking, and thread isolation.

10. Spring Cloud Config

Config centralizes configuration management for distributed systems, storing files in a Git repository (or SVN) and serving them to clients via REST endpoints.

Benefits include encrypted properties, dynamic refresh with Spring Cloud Bus, and unified configuration across services.