上周帮朋友排查一个电商后台问题：下单接口突然超时，监控显示订单服务响应时间飙升到8秒，但单个服务CPU和内存都正常。最后发现是服务间调用链里某个认证网关的DNS解析偶尔失败，导致下游几十个微服务轮番重试、雪崩式延迟——不是代码写得烂，是网络保障没跟上。
微服务不是把应用拆开就完事了
很多人以为微服务就是把单体应用按功能切几块，打几个Docker镜像，再扔进K8s就高枕无忧。其实拆得越细，服务间通信就越频繁。一次用户下单，可能要串起商品、库存、用户、支付、风控、通知共7个服务，中间经过网关、服务网格、负载均衡器、防火墙……每跳都可能出问题。
常见网络坑，都在哪？
• DNS缓存过期或配置错误：K8s里Service域名解析慢，导致服务发现卡顿；
• 服务间TLS握手耗时高：尤其在大量短连接场景（比如HTTP/1.1默认不复用），每次建连都要跑完整个TLS 1.3握手流程；
• 网络策略（NetworkPolicy）配得太严：某次运维同学加了一条“只允许80端口入站”，结果健康检查探针走的是8080，服务直接被标记为NotReady；
• 服务网格Sidecar资源不足：Istio默认注入的Envoy容器只给128Mi内存，高并发下频繁GC，反而拖慢主容器。
一个真实配置片段（Istio流量治理）
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: user-service-dr
spec:
host: user-service.default.svc.cluster.local
trafficPolicy:
connectionPool:
http:
http1MaxPendingRequests: 1024
maxRequestsPerConnection: 128
idleTimeout: 60s
outlierDetection:
consecutive5xxErrors: 3
interval: 30s
baseEjectionTime: 60s这段配置不是炫技，它让服务在连续3次5xx后主动摘除异常实例，并限制单连接请求数，防止连接池被慢节点占满。
日常能做的几件小事
• 给所有服务加统一健康检查路径（如 /healthz），并确保它不查DB、不调第三方，只验本地状态；
• 在CI流水线里加网络连通性测试：部署前先curl -I http://auth-service:8080/healthz，不通就直接中断发布；
• 日志里强制打上trace_id和span_id，别等出问题再翻几十个服务的日志；
• 把核心服务的出口流量限速（比如支付服务每秒最多发500个请求到银行网关），避免突发流量打穿对方也反噬自己。
微服务架构本身不保障稳定，它只是把复杂性从代码层转移到了网络和运维层。网络保障不是“加个SLA合同”就能搞定的事，而是每天盯着拓扑图、看连接数曲线、改一行超时配置、多测一次DNS解析的活儿。