rule configuration
To configure cluster flow control rules through the Sentinel console, the console needs to be modified. We provide corresponding interfaces for adaptation.
Starting from Sentinel 1.4.0, we have extracted the interface for pushing and pulling rules to the remote configuration center:
DynamicRuleProvider<T>
: pull ruleDynamicRulePublisher<T>
: push rule
For cluster flow limit scenarios, since each cluster flow limit rule requires a unique flowId, we recommend that all rule configurations be managed through dynamic rule sources, and cluster flow limit rules are generated in a unified place.
We provide a new version of the flow control rules page, which can push rules for the application dimension, and can automatically generate flowId for cluster flow limit rules. Users only need to implement DynamicRuleProvider
and DynamicRulePublisher
interface to implement application dimension push (URL: /v2/flow
).
Note: The default implementation of the push traffic control rule page in the application dimension is only compatible with the old version of the API (batch push valid machines/pull the latest valid machine rules), and is invalid for cluster rules. It is not recommended to use the default implementation in the production environment, and it is recommended to connect to the dynamic rule source.
We provide push and pull rule implementation examples for Nacos, ZooKeeper, and Apollo (under test
the directory). Taking Nacos as an example, if you want to use Nacos as the dynamic rule configuration center, users can extract related classes, and then only need to FlowControllerV2
specify the corresponding bean in to enable Nacos adaptation. The front-end page needs to be manually switched, or the front-end routing configuration needs to be modified (the sidebar.html
flow control rule route can dashboard.flowV1
be changed from dashboard.flow
, and the dialog box of the cluster point link page needs to be modified by itself).
@Autowired @Qualifier("flowRuleNacosProvider") private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider; @Autowired @Qualifier("flowRuleNacosPublisher") private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;
The default Nacos adapted dataId and groupId conventions are as follows:
- groupId:
SENTINEL_GROUP
- Flow control rule dataId:
{appName}-flow-rules
, for example, if the application name is appA, then the dataId isappA-flow-rules
Users can NacosConfigUtil
modify the corresponding groupId and dataId postfix. Users can NacosConfig
configure the corresponding decoder and encoder Converter
provided by default .FlowRuleEntity
Note : The access terminal also needs to register the corresponding dynamic rule source, refer to the cluster flow control rule configuration document .
Cluster flow control management
Note: The client must introduce dependencies related to cluster current limiting (for example, if you need to use cluster current limiting, you need to introduce cluster current limiting client dependencies; if you need to use it as an embedded cluster current limiting server, you also need to introduce cluster current limiting server dependencies) , otherwise it cannot be configured.
The console of Sentinel version 1.4.1 introduces the cluster flow control management page of the application dimension, which can conveniently allocate token servers and view related status from the application dimension. We can click "Cluster Flow Control" on the sidebar to enter the Token Server list page, where we can view all token server lists and related status under the current application:
We can click the "Add Token Server" button in the upper right corner to add a new token server and assign a client:
Token Client list