-
我给一个上线已久的服务改了下消息格式把一个字段重命名顺手就发版了、自测和预发都好好的,可滚动发布刚推到一半生产就开始零星报错有些消息处理失败有些又正常、等全部实例滚完反而又恢复了,排查很久才反应过来滚动发布的那几分钟里新旧两个版本是同时在线的旧实例根本不认识新字段的深度复盘
我维护一个跑了很久的服务、通过消息队列和另一个消费方协作,这次做了个看起来无伤大雅的改动:把消息体里一个字段从 userName 改名成 username 统一命名风格,生产者消费者代码都改了,本地自测预发联调全正常就走正常流程滚动发布上线。结果发布过程中监控抽风:刚开始推新版本一切正常、等滚动发布推进到一半左右消费方开始零星报错(取不到用户名字段 null)、有的消息失败有的又好好的成功失败夹杂…- 0
- 0
-
每次滚动发布都有几分钟大量 502、半夜还莫名其妙被重启,我查到底才发现是 K8s 的就绪探针没配、存活探针又配得太敏感:一次健康检查探针配置失当、把自愈机制配成故障源的深度复盘
我们的服务跑在 K8s 上,出了两个看似不相关的问题:每次滚动发布都有几分钟接口大量报 502/连接被拒,以及有些 Pod 半夜莫名被 Killed 重启(没崩溃没 OOM)。查到底发现根因都在健康检查探针,且是两个相反方向的错:一是没配 readiness 探针,K8s 不知道 Pod 何时就绪、容器一启动就把流量打进来而应用还没就绪所以 502;二是 liveness 探针配得太敏感(time…- 0
- 0
-
一个没有处理 SIGTERM 的服务,每次滚动发布都会硬生生掐断一批正在处理的请求,丢单又报错:一次优雅停机缺失的深度复盘
每次上线滚动重启,监控都准时出现一小撮 5xx 和超时,客服收到零星下单失败投诉,赶上高峰就放大成一大批丢单。根因是服务完全没做优雅停机:部署滚动更新时给老进程发 SIGTERM,而进程没捕获它,被立即终止或宽限期后 SIGKILL 强杀,正在处理的请求被硬生生掐断、连接没关、事务可能没提交。本文讲透优雅停机要解决什么和信号机制,给出捕获 SIGTERM、srv.Shutdown 停接新请求等存量…- 0
- 0
-
我每次发布服务都有一两分钟大量 502、用户骂声一片,可实例明明都起来了,我对着 K8s 健康检查探针的配置排查了大半天的复盘
负责的一个跑在 K8s 上的服务,功能没问题,可每次滚动发布都有一两分钟大量 502/503,用户骂声一片,过一两分钟又恢复。一开始以为是发布的必然抖动,越想越不对:滚动发布不就是为了不中断吗?新实例起来才切流量啊怎么还502?排查大半天才理解 K8s 健康检查探针的门道和我没配 readiness 探针的致命疏忽:没配 readiness 时,K8s 只看进程起没起来判断就绪,进程一启动就切流量…- 0
- 0
滚动发布
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×