Sentinel

The sentinel-transport module defines the core interfaces for communication between Sentinel monitoring components. It provides the abstractions necessary for a Sentinel monitoring API server and client to interact.

Key abstractions include:

• CommandCenter: The interface for the monitoring API server.
• HeartbeatSender: The interface for sending heartbeat signals from clients.

The module includes various implementations of these interfaces using different protocols and libraries to facilitate monitoring and control in microservice environments.

Sentinel provides a default implementation for cluster-level flow control, which allows for distributed traffic management across multiple service instances. The implementation is divided into three core modules:

• sentinel-cluster-common-default: Contains the common logic, transport protocols, and shared functions used by both clients and servers.
• sentinel-cluster-client-default: The client-side module that integrates with your application. It uses Netty as the underlying transport library to communicate with the cluster server.
• sentinel-cluster-server-default: The server-side module that manages the cluster state and coordinates flow control rules across clients.

The sentinel-demo repository provides comprehensive examples for integrating Sentinel into various environments and extending its functionality. You can use these examples to learn how to implement:

• Core Features: Flow control, circuit breaking, and load protection.
• Data Source Extensions: Configuring Sentinel to use external data sources like File, Nacos, or ZooKeeper for rule management.
• Framework Integrations: Using Sentinel with Dubbo or the Apache RocketMQ client.
• Annotation Support: Leveraging Sentinel's annotation-based configuration.
• Custom Logic: Extending Sentinel's processing pipeline by implementing the Slot Chain SPI to add custom logic.

The UrlCleaner interface is used to normalize URLs to prevent resource exhaustion in Sentinel.

• For REST APIs: You must clean dynamic URLs (e.g., converting /foo/1 and /foo/2 into a unified pattern like /foo/:id).
• To exclude URLs: To prevent certain URLs from being recorded as Sentinel resources, implement UrlCleaner and return an empty string "" or null for those URLs (supported since version 1.6.3).

While Sentinel is primarily known in the Java ecosystem, it provides official support for other languages through dedicated implementations:

• Sentinel Go: For Go applications (github.com/alibaba/sentinel-golang)
• Sentinel C++: For C++ applications (github.com/alibaba/sentinel-cpp)
• Sentinel Rust: For Rust applications (github.com/alibaba/sentinel-rust)

The adapter generates resource names using the following pattern:

{prefix}{METHOD}:{URL}

If you use the default configuration, the prefix is restclient:.

Examples:

• restclient:GET:https://httpbin.org/get
• restclient:POST:http://localhost:8080/api/users

The Sentinel Dubbo Adapter automatically resolves the Dubbo consumer's application name as the caller's name (origin). This allows you to apply flow rules to specific callers.

• Global Flow Control: If the limitApp field in a Sentinel flow rule is set to default, the rule applies to all callers.
• Caller-Specific Flow Control: If limitApp is set to a specific identifier (e.g., the service name of consumer B), the rule will only trigger for that specific caller.

Customization: You can customize how the origin is parsed by implementing the DubboOriginParser interface and registering it to DubboAdapterGlobalConfig.

The adapter automatically resolves the SOFARPC consumer's application name as the caller's name (origin). This allows you to apply flow control rules to specific callers using the limitApp field in a Sentinel flow rule.

• Default Behavior: If limitApp is not configured (set to default), flow control applies to all callers.
• Caller-Specific Behavior: If limitApp is set to a specific service name (e.g., service-b), the flow rule will only apply to requests originating from that specific service.

Sentinel protects Dubbo resources at two levels of granularity. When defining rules in Sentinel, use the following resourceName formats:

1. Service Interface: Use the fully qualified interface name.
   • Format: interfaceName
   • Example: com.alibaba.csp.sentinel.demo.dubbo.FooService
2. Service Method: Use the interface name combined with the method signature.
   • Format: interfaceName:methodSignature
   • Example: com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)

The Sentinel Dashboard serves as the central entry point for configuring and managing flow control and circuit breaking rules. The standard operational workflow for using the dashboard is:

1. Client Integration: Connect your microservices to Sentinel.
2. Machine Discovery: The dashboard automatically detects connected machines.
3. View Resource Chains: Inspect the automatically discovered resource call chains.
4. Configure Flow Control Rules: Set rules to protect your services.
5. Monitor Effects: Observe the real-time impact of the configured rules.