-
我把几个服务实例缩容下线了、本以为流量自然就不会再来,可接下来好几十秒里调用方还在大量报连接被拒绝、请求纷纷失败,我盯着监控纳闷那些实例明明已经停了,最后才想明白实例没了是一回事调用方什么时候知道它没了是另一回事这中间隔着一段谁也绕不开的传播延迟的深度复盘
我的服务部署了多个实例、注册在服务注册中心、调用方通过服务发现拿到实例列表再负载均衡分发请求。某次缩容我把其中几个实例直接停掉,想当然以为实例一停就从可用列表没了、流量自然只去剩下的健康实例。可现实是停掉后好几十秒里调用方持续报错——大量 connection refused、超时、成功率掉一截才慢慢恢复。我确认那些实例真停了却百思不得其解,查调用方日志发现它请求的目标 IP 正是已下线实例。直到…- 0
- 0
-
我们追求微服务把一个本来内聚的业务拆成了十几个小服务,本想解耦独立部署,结果一个下单流程要串着调八个服务、链路又长又慢、改一个小需求要协调好几个服务一起发版、出了问题谁也说不清的深度复盘
当时团队觉得微服务是趋势、拆得越细越解耦越灵活,就把一个本来还算内聚的业务系统拆成了十几个微服务(用户、订单、库存、价格、优惠券、积分、通知、风控……)。拆完上线问题接踵而至:一个下单流程要串行调用七八个服务、链路又长又慢、任一服务抖动整个下单就受影响;改个下单送积分的小需求要同时改好几个服务、协调它们一起发版联调;数据一致性成了噩梦、分布式事务焦头烂额;出问题一个请求跨好几个服务谁也说不清。复盘…- 2
- 0
-
下游换了 IP 发布完成后我们死活连不上、下游明明健康重启自己就好:网络第一步 DNS 缓存导致连旧 IP 刻舟求剑的避坑复盘
这是一次下游明明好好的我却死活连不上的诡异故障。起因是我们依赖的一个下游服务做了一次发布,它换了新机器 IP 变了但对外的域名没变,本来嘛用域名访问的好处就是 IP 可以随便换域名不变。下游发布顺利完成自测一切正常,可就在它发布完成的那一刻我们的服务却开始大面积报错:调用那个下游持续地连接超时或者连接被拒绝。我赶紧检查下游服务确确实实是健康的能正常访问的,我们自己的网络代码也都没动,可我们就是连不…- 2
- 0
-
改个字段要动四个服务:分布式单体避坑复盘
我们把一个几十万行的老单体"成功"拆成十几个微服务,上线时还挺有成就感,可没过几个月就发现不对劲:产品提了个不大的需求——给订单加个备注字段,放单体里半天的活,如今却要同时改订单、用户、通知、聚合查询四个服务,四个仓库四个团队,还因为链式依赖必须按顺序一起上线,排期排了一周半、上线那晚四拨人全在线上盯着。我统计了过去两个月的需求,几乎没有一个能在单个服务里闭环完成的,本该提速的…- 2
- 0
-
慢下游拖垮核心下单:服务雪崩与熔断避坑复盘
一次让我刻骨铭心的雪崩。我们的核心下单服务会调用一个非核心下游——推荐服务,在下单页给用户推荐几个商品,这功能挂了也不影响下单顶多少几个推荐位无足轻重。可某天推荐服务因自身问题变得极慢,响应从几十毫秒涨到十几秒,然后匪夷所思的事发生了:我那本该坚如磐石的核心下单服务竟跟着一起瘫痪——下单大面积超时失败整条业务线告急。一个无足轻重的推荐变慢怎么会把核心下单拖死?顺调用链复盘才看清传导路径:下单服务用…- 0
- 0
-
钱扣了订单却没了:微服务分布式事务避坑复盘
一次让我至今心有余悸的线上事故:下单流程被拆成订单、库存、账户三个微服务依次配合,上线后大多风平浪静,某天财务对账却发现一笔诡异记录——用户的钱被扣了、库存也减了,订单却不存在,客服电话被打爆。扒日志还原现场才明白:那次请求账户成功扣款、库存成功减货,轮到最后写订单时,订单服务的机器恰好抖了一下、数据库连接超时,订单没写成,而前两步已经木已成舟,谁来还?在单体里这三步本可包在一个本地事务里要么全成…- 0
- 0
-
订单系统抗大促架构演进:异步削峰、库存预扣、服务拆分与最终一致性
那年第一次参加大促,我们的订单系统在活动开始后第四分钟就崩了:下单成功率从 99% 直线跳水到不足 30%,数据库连接瞬间打满、CPU 飙到 100%,连商品详情、购物车这些跟下单八竿子打不着的页面也跟着转圈(因为共用一个库被一起拖下水),事后还清出上百个超卖订单要连夜退款道歉,几个人守到凌晨三点才勉强稳住。复盘结论很清楚:不是机器不够,是架构扛不住瞬时洪峰——一个平时跑得好好的同步串行单体,在「…- 2
- 0
-
偶发 502 故障复盘:keep-alive 超时不匹配、缺超时、重试风暴与连接池治理
一套日常 QPS 三四千的微服务系统,网关到订单服务这一跳每隔一阵就冒出大约千分之三的 502,监控曲线上是几个对不上流量高峰也对不上发布的孤立尖刺,客户投诉「点一次失败再点一次就好」,而后端订单服务的业务日志却干干净净——请求根本没进到业务逻辑,就在网络层被掐断了。这篇把这次「查无此错」的偶发故障从头复盘:一开始误判为上游 OOM 重启、白白扩容浪费了四十分钟,直到用 ss 看连接状态、tcpd…- 0
- 0
-
从粗放架构把用户商品订单库存支付营销所有业务不加边界地堆进同一个一百多万行的巨石单体进程任其强耦合成谁也理不清的乱麻改一个边角功能也要重新打包停服部署整个单体一个不相关模块的内存泄漏 OOM 就把整个进程拖垮导致全站一起宕机陪葬 + 拆开后把对端服务的 IP 端口硬编码写死在配置里实例扩容换机宕机就得满世界改配置重启对端进程崩了 IP 还在照样把请求往死实例上送负载也没法均衡 + 各微服务直接把接口暴露给客户端直连鉴权限流日志跨域这些横切逻辑在每个服务重复写一套既散乱又不一致一处有漏洞就是全系统破口后端结构全暴露给客户端 + 服务间清一色同步阻塞 RPC 调用订单要死等库存积分通知营销一长串下游依次返回可用性被乘法级稀释一个发短信服务抖动竟拖垮核心下单洪峰原封不动砸到每个下游 + 按领域拆库后本地事务跨不了多个独立库订单已落库但扣库存失败数据停在订单有了库存没扣的永久错误中间态还撤不回来 + 服务间无超时无熔断的裸调一个下游变慢就把上游线程池占满耗尽上游自己也挂故障顺调用链一级级反向传染雪崩拖垮大半个系统 + 有副作用的接口不做幂等来一次执行一次网络超时调用方重试同一笔支付被重复扣两三次钱同一个单生成好几个重复订单 + 请求跨网关订单用户库存支付好几个进程几台机器日志散落各处无任何关联线索串联断成谁也不认识谁的碎片排查跨服务慢请求只能逐台机器大海捞针拼凑数小时 → 2026 现代微服务架构 按 DDD 限界上下文沿领域边界拆成独立部署独立库独立进程故障隔离的微服务 + 注册中心自注册心跳按服务名动态发现健康实例 + 统一 API 网关收口横切逻辑写一处屏蔽内部结构 + 区分强一致与最终一致非核心下游改消息事件驱动异步消费解耦削峰填谷 + Saga 为每步配补偿操作失败反向回滚保最终一致 + 熔断器监控失败率慢调用超阈值跳闸快速拒绝走降级兜底故障就地隔离 + 全局幂等键加去重表唯一约束保证重复请求只执行一次副作用 + 全链路 TraceID 入口生成沿途透传把跨服务足迹串成完整链路分钟级定位 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
9 人的架构团队 87 天把一套支撑公司整条电商交易主链路、五年里从几万行野蛮生长成一百多万行、几十个开发同时往里提交谁也说不清全貌的巨石单体——用户商品订单库存支付营销所有业务全都长在同一个代码仓库编译成同一个部署包跑在同一个进程里模块之间直接 import 一个类调一个方法进程内强耦合缠成一团乱麻、任何一点改动都要全体陪葬改营销一个边角的活动规则也得把整个百万行单体重新编译打包停服部署几十个开…- 0
- 0
-
从粗放跨网络调用天真当成调一下拿到结果不设超时无脑重试没熔断不限流不隔离 + 不设超时或设几十秒慢下游把调用线程一个个挂死耗尽线程池调用方自己也垮再沿调用链层层传导冲垮整个核心链路雪崩 + 失败就立即原地无脑固定次数猛重试给过载下游火上浇油 N 客户端乘 M 重试瞬间放大数倍把下游彻底打死死亡螺旋还对扣款下单非幂等操作重试导致重复扣款下单 + 下游已经挂了还一根筋拼命猛打无效请求堆积线程全卡在死路上白耗资源还堵死下游恢复 + 对入口流量来者不拒突发洪峰直接把服务自身资源榨干压垮容量内请求也一起玉石俱焚 + 所有下游调用共用一个线程池连接池一个无关紧要的边缘慢下游就把公共池占满连核心订单支付调用也申请不到线程全线瘫痪 + 下游一挂调用方直接把故障原样上抛一个推荐挂掉整个详情页打不开用户连看商品下单都做不了被次要功能绑架核心 + 客户端无脑轮询所有后端不感知健康把请求往挂掉卡死的实例上送间歇性报错忙的更忙 + 网络调用是黑盒出事只能逐个翻日志加 tcpdump 抓包连蒙带猜耗时数小时抓不到是哪一跳慢 → 2026 现代服务间通信韧性工程 每个调用设合理超时加全链路 deadline 剩余预算传播 + 指数退避加抖动加只重试幂等加重试预算绝不放大故障 + 熔断器失败率超阈值快速失败给下游喘息给自己止血加半开试探 + 令牌桶漏桶限流超容量快速拒绝保住核心容量 + 舱壁隔离每个下游独立线程池连接池故障关在单个舱室 + 降级 fallback 下游不可用返回兜底数据保住主流程 + 健康检查加 P2C 最少连接加异常实例自动摘除 + 每跳成功率延迟熔断状态指标加分布式链路追踪 TraceID 串起整条链路 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
9 人的服务治理与中间件团队 87 天把一套由上百个微服务彼此通过网络调用编织而成、五年里服务从十几个长到上百个调用关系织成一张谁也理不清的大网、却一直停留在调用一下拿到结果天真阶段不设超时无脑重试没熔断不限流不隔离的庞大系统——绝大多数地方调用下游压根不设超时或随手填个几十秒形同虚设慢下游一卡调用线程就永久阻塞傻等高并发下线程池被一个个挂死耗尽调用方自己也垮再沿调用链反向层层传导像多米诺骨牌把整…- 0
- 0
-
从古老单体巨石架构 所有业务模块全挤一个进程改一处就全量重新部署 + 模块间直接函数调用编译期强耦合牵一发动全身 + 单库单表所有数据全挤一个库改个表结构全线停机 + 服务间同步阻塞调用一个慢全链路雪崩 + 分布式事务靠 2PC 两阶段提交锁死性能 + 服务地址 IP 端口硬编码换台机器改一堆 + 配置散落硬编码改配置要重新打包发布 + 无 API 网关前端直连各后端认证限流各搞各的 + 系统集成靠共享数据库互相读写表耦合死 + 一次发布全量上线一个模块的 bug 拖垮整个系统 → 2026 现代微服务架构 微服务按业务域拆分独立部署独立伸缩 + DDD 领域驱动设计划分服务边界 + 服务间 gRPC/REST 契约通信 + database per service 每服务独享数据库 + Kafka 异步消息队列解耦削峰 + 事件驱动架构 EDA 发布订阅 + Saga 分布式事务最终一致性 + CQRS 读写分离 + 事件溯源 + 服务注册发现 + Istio 服务网格 + API 网关统一入口 + 配置中心动态刷新 + 绞杀者模式渐进迁移 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
12 位架构与平台工程师 87 天把一套跑了五年的粗放单体巨石架构——订单库存支付用户几十个业务模块全挤在一个进程一个代码库一个数据库、模块间直接 import 互调编译期死死耦合改支付一个方法可能在订单意外炸、一个模块内存泄漏拖垮整个进程、想给大促压力最大的订单单独扩容却只能把整个巨石一起复制白烧资源、所有数据挤在一个库各模块随手跨表 join 互读互写共享库把所有模块焊死改张表全线停机、服务间…- 0
- 0
-
从 巨型单体应用 + 几十张表共享一个数据库 + 服务间全是同步阻塞调用 + 模块边界靠口头约定 + 改一行回归整个系统 + 发布停掉整个应用 + 只有贫血 CRUD 远古架构 → 2026 DDD 领域驱动设计 + 限界上下文 + 微服务独立部署 + 事件驱动架构 + CQRS 读写分离 + Saga 最终一致性 + API 网关 + 每服务独立数据库 现代架构体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学
16 位平台架构工程师 87 天把一套跑了七年的巨型单体大泥球——所有模块塞进一个进程、几十张表共享一个库、服务间全是同步阻塞调用、改一行牵全身、发布停整站——用绞杀者模式零业务中断重构到 2026 年现代架构体系:DDD 限界上下文划清服务边界、微服务每服务独立数据库、事件驱动异步解耦同步调用、CQRS 读写分离应对复杂查询、Saga 补偿保障分布式最终一致、API 网关 + BFF 统一入口,…- 8
- 0
-
从单体 → 600 个微服务 → 事件驱动 + CQRS 架构演进 18 个月踩坑实录:9 个反模式与 11 套修法
某中型电商公司 18 个月架构演进:单体 → 600 微服务 → 事件驱动 + CQRS。踩 9 个反模式:微服务过细分布式单体、同步 RPC 链 12 跳可用性衰减、DB 连接池打爆、跨服务分布式锁死锁、trace 数据爆炸 18TB/天、Istio sidecar P99 +120ms、Kafka schema 漂移、CQRS Read Model 不一致、团队认知负担。落地 11 套修法:D…- 2
- 0
-
DDD 限界上下文划分错误导致 6 个月返工 420 人日的复盘:从按团队 / 按数据库表两次翻车到 Event Storming + 业务能力的正解 + 11 条划分纪律
我们用 240 人日做完一次 DDD 切分,然后 180 人日推倒重做。本文复盘 3 种 BC 划分方法的对比:按组织失败、按数据库失败、按业务能力 + Event Storming 才成功,以及 9 条引申认知。- 0
- 0
-
微服务架构在第三方接口故障时 35 分钟全平台雪崩的复盘:熔断 + 限流 + 降级三件套落地全过程
一次第三方银行接口 100% 超时,通过 pay-gw 把雪崩传染到全部 50+ 微服务,业务全平台不可用 35 分钟。事故后用 7 天引入 Resilience4j + Polly + bulkhead 三件套,3 个月内类似事故 3 次全部局部隔离。复盘三件套的具体参数 + 协同决策树 + 容错反模式 + 可观测性配置 + 8 条容错纪律,适合所有微服务团队抄作业。- 0
- 0
-
.NET HttpClient 单例 + K8s 滚动发布失联 4 小时复盘:SocketsHttpHandler 默认 PooledConnectionLifetime 灾难
.NET 8 计费网关上游服务做了次普通滚动发布,我们的 HttpClient 单例对着已经回收的旧 Pod IP 持续报错 18 分钟。SocketsHttpHandler 默认 PooledConnectionLifetime 是无限,DNS 永不刷新。完整复盘 + 6 步自查清单。- 0
- 0
-
微服务拆得太细的代价:从 30 个服务合并回 8 个的实战复盘 + 模块化单体方案
三年前把单体拆成 30 个微服务,跨服务调用爆炸、数据一致性失控、团队认知负担翻倍。半年前下决心反向重构,用 5 个月时间合并回 8 个服务,故障率降 75%、交付速度提 60%、基础设施成本降 40%。完整复盘合并方法论、shadow traffic 比对、API 兼容层、踩过的坑,以及模块化单体的中间方案。- 2
- 0
-
gRPC 微服务通信完全指南:从一次"ClusterIP LB 让 99% 流量打一个 pod 单机 CPU 95%"看懂为什么 HTTP/2 + protobuf 远远不够
2023 年底我们公司启动微服务全栈改造把单体 Spring Boot 拆成 18 个 gRPC 服务期望解耦和性能提升架构师拍板 gRPC 性能比 REST 快 10 倍 type-safe IDL 优雅我们也信了开搞第一个月顺利上线性能压测确实快 3 倍服务间调用 P99 从 200ms 降到 60ms 大家很高兴但第二个月开始事故连连平均每周 2-3 次 P1 故障凌晨被告警叫醒 4 次然后…- 2
- 0
-
gRPC 微服务通信完全指南:从一次"长连接 hang 死整个支付服务雪崩 5 分钟"看懂为什么写完 proto 远远不够
2022 年我加入一家金融科技公司接手一个 30 个微服务的支付系统服务间用 HTTP REST 加 JSON 通信平时延迟 50ms 一切都还能跑后来业务量从日 100 万订单涨到日 1000 万我们做服务拆分调用链从 3 层涨到 8 层性能问题陆续暴露我决定把核心链路改成 gRPC 觉得 protobuf 加 HTTP2 性能秒杀 REST 切换很顺利灰度第一周性能从 P99 800ms 降到…- 0
- 0
-
OpenTelemetry 分布式追踪工程化完全指南:从一次"P99 8 秒但 Zipkin 只显示 800ms"看懂为什么加 Sleuth 远远不够
2023 年我们公司有一套微服务系统跑在 Kubernetes 上大概 80 个 service 分布在 6 个 namespace 一开始我们用 spring-cloud 的 Sleuth 接 Zipkin 做调用链追踪看起来该有的都有 trace_id span_id 服务调用关系图谱也能画出来看上去很完整但真正发生故障的时候我们才发现一系列问题第一种最让我傻眼某天业务报告下单接口慢 P99 …- 0
- 0
-
gRPC 微服务超时与重试工程化完全指南:从一次"下游慢 800ms 上游 5 个服务全部雪崩"看懂为什么加 timeout 远远不够
2023 年我们公司有一套基于 gRPC 的微服务架构十几个服务互相调用拓扑大概有三四层深接手时表面看挺平静 QPS 不算高响应时间也还行可三个月里我们陆陆续续出了几次让我刻骨铭心的故障第一次是周五晚上一个下游的搜索服务因为索引重建延迟变高从 50ms 涨到 800ms 结果上游所有依赖它的服务的线程池被打满整个调用链上的 5 个服务全部超时雪崩业务被打挂 30 分钟第二次最莫名其妙某个接口压测时…- 2
- 0
-
gRPC 完全指南:从一次"加个字段老服务就错乱、一个慢服务拖垮整条链"看懂 RPC 框架
2023 年我把团队内部几个服务之间的调用从 REST JSON 改成了 gRPC。第一版我做得很省事写了个 proto 文件生成客户端和服务端代码服务之间直接互相调用。本地一测真香比 JSON 快还带类型检查改个字段编译器立刻报错。我心里很踏实gRPC 嘛不就是一个更快带类型的 HTTP 接口。可等它真正上线跑在真实的多服务环境里一串问题冒了出来。第一种我给 proto 加了一个字段重新发布结果…- 0
- 0
-
熔断降级完全指南:从一次"一个边角服务变慢、整个系统被拖垮雪崩"看懂服务容错
2022 年我在做一个电商的商品详情页服务。一个详情页要展示很多东西库存价格用户评论还有猜你喜欢的推荐位。这些数据来自不同的下游微服务我的服务要把它们一个个调过来拼成一个完整的页面返回。第一版我做得很直接在一个函数里同步地一个接一个地调下游全调完了再拼页面。本地一测很顺每个下游都秒回。可上线几个月后的一天整个商品详情页突然大面积超时报错监控告警炸了。我冲上去查最后定位到是那个猜你喜欢的推荐服务因为…- 2
- 0
-
分布式锁完全指南:从一次"加了锁还超卖、库存被扣成负数"看懂分布式锁
2022 年我做一个秒杀活动的库存扣减接口。逻辑很简单:用户下单先查库存够不够,够就扣减一个。第一版在单机上跑,为了防止两个请求同时扣减同一个库存导致超卖,我加了个进程内的锁 threading.Lock。本地压测单机上线都没问题。后来活动流量涨了,运维把服务部署成了三个实例挂在负载均衡后面。某次活动结束我对账,发现一件吓人的事:库存明明只有 100 件,却卖出去了 130 单,超卖了 30 件。…- 2
- 0
微服务
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×