DevOps是微服务存续的必要条件，需具备持续交付、可观测性与自动化运维闭环；各服务须独立CI/CD流水线、语义化镜像标签、有序部署策略；须统一分布式追踪、分层指标采集与SLO告警；K8s原生能力不足，需配置分离、服务网格与PodDisruptionBudget；回滚责任必须流程化明确。
DevOps 不是微服务的“配套工具”，而是微服务能活下来的必要条件——没有持续交付能力、可观测性基建和自动化运维闭环，微服务只会快速退化成“分布式单体”。
微服务拆分后，CI/CD 流水线必须按服务粒度独立运行
传统单体应用共用一条流水线，而每个微服务需拥有自己的 build、test、deploy 路径。关键不是“能不能做”，而是“敢不敢让订单服务的失败阻塞用户服务上线”。
- 每个服务的代码仓库应对应唯一一条流水线（如 GitHub Actions 中的
.github/workflows/deploy.yml），触发事件限定为该仓库的main分支推送 - 镜像构建必须带语义化标签，避免用
latest；推荐格式：v2.3.1-20240521-abc7f8d（版本+时间+Git SHA） - 部署阶段禁止跨服务并行更新——哪怕只是两个强依赖服务，也应通过蓝绿或金丝雀控制流量切换节奏，而非同时滚动发布
服务间调用失败时，curl 和日志 grep 已经不够用了
微服务天然放大网络不确定性，超时、重试、熔断等策略若只靠代码硬编码，运维将失去干预能力。可观测性不能只靠 console.log 堆砌。
- 必须统一接入分布式追踪（如 OpenTelemetry SDK），所有 HTTP/gRPC 调用自动注入
trace_id，否则一个 500 错误根本无法定位是下游哪个服务返回的 - 指标采集要分层：基础设施层（CPU、内存）、平台层（K8s Pod Ready 状态）、应用层（
http_client_request_duration_seconds）、业务层（order_create_failed_total） - 告警阈值不能只设“CPU > 90%”，而应关注 SLO 偏离：例如 “过去 5 分钟 /api/v1/pay 的 P99 延迟 > 2s” 触发告警，比资源水位更有业务意义
Kubernetes 中的 Deployment 不等于微服务实例管理的终点
很多人以为把每个服务打成镜像、写个 Deployment 就算完成微服务部署，但实际运维中，配置热更新、密钥轮换、灰度路由、服务发现这些事，K8s 原生对象根本不处理。
- 配置与代码分离：使用
ConfigMap+envFrom或volumeMount，但禁止直接挂载整个 ConfigMap 到容器根目录；敏感配置必须走Secret，且启用immutable: true防止误修改 - 服务网格（如 Istio）不是可选项：当服务数超过 10 个，手动维护
Service+Ingress规则会迅速失控；VirtualService才能真正实现按 header、path、权重做流量切分 -
PodDisruptionBudget必须配：避免节点维护时一次性驱逐多个同服务 Pod，导致短暂性不可用；尤其对有状态服务（如用户会话缓存）更关键
最常被忽略的一点：微服务架构下，“谁负责回滚”这件事必须在 DevOps 流程里明确定义——是开发改完 bug 提 PR 后自动触发？还是运维收到告警后手动执行 kubectl rollout undo deployment/order-service？没有约定，出问题时只会互相等待。
