【从零开始学架构】服务治理思想：从失败场景倒推系统设计

很多人理解服务治理第一反应是工具注册中心、配置中心、网关、限流、熔断、监控、链路追踪。这些当然重要但如果只从工具理解服务治理很容易把它做成一堆技术组件的堆叠——装了一柜子工具系统该崩还是崩。服务治理真正要解决的问题不是系统用了哪些治理工具而是系统上线以后面对失败、压力和变化时能不能继续保持可控。这里有一个常被忽略的前提好的架构设计不是从正常路径出发而是从失败场景倒推。一个系统在开发环境里跑通不代表它在生产环境里可靠。真实的生产里下游会变慢流量会突增数据库会抖动消息会堆积缓存会击穿版本会发布失败数据会出现异常第三方服务也会不可用。如果一份架构方案只写了请求正常时怎么走却没写异常发生时系统怎么活下来那它还只是功能设计不是成熟的架构设计。所以从失败倒推就是本文唯一的题眼。围绕它服务治理要回答五个问题系统能不能发现问题故障能不能被限制住核心业务能不能保住失败以后能不能恢复问题能不能被定位和复盘为了不让这五个问题停留在抽象层面下面我用同一个真实场景贯穿全文一个 ChatBI 系统。用户用自然语言提问系统做意图识别、实体链指、生成 SQL、查询数据再把结果解释给用户。某天上午大模型推理服务开始变慢——这是故事的起点。我们就跟着这一次故障一层一层往下走。第一层发现问题——系统能不能知道自己不健康那天上午大模型服务变慢但监控大盘一片绿色。直到一个小时后业务同事在群里问为什么查询都转圈圈团队才意识到出事了。这就是第一层要解决的问题系统不能靠用户投诉才发现故障。等用户来反馈通常说明问题已经发生了一段时间甚至已经造成了业务损失。要做到提前发现架构师首先要定义什么叫系统正常。健康指标因系统而异——交易系统看下单/支付成功率消息系统看消费延迟和堆积量。对我们这个 ChatBI 来说健康意味着意图识别成功率、SQL 生成失败率、查询超时率、空结果率、用户追问率。关键在于这些指标必须能反映用户是否真的受到影响。这就是 SLI 的意义——SLI 不是一堆技术指标而是系统健康状态的可观测表达。回到那次故障如果大盘里有查询超时率这条曲线它在故障发生的第一分钟就会拉起来根本等不到业务来问。有了指标还要有告警但告警不是越多越好太少故障发现晚太多团队会麻木到直接忽略。真正有效的告警绑定的是用户影响——查询超时率持续超阈值说明体验已经变差这才值得把人从会议里叫出来。这一层最该问清楚的是哪些指标代表用户是否真的受影响哪些告警是噪声应该被收敛掉如果系统不能及时发现自己不健康后面四层都无从谈起。第二层控制影响——别让一个慢点拖垮整条链路发现大模型变慢之后团队的第一反应是赶紧把模型服务修好。但这是错的——第一步不是修好而是先止血。因为线上事故往往不是一个点坏了就结束而是一个点坏了以后继续把整条链路拖垮。在我们的 ChatBI 里故障是这样扩散的大模型响应慢 → 业务服务调用它时没有超时请求一直挂着等 → 线程被占满 → 连接池耗尽 → 连看历史看板这种根本不用大模型的请求也进不来 → 整个系统不可用。本来只是一个依赖慢最后变成全站雪崩。这就是故障扩散。第二层要做的就是限制故障半径超时调用大模型、查询数据库、请求第三方都不能无限等待。没有超时等于把自己的稳定性交给了下游。这次事故的根因恰恰就是缺了一个超时。熔断当大模型连续超时与其让每个请求都去等死不如暂时停止调用、直接走降级——熔断不是放弃而是不让自己和对方一起被拖垮。隔离:问答查询和看历史看板不该共用同一个资源池。否则一个高成本的大模型调用就能耗尽整个系统的线程连不相干的功能一起拖死。控制影响还必须盯住一个地方请求堆积。请求会堆在 HTTP 入口、线程池、连接池、大模型调用队列里。队列只要没有上限系统就会表面还在接请求内部早已处理不过来,最后整体雪崩。这一层最该问清楚的是请求会堆在哪里那个地方有没有上限超过上限以后是拒绝、降级还是转异步有没有想清楚这一层解决的是系统出问题以后能不能避免小故障变成大事故。第三层保护核心——资源不够时先保住谁止住了扩散新的问题来了大模型还是慢资源还是紧张那这有限的资源该优先给谁答案是不是所有功能都同等重要。在我们的 ChatBI 里——用户追问的智能推荐相关问题失败了返回几个默认问题就行。自然语言问答的大模型调用失败了可以降级到固定筛选器、模板查询或者直接让用户看已有看板。但用户的数据权限校验不能降级成假装通过——那是安全底线。所以服务治理必须提前区分核心链路和增强能力核心链路优先保障增强能力允许降级。否则系统在高压下会把宝贵资源消耗在不那么重要的地方真正关键的业务反而被拖垮。降级不是临时拍脑袋而是提前设计好的替代路径哪些功能返回默认值哪些用缓存结果哪些必须失败即阻断都要在架构阶段就说清楚。保护核心还需要限流。限流不是为了拒绝用户而是为了让系统在资源有限时仍然可控。还是用 ChatBI 举例如果不限流一个用户连续提交复杂问题就能同时吃掉大模型 token、查询引擎资源和数据库连接把别的租户全饿死。这时候限流不是体验问题而是公平性和稳定性问题——既要按租户/用户限 QPS也要专门限制大查询、高成本分析这类业务级重负载。这一层最该问清楚的是哪些是核心链路必须保住哪些只是增强体验可以降级单个用户或租户能不能把整个系统拖垮这一层解决的是系统在压力下能不能做取舍而不是一起崩。第四层恢复现场——失败之后能不能回到可信状态熬过了高峰团队决定回滚刚上线的一个版本——结果发现回滚不了这次发布顺带改了数据库字段新代码写进去的数据旧代码读不出来。这就是第四层的价值成熟的服务治理不假设系统不会失败而是假设失败一定会发生并提前设计恢复能力。恢复首先是回滚。很多系统只设计了发布成功的路径没设计发布失败的路径。但真实上线里失败很常见代码有 bug、配置写错、数据库变更不兼容、灰度期间新老版本同时读写数据。所以架构设计必须提前问代码能不能回滚配置能不能回滚数据库变更是否向前兼容、新老版本能否同时运行尤其是数据变更不能只想怎么改过去还要想改坏了怎么回来——是否双写、是否影子表、是否按租户灰度都属于恢复能力的一部分。我们这次的教训就是漏掉了向前兼容这一步。恢复还包括数据修正——这比服务挂掉更危险。有些故障是服务可用但结果不可信:ChatBI 返回了错误的指标口径用户看到的是一个正常的图表但数字本身是错的业务据此做了决策。比起白屏这种看起来正常实则错误才是真正的隐患。所以系统要有数据校验、对账、异常值检测、审计记录和人工修正入口否则数据一旦错了就只能靠临时 SQL 和人工猜测救火。这一层最该问清楚的是发布失败、数据库改坏了能不能快速退回上一个稳定状态数据错了能不能发现、能不能追溯是谁在何时写入、能不能修正并验证这一层解决的是系统失败以后能不能重新回到可信状态。第五层定位与复盘——让一次事故变成系统能力事故平息后复盘团队想还原那一个小时到底发生了什么,却发现查不清——网关、业务服务、大模型、查询引擎、数据库,每个地方都有日志但没有一条贯穿的 trace-id只能靠时间戳和经验拼凑。这就是最后一层要解决的让问题能被定位并推动系统变得更稳。很多团队有监控、有日志、有告警出了问题却仍查不清原因就是这些信息没被串成链路。所以服务治理必须要求关键链路可追踪日志里要有请求标识、用户/租户信息、关键参数摘要、错误码、耗时、下游依赖和返回状态敏感信息脱敏。有了贯穿的 trace-id才能回答这次查询慢到底慢在意图识别、SQL 生成、查询引擎还是大模型那一步。如果只能看到请求失败,看不到失败发生在哪一段系统就根本不可治理。最后还要有复盘机制。复盘不是为了追责而是为了把一次事故沉淀成能力。它要回答为什么没提前发现第一层为什么故障会扩散第二层为什么降级没生效第三层为什么回滚那么慢第四层下一次靠什么机制避免——你会发现一次像样的复盘正好把前四层重新检验了一遍。这一层最该问清楚的是一个请求的完整链路能不能串起来、能不能分段定位到是哪一步出的问题事故之后有没有落地的长期修复动作而不只是一句以后注意这一层解决的是系统能不能从失败中学习而不是反复摔在同一个地方。回到题眼服务治理是一套从失败倒推的系统能力走完这五层再回头看那次 ChatBI 故障就会发现它其实是一根线上的五个点层次能力在那次故障里意味着第一层发现问题能不能在第一分钟就知道大模型变慢了第二层控制影响能不能不让模型慢拖垮整个系统第三层保护核心资源紧张时能不能保住权限校验和看板第四层恢复现场发布改坏了能不能干净地退回去第五层定位复盘能不能查清根因并让下一次不再重演所以服务治理从来不是加监控、加限流、加熔断这么一份工具清单。这些只是手段。它真正的内核是那个贯穿始终的题眼——从失败场景倒推设计并据此建立一套系统能力。它的价值从不在系统顺利时体现而在系统不顺利时体现当下游变慢时能保护自己当流量突增时能限制压力当部分能力失败时能保住核心当发布出错时能快速恢复当事故发生后能定位根因、推动系统变得更稳。这才是服务治理真正要训练的能力不是追求系统永远不失败而是让系统在失败发生时仍然可控、可恢复、可演进。