4. 变更门禁架构设计：分层架构与数据流

4.3 高可用与容错机制

变更门禁系统一旦不可用，整个部署流水线将陷入阻塞。因此，高可用与容错是架构设计的底线要求。以下从无状态化、多副本部署、熔断降级、数据持久化四个维度展开。

4.3.1 无状态化与水平扩展

触发层、决策层、执行层的核心业务逻辑均设计为无状态，所有状态数据（规则缓存、评分模型、执行记录）统一存储在 Redis 或数据库层。无状态化使得每一层都可以通过 Kubernetes HPA 实现秒级水平扩缩容。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: gate-decision-layer
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: decision-layer
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

4.3.2 多副本部署与故障转移

每一层至少部署 3 个副本，分布在不同可用区（AZ）。当单个副本或单个 AZ 故障时，流量由负载均衡器自动切换到健康副本。决策层使用 Redis Sentinel 或 Redis Cluster 保障规则缓存的高可用。

4.3.3 熔断降级与优雅降级

当依赖的下游服务（如 CMDB、代码仓库 API）响应超时或返回错误时，决策层必须快速失败，避免阻塞整个门禁流程。采用熔断器模式（如 Resilience4j / Hystrix），配置如下降级策略：

• 熔断阈值：10 秒内失败率达到 50%，熔断器打开，后续请求直接返回降级结果。
• 降级结果：当 CMDB 不可用时，使用本地缓存的影响范围数据；当规则引擎不可用时，默认执行“人工审核”策略。
• 半开恢复：熔断 30 秒后允许一个探测请求通过，若成功则关闭熔断器。

4.3.4 数据持久化与幂等性

所有门禁执行记录必须持久化到数据库（建议使用 TiDB 或 PostgreSQL），并建立变更 ID 的唯一索引。执行层在消费消息时，通过 SELECT ... FOR UPDATE 或 Redis 分布式锁实现幂等，确保同一条 DecisionResult 不会被执行两次。

def consume_decision(decision):
    # 1. 检查执行记录表是否已存在
    record = db.query("SELECT id FROM execution_record WHERE change_id = ?", decision.change_id)
    if record:
        return  # 已执行，直接跳过

    # 2. 加分布式锁
    lock = redis.lock(f"gate:exec:{decision.change_id}", timeout=30)
    if not lock.acquire():
        return  # 其他实例正在处理

    try:
        # 3. 再次检查（双重检测）
        record = db.query("SELECT id FROM execution_record WHERE change_id = ?", decision.change_id)
        if record:
            return
        # 4. 执行门禁动作
        execute_action(decision)
        # 5. 写入执行记录
        db.insert("execution_record", change_id=decision.change_id, status="SUCCESS")
    finally:
        lock.release()

4.4 架构设计总结

变更门禁的三层架构通过触发层感知变更、决策层智能评估、执行层可靠动作，实现了变更风险的自动化管控。组件间数据流采用异步消息队列解耦，配合无状态化、多副本部署、熔断降级和幂等消费，确保系统在极端流量和部分故障场景下仍能稳定运行。这套架构已在日均处理 10 万+ 变更的生产环境中验证，门禁决策 P99 延迟控制在 500ms 以内。