3、变更检测原理：触发机制与事件分类

变更检测是服务画像变更检测系统的第一道关卡。其核心目标是在最短时间内感知到目标服务发生了“值得追踪”的变化，并生成结构化的变更事件，为后续的分布式追踪触发和MTTR复盘口径重算提供精确的时间锚点与上下文。

3.1 变更检测的触发机制

根据生产环境的实际运维经验，变更检测的触发源主要分为三大类：配置变更、代码发布和资源扩缩容。每一类触发机制都有其独特的检测手段和时效性要求。

3.1.1 配置变更触发

配置变更是最容易被忽视但影响范围最广的变更类型。一个数据库连接串的修改、一个限流阈值的调整，都可能引发服务行为的剧烈变化。

• 监听模式：通过配置中心（如Nacos、Apollo）提供的长轮询或gRPC流式监听接口，实时感知配置项的增、删、改操作。
• 快照比对：对于不支持事件推送的配置源（如本地文件），采用定时计算配置文件的SHA256摘要，与上一周期快照进行比对。
• 审计日志：订阅配置中心的审计日志流，捕获“谁、在什么时间、修改了哪个配置项”的完整操作记录。

3.1.2 代码发布触发

代码发布是变更检测中最成熟、最可靠的触发源。每次发布都意味着服务二进制或运行时逻辑发生了确定性变化。

• CI/CD Pipeline Webhook：在构建流水线的“部署完成”阶段，向变更检测系统发送HTTP回调，携带版本号、Git Commit、发布人、发布时间等元数据。
• 容器镜像Tag变更：监听容器镜像仓库（如Harbor、Docker Hub）的Tag推送事件，当服务镜像的Tag（如v2.3.1）发生变化时触发检测。
• K8s Rollout事件：通过K8s Informer机制监听Deployment、StatefulSet的RolloutComplete事件，精确捕获Pod版本切换的时刻。

// 伪代码：基于K8s Informer的代码发布检测
func WatchDeployment(clientset kubernetes.Interface, namespace string) {
    factory := informers.NewSharedInformerFactory(clientset, 0)
    informer := factory.Apps().V1().Deployments().Informer()
    informer.AddEventHandler(cache.ResourceEventHandlerFuncs{
        UpdateFunc: func(oldObj, newObj interface{}) {
            oldDep := oldObj.(*appsv1.Deployment)
            newDep := newObj.(*appsv1.Deployment)
            if oldDep.Generation != newDep.Generation &&
               newDep.Status.ObservedGeneration == newDep.Generation {
                // 检测到一次完整的代码发布
                emitChangeEvent("code_deploy", newDep)
            }
        },
    })
    informer.Run(stopCh)
}

3.1.3 资源扩缩容触发

资源扩缩容通常由HPA（Horizontal Pod Autoscaler）或弹性伸缩策略自动触发，也可能由运维人员手动调整。这类变更虽然不改变代码逻辑，但会显著影响服务的并发能力和资源水位。

• ReplicaSet数量变化：通过K8s Watch API监控目标服务的Pod副本数变化，当spec.replicas或status.availableReplicas发生跳变时触发。
• 节点/实例增减：对于虚拟机或物理机部署的服务，通过云厂商API或CMDB事件流感知实例的上下线。
• 资源规格调整：监控Pod的resources.requests和resources.limits的变更，如CPU从2核调整为4核。

3.2 变更事件的定义与分类

变更检测系统在捕获到原始触发信号后，需要将其标准化为统一的变更事件（Change Event）。一个规范的变更事件是后续所有分析流程的原子数据单元。

3.2.1 变更事件的数据结构

一个完整的变更事件应包含以下核心字段：

3.2.2 变更事件的分类体系

为了便于后续的MTTR复盘口径重算，变更事件需要按照影响范围和风险等级进行分类：

• 按变更对象分类：
  • 逻辑变更：代码发布、配置修改、特性开关切换。直接影响服务行为。
  • 资源变更：扩缩容、节点迁移、资源规格调整。影响服务容量和性能。
  • 拓扑变更：上下游依赖关系变化、服务路由规则修改。影响调用链路。
• 按变更风险分类：
  • P0（致命）：核心服务的全量发布、数据库连接串修改、鉴权策略变更。
  • P1（高）：非核心服务的全量发布、限流阈值调整、缓存策略变更。
  • P2（中）：灰度发布、日志级别调整、非关键配置修改。
  • P3（低）：资源扩缩容、标签修改、注释更新。

3.3 变更检测触发流程总览

下图展示了从原始变更信号到标准化变更事件的完整触发链路：

3.4 变更事件的生命周期管理

变更事件从产生到归档，需要经过明确的生命周期阶段，以确保MTTR复盘口径重算时能够准确关联：

• Created（已创建）：检测到原始信号，生成事件记录，但尚未完成标准化。
• Normalized（已标准化）：完成字段映射、快照比对和风险分级，事件进入待消费队列。
• Triggered（已触发）：事件被分布式追踪系统消费，开始生成对应的Trace数据。
• Resolved（已解决）：关联的故障或异常已处理完毕，事件进入复盘阶段。
• Archived（已归档）：完成MTTR复盘口径重算，事件数据转入冷存储。