Master Spring Cloud Internals (Nacos, Sentinel, Load Balancing) to Ace Interviews and Land Offers

1. Load Balancing Components

Spring Cloud’s load‑balancing solutions are classified into three layers covering the full request path from client to infrastructure:

Client‑side load balancer (e.g., Ribbon – deprecated, and the newer Spring Cloud LoadBalancer which integrates with Spring and supports custom LoadBalancerClient implementations).

Gateway‑side load balancer (Spring Cloud Gateway, built on Netty, automatically integrates Ribbon or LoadBalancer for routing and can apply rate‑limiting, logging, etc.).

Traffic‑access layer load balancer (L4/L7 solutions such as Nginx and LVS/Kubernetes Service, handling public‑facing traffic and high‑concurrency distribution).

A typical production architecture combines these three layers: LVS/Nginx → Spring Cloud Gateway → LoadBalancer , ensuring efficient, reliable end‑to‑end traffic distribution.

2. Rate‑Limiting Component

Rate limiting protects core service paths by sacrificing non‑critical requests. It consists of three core stages: metric collection, decision logic, and trigger actions.

2.1 Metric Collection

Three statistical models are described:

Time‑window counter : Fixed 1‑second windows split into buckets (e.g., 100 ms). Simple, low‑overhead, but suffers from “critical‑value” spikes.

Sliding window (LeapArray) : 1 second divided into many small buckets (e.g., 60 × 100 ms). Provides precise counts without the critical‑value problem.

Token bucket : Tokens are added at a steady rate (e.g., 100 tokens/s) and can accumulate up to a capacity, allowing burst traffic.

Leaky bucket : Requests leave the bucket at a fixed rate; excess requests are rejected, guaranteeing smooth output.

2.2 Decision Logic

Decision criteria include business metrics (QPS, thread count, response time, error ratio) and system metrics (CPU usage, load average, TCP connections). Thresholds are defined per metric, and when exceeded, the corresponding trigger action is executed.

2.3 Trigger Actions

Direct rejection (HTTP 429).

Queueing (using a blocking queue or semaphore).

Cold‑start ramp‑up (gradually increase the token‑bucket rate).

Degradation (return cached/default data instead of failing).

Circuit breaking (OPEN, HALF‑OPEN, CLOSED states).

3. Sentinel Flow‑Control Principle

Sentinel (Alibaba open‑source) implements flow control through a chain of components:

LeapArray → StatisticSlot → FlowSlot forms the core processing pipeline.

3.1 LeapArray – Sliding Window

LeapArray splits a time window into buckets (e.g., 2 buckets of 500 ms for a 1‑second window). Each bucket holds a MetricBucket with LongAdder counters for pass, block, success, exception, rt, curThread, etc. The design avoids global locks; writes use CAS, reads aggregate active buckets.

3.2 StatisticSlot

During entry(), node.addPass() records the request into the current bucket; during exit(), RT and success counts are updated.

3.3 FlowSlot

FlowSlot reads the aggregated metrics from LeapArray and compares them against the configured thresholds (QPS uses pass count; thread‑count uses curThread). If the limit is exceeded, it throws new FlowException() to reject the request.

3.4 Slot Chain

The responsibility chain executes in order:

NodeSelectorSlot → ClusterBuilderSlot → StatisticSlot → FlowSlot → DegradeSlot → SystemSlot

. Each slot has a single responsibility, making the architecture extensible.

3.5 Hot‑Parameter Flow Control

For hotspot parameters (e.g., goodsId), Sentinel creates a per‑parameter token bucket stored in an LRU cache. When a request arrives, the parameter value is extracted, the corresponding bucket is looked up, and a token is attempted to be taken. Success allows the request to pass and the global LeapArray is updated; failure throws ParamFlowException without affecting the global counters.

3.6 Circuit Breaking

Sentinel combines flow control with circuit breaking. Three trigger strategies are supported:

Exception ratio (e.g., >50% of requests in a minute).

Exception count (e.g., >100 exceptions in a minute).

Slow‑call ratio (e.g., >80% of calls with RT ≥ 500 ms).

When a circuit opens, all calls are rejected; in half‑open state, a limited number of probe calls are allowed.

4. Nacos AP/CP Dual Mode

Nacos provides both AP (eventual consistency) and CP (strong consistency) modes by distinguishing instance types:

Ephemeral (temporary) instances – default, use the Distro protocol (AP). Heartbeats are sent every second; if a heartbeat is missed for nacos.instance.heartbeat.timeout (default 15 s), the instance is marked unhealthy and removed after nacos.instance.expire.time (default 30 s).

Persistent instances – use JRaft (CP). Writes go through a Raft leader, are replicated to a majority of nodes, and are persisted to disk, guaranteeing linearizability.

Distro works by partitioning instances among cluster nodes, broadcasting hash summaries every 5 seconds, and synchronizing differences on demand, achieving eventual consistency without a master‑slave architecture.

JRaft follows the classic Raft steps: leader election, log replication, majority commit, and state‑machine application, ensuring that configuration data (e.g., gateway routing rules) is strongly consistent.

5. Configuration‑File Priority

Spring Cloud Alibaba 2021+ adopts a unified priority order: remote > local, profile‑specific > non‑profile, and bootstrap > application. The hierarchy (high to low) is:

Remote Nacos DataId with profile (e.g., user-dev.yaml).

Remote Nacos DataId without profile (e.g., user.yaml).

Local bootstrap‑{profile}.yml (provides Nacos address and service name).

Local bootstrap.yml.

Local application‑{profile}.yml.

Local application.yml.

Remote configuration overrides local files, enabling dynamic updates without restarting services. Profile‑specific files isolate environments (dev/test/prod). Bootstrap files are loaded before application files because they contain essential startup parameters.

6. Service Offline Access

Whether a consumer can still call a service after the provider goes offline depends on the instance type.

6.1 Temporary Instances

Heartbeat loss → instance marked unhealthy after nacos.instance.heartbeat.timeout (default 15 s).

After nacos.instance.expire.time (default 30 s), the instance is removed from the registry.

Consumers cache the instance list locally and refresh it via a 30‑second full pull plus a 1‑second UDP push from the server. The worst‑case stale window is 30 seconds.

During the stale window, a call may hit the dead instance, causing a connection timeout; retry mechanisms (Spring Retry, Sentinel fallback) hide the failure.

6.2 Persistent Instances

Removed manually via console/API or automatically by Raft when a majority confirms the failure.

Consumer cache refresh follows the same 30‑second pull + UDP push pattern.

Transient failures are handled identically to temporary instances.

6.3 Optimization Recommendations

Enable UDP push to reduce stale time.

Integrate Sentinel circuit breaking and Spring Retry to mask brief failures.

Use graceful shutdown (e.g.,

spring.cloud.service-registry.auto-registration.enabled=false

) to mark instances unhealthy before termination.

Shorten the consumer full‑pull interval (e.g., from 30 s to 10 s) for critical services.

By following the above systematic analysis, interviewees can demonstrate deep understanding of Spring Cloud’s underlying mechanisms, provide concrete implementation details, and discuss practical optimization strategies.