部署、可观测性与排障

微服务数量增加后，发布单元、配置、依赖和告警也随之增加。运维必须能回答“现在运行的是哪个版本、依赖谁、变更了什么、用户是否受影响”。

发布闭环

Git 变更
  → CI 测试并构建不可变镜像
  → 更新 Helm/Manifest 中镜像版本
  → Argo CD 同步
  → Readiness 后逐步接流量
  → 观察错误率、延迟、饱和度和业务指标
  → 继续放量或回滚

应用版本、配置版本、数据库迁移和消息 Schema 必须兼容滚动发布时的新旧实例并存。回滚镜像不能自动撤销数据库和外部配置。

每个服务的运行清单

项目	至少应明确
所有权	团队、值班、仓库、文档和升级窗口
依赖	上下游、数据库、缓存、消息、外部接口
资源	requests/limits、容量基线、扩容条件
健康	Startup/Readiness/Liveness 与优雅退出
可观测	RED 指标、结构化日志、Trace、版本和环境标签
恢复	回滚、降级、数据补偿、备份和恢复演练

排障路线

用户现象和影响范围
  → 最近发布/配置/流量变化
  → Gateway 的请求率、错误率、延迟
  → Trace 找到最慢或失败 Span
  → 对应服务实例的资源、日志和依赖
  → 数据库/缓存/消息队列容量与错误

同一故障若所有服务都慢，优先检查共享入口、DNS、网络、身份系统、数据库或节点；只有单版本/单实例异常时，优先比较镜像、配置、节点和流量分布。

必须关联的字段

日志、指标和 Trace 至少统一：

service.name  environment  service.version
cluster  namespace  instance/pod
trace_id  span_id  request/operation

用户 ID、订单号等高基数字段适合在日志/Trace 中按需检索，不应直接作为 Prometheus label，否则会造成时序爆炸。

故障演练

• 单实例被杀时是否自动恢复且不中断服务。
• 下游超时是否触发受控重试、熔断和降级。
• 消息重复、延迟或积压是否可恢复。
• 配置中心、注册中心和身份系统异常时的行为。
• 节点维护、可用区故障和容量不足时的调度。
• 回滚后数据和消息格式是否仍兼容。

详细信号设计、告警和工具落地参见 可观测性。