Linux服务依赖治理需理清真实调用关系、分级依赖强度、实施轻量隔离并验证故障容忍能力。通过网络/进程观测确认实际依赖，按强/弱/观测三类设定容错策略，利用cgroup、network namespace、iptables等实现隔离，并通过kill、tc、DNS篡改等手段注入故障验证有效性。
Linux服务依赖治理的核心在于理清调用关系、限制故障传播。不掌握服务间真实依赖，就无法做有效隔离；不做好隔离，一个服务异常就可能引发雪崩。
看清真实调用关系：别只信配置文件
服务依赖不是靠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指向错误地址，测试服务能否优雅失败而非无限重连
- 所有验证结果要记录到运维文档，标注“已验证：订单服务在支付网关宕机时仍可提交草稿”
