Linux 服务依赖治理需理清真实调用关系、分级依赖强度、实施轻量隔离并验证故障容忍能力。通过网络 / 进程观测确认实际依赖，按强 / 弱 / 观测三类设定容错策略，利用 cgroup、network namespace、iptables 等实现隔离，并通过 kill、tc、DNS 篡改等手段注入故障验证有效性。
Linux 服务依赖治理的核心在于理清调用关系、限制故障传播。不掌握服务间真实依赖，就无法做有效隔离；不做好隔离，一个服务异常就可能引发雪崩。
看清真实调用关系：别只信 配置文件
服务依赖不是靠 red”>systemd Unit 文件里的 Wants/After 或Docker Compose 的 depends_on来定义的，这些只是启动顺序约束，不反映运行时实际通信路径。真实依赖必须从网络和进程层面观测：
- 用 ss -tuln 或netstat -tuln查监听 端口，确认哪些服务真正对外提供接口
- 用 lsof -i -P -n -sTCP:ESTABLISHED 或ss -tunp抓运行中连接，看 A 服务是否真在连 B 服务的 IP:Port
- 对 HTTP 类服务，结合tcpdump -i any port 8080 -w trace.pcap + Wireshark 分析请求来源与目标
- 避免仅凭“它用了 Redis”就默认强依赖——检查代码或日志，确认是缓存降级可用，还是启动即失败
按依赖强度分级，明确故障容忍边界
不是所有依赖都同等重要。应按影响划分三类：
- 强依赖：服务启动失败或核心流程中断（如订单服务连不上 MySQL 主库）→ 必须做健康检查 + 自动熔断
- 弱依赖：功能可降级（如用户头像服务不可用时显示默认图）→ 启动不阻塞，运行时超时设短（≤500ms），失败直接跳过
- 观测依赖：仅用于监控或审计（如日志上报到 Loki）→ 单独线程异步发送，失败不抛异常，不记入主链路指标
用命名空间与资源限制实现轻量隔离
不用上 K8s 也能做基础隔离。Linux 自带机制足够应对多数场景：
- 用 systemd –scope 为关键服务绑定独立 cgroup，限制 CPU、内存上限，防止单个服务吃光资源
- 用 network namespace 隔离测试环境依赖：例如ip netns exec test-env curl http://redis.local:6379，验证服务是否误连生产 Redis
- 对数据库等敏感服务，用 iptables 或nftables限制源 IP 白名单，禁止非授权服务直连
- 禁用 root 权限启动应用，用 User= 和NoNewPrivileges=yes在 systemd unit 中加固
故障注入验证：不测就不算隔离生效
写完隔离策略后，必须主动破坏才能确认是否真的起作用：
- 用 kill -STOP 暂停下游服务进程，观察上游是否快速超时、走降级逻辑，而非卡死或报 500
- 用 tc qdisc add dev eth0 root netem delay 3000ms 模拟高延迟，验证重试与超时配置是否合理
- 临时删除 DNS 记录或修改 /etc/hosts 指向错误地址，测试服务能否优雅失败而非无限重连
- 所有验证结果要记录到运维文档，标注“已验证：订单服务在支付网关宕机时仍可提交草稿”
