Sentinel console (cluster flow control management)

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 rule
  • DynamicRulePublisher<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.

flow-rule-v2

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 is appA-flow-rules

Users can  NacosConfigUtil modify the corresponding groupId and dataId postfix. Users can  NacosConfig configure the corresponding   decoder and encoder Converterprovided 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:

image

We can click the "Add Token Server" button in the upper right corner to add a new token server and assign a client:

image

Token Client list

 

Guess you like

Origin blog.csdn.net/leesinbad/article/details/132452962