治理规则与灰度发布
治理规则如何从 Console 写入、生成版本、发布 active release，并进入客户端发现视图。
pole-control-plane 的治理规则不是简单的“规则表 + 查询接口”。真实实现把控制台管理视图和客户端生效视图区分开：规则本体用于 Console 管理，release 表示一个可发布、可激活、可回滚或可停止灰度的客户端版本。
核心实现入口：
pkg/goverrule/default.go：治理规则 Server 初始化与 interceptor 链。pkg/goverrule/traffic_governance.go：traffic security、traffic mirror、traffic mock 的统一业务模板。pkg/goverrule/interceptor/auth/release.go：发布、查询版本、删除版本、回滚、停止灰度的鉴权入口。plugin/store/mysql/traffic_governance.go与governance_rule_base.go：统一规则存储、release 查询和 active 状态切换。pkg/cache/rules/*：console 视图与 client active 视图的增量缓存。
两类视图
治理规则缓存通常维护两类数据：
- Console 视图：规则本体，用于列表、详情、编辑、删除。
- Client 视图：active release，用于 SDK、xDS、协议适配层向客户端下发生效版本。
例如 TrafficGovernanceCache 内部有两个 map：
ids:ruleID -> TrafficGovernanceRule，对应 Console 管理视图。rules:ActiveKey -> TrafficGovernanceRuleRelease，对应客户端可见 active release。
realUpdate 会分别调用 loadRules 和 loadRelease，再执行 setRulesConsole 与 setRulesClient。release 如果不是 active，或者已经被删除，就会从客户端视图移除。
创建与更新
pkg/goverrule/traffic_governance.go 把 traffic security、traffic mirror、traffic mock 收敛成 trafficGovernanceSpec。业务函数只保留资源差异：
- resource 类型。
- proto spec 与内部
TrafficGovernanceRule的转换。 - create/update/delete/get/query store 函数。
- 展示名和 history 记录。
创建规则时会生成：
ID = utils.NewUUID()Revision = revision.NewRevision()
更新规则时会先通过 getOne 确认旧规则存在，再生成新的 Revision。创建、更新、删除都会调用 RecordHistory 记录操作历史。
发布 active release
发布链路由 PublishGovernanceRules 接收 RuleRelease。auth interceptor 会根据 resource 分派到具体权限点：
PublishRouteRulesPublishRateLimitRulesPublishCircuitBreakerRulesPublishFaultDetectRulesPublishLaneGroupsPublishLosslessRulesPublishTrafficSecurityRulesPublishTrafficMirrorRulesPublishTrafficMockRules
collectRuleReleases 会按 RuleRelease.Resource 到对应 cache 里找规则，并把规则 ID、资源类型和 metadata 放进 AcquireContext。权限通过后才调用真实 Server。
存储层的 release 语义由统一表结构表达：
idnamerule_idrule_nameactiveversiondescriptionrelease_typectimemtime
governance_rule_base.go 中的 ExecInactiveRelease 会把同一规则或同一发布条件下旧 release 置为 inactive。ExecuteActiveRule 会在 inactive 后写入新 active 版本，并将 version 设置为当前最大版本加一。
回滚与停止灰度
回滚和停止灰度不是新的规则类型，而是 release 生命周期操作：
RollbackGovernanceRules：把目标版本重新置为客户端 active 视图。StopbetaGovernanceRules：停止灰度发布版本。DeleteGovernanceRules：删除发布版本。GetRuleReleases：查询某个规则的发布版本列表。
这些接口仍然先经过 checkGovernanceRules，也就是按资源类型、操作类型和方法名进行权限检查。
七类流量规则如何放到同一拓扑
官网首页用 client -> control plane -> upstream 解释七类规则，这个表达对应的是规则生效位置，而不是存储结构。真实实现里各规则可以分成三组：
| 规则 | 主要实现入口 | 生效视图 |
|---|---|---|
| 路由 | pkg/goverrule/router_rule.go、pkg/cache/rules/router_rule.go | active router release |
| 限流 | pkg/goverrule/ratelimit.go、pkg/cache/rules/ratelimit_config.go | active rate limit release |
| 熔断 | pkg/goverrule/circuitbreaker.go、pkg/cache/rules/circuitbreaker.go | active circuit breaker release |
| 主动探测 | pkg/goverrule/faultdetect.go、pkg/cache/rules/faultdetect.go | active fault detector release |
| 泳道 | pkg/goverrule/lane_rule.go、pkg/cache/rules/lane.go | active lane group release |
| 无损上下线 | pkg/goverrule/lossless.go、pkg/cache/rules/lossless.go | active lossless release |
| 安全 / 镜像 / Mock | pkg/goverrule/traffic_governance.go、pkg/cache/rules/traffic_governance.go | active traffic governance release |
在客户端视角，所有规则最终都变成“当前服务或调用关系下应该下发的 active 配置”。在控制台视角，它们仍保留各自的编辑模型、过滤条件、权限点和发布历史。
和缓存更新的关系
治理规则的发布不会要求客户端直接查数据库。发布写入 store 后，由缓存层通过两种路径追平：
- 常规 cache 的
realUpdate按LastFetchTime拉取规则和 release。 - 统一治理规则更新器
governanceRuleUpdateCache一次拉取GovernanceRuleUpdates和GovernanceRuleReleaseUpdates，再分发给所有 watcher。
这让发布链路保持事务语义，让读路径保持低延迟。
设计边界
- Rule 是管理态对象，Release 是客户端生效态对象。
- active release 是客户端读路径的核心，不应只看规则本体。
- 版本号由存储层 release 操作推进，规则本体的
Revision用于资源变化识别。 - 鉴权在发布、回滚、删除、停止灰度这些 release 操作上同样生效。
- 新增治理规则类型时，至少要补齐业务 Server、store、cache、release、auth resource mapping 和 policy detail 回显。