14年程序员实战：系统优化与容器编排提效

　　14年程序员实战：系统优化与容器编排提效——这标题不是凑字数，是我去年五月份在杭州某跨境电商中台项目里，用三台旧款Dell R730（2016年产，双E5-2650v4、128GB DDR4、6×4TB SATA）硬扛住日均800万订单查询压力后，运维组长盯着Prometheus看板上QPS从47跳到312时脱口而出的原话。

　　我们把原来跑在物理机上的Spring Boot 2.3.x+MyBatis服务，拆成37个有状态/无状态混合微服务，但K8s集群初始调度策略没动默认——结果Service A调用Service B时，偶尔卡在kube-proxy iptables链路里2.3秒以上；抓包发现conntrack表满溢，且节点间UDP健康检查失败率在凌晨3:17–4:05稳定在11.6%。你信吗？就因为iptables -t nat -L | wc -l 输出值超过127923条——这个数字我手抄了三遍，贴在工位玻璃上。改用IPVS模式后，P99延迟从2140ms压到89ms，但etcd写入毛刺反而多了——后来查清是CoreDNS的autopath插件和flannel的host-gw模式对冲，关掉autopath才稳住。

　　失败案例真有。去年八月上线的订单履约服务，用Argo Rollouts做蓝绿发布，预热流量走的是Istio VirtualService的weight机制，可开发漏写了destination rule的subset标签——结果12%灰度流量直接打进v1版本的老Pod，而那批Pod还挂着未回滚的Redis连接池bug（maxIdle=3，实际并发超57）。监控告警响了47分钟才有人看飞书消息，因为告警级别设成了“warning”。

　　14年程序员实战：系统优化与容器编排提效

　　我坚持认为它优点在“新技术”——不是指K8s或者eBPF本身新，而是新在技术栈组合方式。比如把OpenTelemetry Collector的OTLP exporter直连VictoriaMetrics（非Prometheus），中间跳过Grafana Loki；再比如用containerd的cgroups v2 + systemd slice做CPU bandwidth throttling，比docker run --cpu-quota更准——上周实测同一批Java应用，-XX:+UseContainerSupport开启下，GC停顿时间方差降低63%，但只在CentOS 8.4+内核5.10.155生效，换成Alibaba Cloud Linux 3.2104就反向恶化——这事连阿里云TAM都说“没见过”，文档里压根没提这组合。

文章配图，仅供参考

　　我们还在试chaos-mesh做混沌实验，但发现NetworkChaos对calico-node DaemonSet失效——不是bug，是calico用eBPF代替了iptables后，chaos-mesh的tc规则压根不生效；最后靠手动在host网络命名空间里加tc qdisc才模拟出丢包。这种细节没人写进最佳实践手册里。

　　去年五月份那轮优化，最脏的活是重写了一个Java Agent：用JVMTI hook jdk.internal.misc.Unsafe.allocateMemory，统计每个服务pod的真实堆外内存占用——结果发现HikariCP的connectionTimeout=30000在高负载下会累积23GB堆外泄漏，官方issue#3781至今标着“unconfirmed”。

　　新技术真香，但得敢自己撕开源码看汇编

　　现在正扒Cilium 1.15的BPF map gc逻辑，打算给team提PR——不过昨天编译失败七次，第三次失败时误删了.kube/config，幸好用kubectl get secret -n kube-system coredns -o yaml > /tmp/coredns.bak保住了凭证……这事我暂时不告诉leader。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!