Practice | sentinel scalability Design

Abstract: sentinel provides a variety of SPI interfaces to provide scalability. You can expand the interface implementation based on the same Sentinel-core, so that you can easily add custom logic to Sentinel. In order to unify the initialization process, the initialization logic extension mechanism abstracts some initialization logic of the initfunc interface, for example, registering a dynamic rule source (example) to register the statisticslot callback function (example) start command center to initialize heartbeat sending. We can set the priority of initfunc execution through annotation.

Sentinel provides a variety of SPI interfaces to provide scalability. You can expand the interface implementation based on the same Sentinel-core, so that you can easily add custom logic to Sentinel.

Initialize logical extension mechanism
To unify the initialization process, we abstracted some initialization logic of the initfunc interface, such:

Register a dynamic rule source (example)
Register the statisticslot callback function (example)
Start Command Center
Initialize heartbeat Transmission
We can set the priority of initfunc execution through annotations. When the application accesses the resource for the first time, the registered initialization function is executed in sequence. If you want to manually trigger initialization in advance, you can call the initexecutor. doinit () function at the corresponding position (such as spring bean). Repeated calls will only be executed once.

Slot chain extension mechanism
Sentinel implements various functions through a series of Slot chains, including building call chains, call data statistics, and rule checks. The order between slots is very important. Sentinel uses slotchainbuilder as the SPI interface to expand the slot chain. You can add custom slots and arrange the slots in sequence, so that you can add custom functions to Sentinel.

For example, if we want to record the current context and resource information after the request pass, we can implement a Simple slot:

Public class demoslot extends act1_processorslot <defanode node> {

@Overridepublic void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count, Object... args)    throws Throwable {    System.out.println("Current context: " + context.getName());    System.out.println("Current entry resource: " + context.getCurEntry().getResourceWrapper().getName());    fireEntry(context, resourceWrapper, node, count, args);}@Overridepublic void exit(Context context, ResourceWrapper resourceWrapper, int count, Object... args) {    System.out.println("Exiting for entry on DemoSlot: " + context.getCurEntry().getResourceWrapper().getName());    fireExit(context, resourceWrapper, count, args);}

}
Then an slotchainbuilder can be implemented. Based on defaultslotchainbuilder, we can add our new slot to the end of the chain (of course, we can also freely combine the existing slot without defaultslotchainbuilder ):

Package com. Alibaba. CSP. Sentinel. Demo. slot;

Public class demoslotchainbuilder implements slotchainbuilder {

@Overridepublic ProcessorSlotChain build() {    ProcessorSlotChain chain = new DefaultSlotChainBuilder().build();    chain.addLast(new DemoSlot());    return chain;}

}
Finally, the Class Name of slotchainbuilder added to the com. Alibaba. CSP. Sentinel. slotchain. slotchainbuilder file under the resources/META-INF/Services Directory takes effect:

Custom slot chain Builder

Com. Alibaba. CSP. Sentinel. Demo. Slot. demoslotchainbuilder
The hot spot throttling module of sentinel uses the Expansion Mechanism of Slot chain to add the hot spot throttling function to the original function chain.

Statisticslot callback
Previously, statisticslot contained too many logics, such as the addpass/addblock logic statistics of common QPS and hotspot QPS are all in statisticslot. Each logic is mixed together, which is not conducive to expansion. Therefore, it is necessary to abstract a series of callback for statisticslot, so that statisticslot can have basic scalability, and decouple a series of logic from statisticslot for clarity. Currently, Sentinel provides two types of callback:

Processorslotentrycallback: contains two callback functions: onpass and onblocked, which are executed when the request passes statisticslot and the request is blocked.
Processorslotexitcallback: contains the onexit callback function, which is executed when the request is exit by statisticslot.
You only need to register the implemented callback to statisticslotcallbackregistry.

Dynamic Rule Source
The Sentinel dynamic rule data source is used to read and write rules from external storage. Sentinel divides the dynamic rule data source into two types: Read data source (readabledatasource) and write data source (writabledatasource), so that the responsibilities of different types of data sources are clearer:

Read data sources are only responsible for listening or polling for reading remote storage changes.
Write data sources are only responsible for writing rule changes to rule sources.
We only need to implement the dynamic rule source by ourselves, and then register it to the corresponding rulemanager, so that we can configure the rule in real time and pull/push it. You can use the initfunc SPI of sentinel to automatically register a dynamic rule source during initialization.

Transport Extension Mechanism
Commandcenter Scalability: You can use different network protocols or libraries to implement the transport API server.
Heartbeatsender is scalable: You can use different network protocols and heartbeat policies to send heartbeats (Report to the console ).
Commandhandler can be expanded: You can implement commandhandler and register it in the SPI configuration file to add custom commands for commandcenter.

Practice | sentinel scalability Design