为什么微服务架构会带来更多运维复杂度

结论：微服务架构带来更多运维复杂度，根本原因是把单体应用里进程内的方法调用，变成了跨网络、跨进程、跨版本的分布式调用；服务数量每增加一个，配置、部署、监控、告警、链路排查的工作量就按依赖关系成倍叠加，而不是线性增加。

为什么服务数量增加，运维复杂度会成倍上升？

结论：复杂度来自服务之间的调用边，不是服务节点本身。10 个服务两两调用最坏有 10×9/2=45 条边，20 个服务有 190 条边。

单体应用是 1 个进程、1 次部署、1 份日志。拆成 10 个服务后，变成 10 个进程、10 个端口、10 份配置；如果再有 dev、staging、prod 3 套环境，就是 30 份配置。每个服务还要单独选版本、配 CPU 和内存、设副本数、定健康检查路径。运维对象从 1 个变成 30 个，而且任意两个服务之间的网络抖动、超时、重试都会互相影响。

微服务为什么让故障定位变难？

结论：一次用户请求跨 5 个服务，每个服务 3 个副本，日志散落在 15 个实例上，没有链路追踪就无法定位。

做法是：在每个入口生成 trace ID，通过 HTTP header 的 traceparent 或 gRPC metadata 透传；用 OpenTelemetry（跨语言的可观测性标准）采集，后端接 Jaeger 或 Tempo。生产环境采样率设 1%～10%，错误请求 100% 采样。指标用 Prometheus 抓取，每个服务暴露 /metrics，监控四个黄金指标：延迟、流量、错误、饱和度。告警规则从 1 套变成 10 套，还要加依赖告警，否则下游服务挂了，上游先报警，真正根因被淹没。

微服务为什么让发布和回滚更复杂？

结论：单体一次发布覆盖全部功能，微服务一次需求要发 N 个服务，且必须处理新旧版本共存。

举例：服务 A 调用服务 B，B 新增字段。先发 B，保证旧字段仍返回；再发 A，开始读新字段；观察 24 小时；最后发 B 删除旧字段。回滚时不能只回滚 A，要按相反顺序回滚。蓝绿发布需要 2 倍资源，金丝雀发布先放 5% 流量，每 10 分钟扩大 5%，到 50% 后全量。没有 CI/CD 流水线和版本兼容约定，发布窗口会从每周 1 次变成每天多次，人为失误概率上升。

微服务对监控、容量和配置有什么额外要求？

结论：监控对象从 1 个应用变成 N 个服务×M 个实例，容量规划从整体 QPS 变成每个服务、每个连接池、每个线程池。

超时设置要防止倒挂：A 调 B 设 200ms，B 调 C 设 100ms，总超时不能超过上游。重试要加退避和熔断，重试 3 次会让下游流量变成 4 倍。配置中心用 Nacos 或 Apollo，配置变更要支持灰度、回滚、审计。没有配置中心，改 10 个服务的数据库连接串需要登录 10 台机器。

微服务运维复杂度能降低吗？需要哪些基础设施？

结论：能降低，但复杂度从业务团队转移到平台层，不会消失。

需要容器编排 Kubernetes 管调度和自愈；服务网格 Istio 或 Linkerd 管流量、mTLS、重试；日志用 Loki 或 ELK 集中；追踪用 Jaeger 或 Tempo；指标用 Prometheus + Grafana；CI/CD 用 Argo CD 或 GitLab CI。平台本身要人维护，1 个平台团队可支撑 50～200 名研发。少于 5 个服务时，这些设施的成本高于收益。

什么情况下不该上微服务？

结论：团队少于 10 人、日活低于 10 万、业务边界没理清时，单体优先。

拆分信号：每周部署冲突超过 1 次；单次构建超过 10 分钟；团队超过 20 人；某个模块需要独立扩缩容。满足 2 个以上再拆，先拆 1～2 个边界清晰的服务，观察 1 个季度再继续。

微服务运维复杂度来自分布式调用、服务数量、版本组合和可观测性缺口。要上微服务，先把 CI/CD、日志、指标、追踪、配置中心建好，再拆服务；否则只是把单体的问题换成更难查的问题。