Mastering Service Fault Tolerance: A Deep Dive into Sentinel for Microservices

Introduction

Microservices isolate single‑responsibility functions into independent sub‑services, reducing coupling but creating cascading failures when a service crashes, potentially causing a system‑wide avalanche. High‑concurrency scenarios also demand degradation to protect scarce resources.

When a service experiences a spike, degrading it prevents excessive resource consumption.

What is Sentinel?

Sentinel, developed by Alibaba, is a lightweight traffic‑control product for distributed service architectures. It provides flow control, circuit breaking, and system load protection. Sentinel consists of two parts:

sentinel‑dashboard – similar to hystrix‑dashboard but more powerful, offering real‑time monitoring and online maintenance of flow‑control and circuit‑breaking rules.

Client integration – each microservice must integrate Sentinel’s client library to report metrics to the dashboard and allow dynamic rule updates.

Deploy Sentinel Dashboard

Download the latest release from the GitHub repository:

https://github.com/alibaba/Sentinel

Run the dashboard jar (default port 8080):

nohup java -jar sentinel-dashboard-1.7.1.jar &

Access the console at http://<em>host</em>:8080 with username and password both set to sentinel.

The dashboard displays flow‑control and degradation rule settings.

Sentinel Support for API Gateways

Sentinel can limit traffic for popular API gateways such as Spring Cloud Gateway and Zuul. Since version 1.6.0, Sentinel includes the Sentinel API Gateway Adapter Common module, which defines gateway‑specific rule entities.

Gateway Flow Rule Fields

The main fields are:

resource : the route name or custom API group name.

resourceMode : indicates whether the rule applies to a gateway route (RESOURCE_MODE_ROUTE_ID) or a custom API (RESOURCE_MODE_CUSTOM_API_NAME). Default is route.

grade : the limiting metric dimension, same as the grade field in generic flow rules.

count : the threshold value.

intervalSec : statistical time window in seconds (default 1 s, only effective for parameter‑based limiting).

controlBehavior : traffic shaping mode – either fast‑fail or warm‑up (default fast‑fail).

burst : extra allowed requests during bursts (effective only for parameter limiting).

maxQueueingTimeoutMs : maximum queuing time in warm‑up mode, in milliseconds.

paramItem : parameter‑limiting configuration, including parseStrategy (IP, Host, Header, URL), fieldName , pattern , and matchStrategy .

Rules can be loaded manually via GatewayRuleManager.loadRules(rules) or registered for dynamic updates with GatewayRuleManager.register2Property(property).

Gateway Flow‑Control Implementation

When a request reaches the API gateway, Sentinel’s filter performs route/API‑group matching, request attribute parsing, and parameter assembly. It then evaluates the configured GatewayFlowRule by converting it into an internal ParamFlowRule and invoking SphU.entry(resource, args). The GatewayFlowSlot checks the rule; if the rule does not target request attributes, a constant is injected to achieve ordinary flow control.

During rule loading, Sentinel always transforms gateway flow rules into hotspot parameter rules, storing them separately in GatewayRuleManager .

Conclusion

Since Sentinel 1.6.0, Spring Cloud Gateway integration enables two dimensions of limiting: route‑based (using the route ID) and custom API‑based (user‑defined API groups). This provides fine‑grained traffic protection for microservice architectures.