Files
2026-07-13 12:37:52 +08:00

6.8 KiB

Control Plugin Spec

Scope

The control plugin type provides runtime traffic and connection control for Nacos server nodes. It covers connection admission, TPS checks, rule parsing, rule storage, and optional metrics collection.

This is a configured single-service plugin. The configured control manager type selects one ControlManagerBuilder. If no type is configured or the selected plugin cannot be loaded, Nacos uses no-limit default managers. Common lifecycle and state rules are defined by the Nacos Plugin Spec, and the bundled implementation is defined by the Default Control Plugin Implementation Spec.

Control is an anti-fragility mechanism. It protects a Nacos node by rejecting or monitoring requests when access to a control point exceeds configured rules. Control plugins must not change resource semantics; they only decide whether the current connection or request may continue.

HTTP and gRPC TPS control hooks are connected through the shared request filtering model defined by the Request Filtering And Runtime Context Spec.

Concepts

Concept Meaning
Control point A named runtime resource that can be measured and limited.
Connection control Admission control for long connections or long polling connections.
TPS control Admission control for request frequency at a named API operation point.
Rule storage Storage that persists rule text for local or external distribution.
Rule parser Parser that converts stored rule text into runtime rule objects.
Barrier Runtime TPS counter and decision component for a point.

Connection and TPS control are independent. A deployment may provide both managers, only one manager, or no manager. A missing manager is treated as no-limit for that dimension.

SPI

Control plugins implement ControlManagerBuilder.

Method Requirement
getName() Stable plugin name.
buildConnectionControlManager() Build connection control manager.
buildTpsControlManager() Build TPS control manager.

External rule storage plugins implement ExternalRuleStorageBuilder and are selected independently through control configuration.

The plugin is exposed to the core plugin manager as type control.

Managers

ConnectionControlManager owns connection rules and returns ConnectionCheckResponse for connection admission. It may load ConnectionMetricsCollector implementations to report connection metrics.

Required connection manager behavior:

Method Requirement
applyConnectionLimitRule(rule) Apply the latest connection rule.
check(request) Return pass or reject for a connection admission request.
buildConnectionControlRuleParser() Optionally override the rule text parser.

TpsControlManager owns TPS points, TPS rules, and barriers. It returns TpsCheckResponse for TPS admission.

Required TPS manager behavior:

Method Requirement
registerTpsPoint(pointName) Register a control point during startup or route scan.
applyTpsRule(pointName, rule) Apply or remove the rule for a point.
check(request) Return pass or reject for a TPS request.
buildTpsControlRuleParser() Optionally override the rule text parser.
buildTpsBarrierCreator() Optionally override time-window and counter behavior.

Rule Model

ConnectionControlRule contains:

Field Meaning
countLimit Maximum total connection count. A value below 0 means no limit.
monitorIpList IP addresses whose connection behavior should be logged in detail.

TpsControlRule contains:

Field Meaning
pointName Control point name.
pointRule Rule detail for the control point.

RuleDetail contains:

Field Meaning
ruleName Rule identifier. A point may have multiple rule names in custom plugins.
maxCount Maximum allowed count in the period. A value below 0 means no limit.
period Counting period. The built-in default is seconds.
monitorType monitor for observation only, or intercept for rejection.

Rule Storage

Rules may come from local disk storage or an external rule storage plugin. Local rules are always available as the safe baseline. External rule storage must fail closed only when the selected control plugin explicitly requires it.

Rule reloads are published through control rule change events and applied by the active managers. Local event dispatch follows the Event Dispatch And NotifyCenter Spec. Control metrics and denied observations follow the Observability Hooks Spec.

External rule storage is selected by:

nacos.plugin.control.rule.external.storage=${controlPluginName}

The local rule storage base directory is selected by:

nacos.plugin.control.rule.local.basedir=${expectedDir}

Custom control plugins may support non-JSON rule text by overriding the rule parser methods. Custom TPS plugins may support sliding windows or other counter algorithms by overriding the barrier creator.

Selection And State

The selected manager implementation is named by:

nacos.plugin.control.manager.type=${controlPluginName}

The selected control plugin must also respect unified plugin state for control:{pluginName} when integrated through the core plugin manager.

Point names are part of the public control contract. New @TpsControl points must use stable names, document the protected operation, and preserve the name when HTTP and gRPC endpoints represent the same semantic operation.

Degradation

Control plugins affect request admission. If plugin construction fails, Nacos must fall back to no-limit managers and log the failure unless the deployment explicitly configures a fail-fast policy.

Runtime plugin exceptions must not corrupt request state. For monitoring-only rules, failures should be logged and skipped. For intercepting rules, the selected plugin owns whether a failure means pass, reject, or fail fast, and that behavior must be documented by the implementation spec.