★ FEATURED ARTICLE 做互联网后端这十几年几乎每隔一段时间就要跟“高可用”打交道。尤其是到了架构评审或者线上故障复盘的时候大家都会把这三个字挂嘴边可用性要几个9RTO控制在多少RPO能不能不丢数据。但真到设计一套高可用方案时我发现不少团队容易走两个极端要么以为多部署几台机器、加个负载均衡就算高可用要么一上来就规划异地多活最后架构复杂度上去了运维根本hold不住连故障恢复流程都没跑通一次。高可用High Availability不是某一个单一技术点而是从架构设计、数据同步、流量管控到故障响应的一套综合治理方案。这篇文章把我这些年做高可用方案设计的思路、选型背后的理由、以及实际踩过的坑一起整理出来给正在做架构设计或者被“提升可用性”需求追着跑的朋友一个参考。即使你刚接触后端架构按文中的思路去理解一套系统也会比单纯看概念清晰很多。1. 先把“高可用”翻译成具体指标和故障场景1.1 可用性指标从99.9%到99.999%每一档都是真金白银说高可用第一步不是选架构而是跟业务方对齐目标。目标用可用性指标来表达业内通常用“N个9”来描述99.9%全年停机时间不超过8.76小时适合内部系统、非核心业务。99.99%全年停机不超过52.6分钟适合大部分互联网在线业务。99.999%全年停机不超过5.26分钟通常只有支付、实时通信等强依赖场景才会提这个要求。这里有一个最容易被忽略的点可用性指标是“全年统计”的平均值它不代表你可以事后铺开计算。比如某个系统平时很稳但大促期间挂了40分钟全年指标可能还勉强在99.99%以内对用户来说却是一场灾难。所以在定指标的同时一定要把“最长单次故障时长”和“一年最多几次故障”单独写清楚否则高可用设计很容易变成事后算账而不是事前约束。从指标落到技术设计核心落在两个角色上MTBF平均无故障时间和MTTR平均恢复时间。可用性 MTBF / (MTBF MTTR)。这个公式看着简单实际指导意义很强想提高可用性要么延长不出故障的时间增强冗余、预防缺陷要么缩短恢复时间可观测性、快速回滚、故障自动转移。很多团队只在“增强冗余”上使劲忽略了MTTR结果是故障照样出恢复全靠人工可用性自然上不去。1.2 故障从哪来单点、流量、依赖、软件缺陷、人为失误只有把故障来源梳理清楚才知道高可用设计要堵哪些口子。我归纳了五类最常见的故障源单点故障某台机器、某个进程、某份存储是唯一的它一挂整个链路就断。这是高可用设计最先要消除的东西。流量突增平时抗5000 QPS的系统突然被热点事件打到5万 QPS。流量不是慢慢涨上来的往往一两分钟之内就把系统打垮。依赖故障系统本身很健康但下游接口超时或报错整个调用链跟着卡死。这类故障最容易引发连锁反应也是重试风暴的重灾区。软件缺陷发布了一个有bug的版本或者某个逻辑在极端数据下触发死循环。此类故障很隐蔽通常线上才会暴露。人为失误配置写错、误删表、回滚错版本。有统计显示相当比例的故障根源是变更操作这也是高可用方案一定要包含变更管理和自动化校验的原因。把这些故障来源跟设计手段映射起来就很清晰了架构上消单点容量上扛流量容错上挡依赖故障发布与变更上防人为事故。任何一环缺失可用性都很难真正达标。2. 架构层设计靠冗余和隔离撑起可用性底盘2.1 无状态服务高可用的第一课是“状态外置”在微服务和分布式架构里最先要做也最容易做的是“无状态化”。所谓无状态是指服务实例不保存跟用户请求相关的业务数据谁来处理这个请求结果都一样。最典型的反例是早期很多单体应用用Session存登录态如果用户第一次请求落在A机器第二次请求落到B机器登录态就丢了。这本质上是把状态绑死在单机上造成了隐性的单点。无状态化的标准做法是把状态下沉到集中式存储Session放到Redis或独立的会话服务里文件放到对象存储任务进度放到数据库或消息队列。做完这一步服务实例才能真正变成“可替换的零件”——随便加机器、随便摘机器流量随便调度都不会影响业务正确性。这也是水平扩展的前提只有无状态的服务扩容才只是加实例和调负载均衡配置不需要做数据迁移。实操中有一个容易忽略的细节很多服务号称无状态却在本地磁盘落了缓存文件或是在进程内存里放了业务流程中间数据。一旦出现发布、重启、缩容这些数据就丢了。所以架构评审时我通常会对团队提一个问题这台机器如果现在立刻被销毁你的业务还能不能正常继续只要有一丝犹豫就说明状态没有完全外置。2.2 负载均衡选型四层、七层和健康检查的讲究状态外置之后就需要把流量合理分发到多台实例上。负载均衡是高可用架构里最基础的冗余调度器它可以分多层部署DNS层负载通过域名解析到多个入口IP实现最基本的流量分散。它的生效依赖DNS缓存刷新故障切换通常有分钟级延迟不适合作为唯一的高可用手段。四层负载均衡工作在传输层基于IP和端口转发常见实现有LVS、内核IPVS等。性能极高适合在最前端扛大流量入口。七层负载均衡工作在应用层能识别HTTP协议支持更细粒度的路由规则。Nginx、Envoy、各类云负载均衡都属于这一类功能丰富适合做业务流量调度。在真正的高可用链路里通常是多层LB配合最外层用四层LB扛流量入口内部用七层LB做业务路由后端挂服务实例组。无论哪一层健康检查都是关键中的关键。健康检查不能只检查“进程是否活着”更要检查“服务是否真的能处理请求”。我见过不止一个案例进程明明活着但线程池打满、数据库连接耗尽健康检查依然返回正常流量照常打进来把故障实例硬生生拖死。健康检查还有一个容易踩的坑检查频率和超时设置。频率太高会给服务造成不必要的压力频率太低则故障感知过慢。我习惯把健康检查间隔设在3到5秒连续失败2到3次就把实例摘掉连续成功2次再恢复上线同时配合请求层面的错误率做兜底防止健康检查本身误判。2.3 同城多活与单元化多活架构不是越高越好如果说负载均衡解决的是“实例挂了”的问题那机房级别的故障就需要多活架构来解决。常见方案有两种同城双活和异地多活。同城双活指的是在一个城市内两个机房同时承接流量两边数据实时同步任何一个机房出问题流量可以秒级切换到另一个。它的优点是时延低、数据同步相对容易因为同城专线时延通常在1到2毫秒内数据库同步延迟可控。这是多数互联网公司优先考虑的高可用形态。异地多活则复杂得多机房距离远专线时延可能几十毫秒甚至上百毫秒数据实时同步非常困难还会面临数据冲突、时钟偏差、网络分区导致脑裂等一系列问题。真正做异地多活通常要求业务做单元化改造把用户按维度比如用户ID哈希划分到不同单元每个单元包含完整的一套应用和数据库单元之间只同步必要的用户数据。这个改造涉及路由、数据、缓存、消息队列等方方面面成本极高非核心业务一般不建议一上来就搞。我自己对多活方案的态度是先算清楚“机房级故障发生的概率”和“业务对恢复时间的要求”再决定要不要上多活。很多业务把数据和服务部署在一个机房的不同可用区其实已经能覆盖绝大多数故障场景。异地多活是锦上添花不该成为所有系统的默认选项否则只会用极高的成本去解决一个低概率问题同时引入更多因复杂度带来的新故障。2.4 缓存层高可用Redis挂了怎么办缓存是互联网系统扛高并发的利器但缓存本身也是高可用设计中容易翻车的一环。很多系统把热点数据全部放在Redis里一旦Redis集群出现大面积故障流量会穿透到数据库数据库瞬间被打垮整个系统雪崩。这个场景几乎每个大流量团队都经历过所以缓存高可用必须单独设计。常规做法是Redis主从加哨兵或者直接上Redis Cluster。主从加哨兵适合缓存量可控的场景哨兵负责监控主节点状态主节点故障时自动把从节点提升为主节点Redis Cluster则通过分片把数据分布到多个主节点上每个主节点带多个从节点既能扩展容量也能在主节点故障时做从节点提升。但缓存高可用还有一个更隐蔽的问题缓存雪崩和缓存击穿。缓存雪崩指大量缓存Key在同一时间过期请求全部落到数据库缓存击穿指某个热点Key过期瞬间大量请求同时打到数据库。应对手段也很成熟过期时间加随机抖动、热点数据不过期、用互斥锁或分布式锁控制回源请求。我见过太多团队把精力放在Redis集群本身的高可用上却忽略了缓存策略层面的雪崩问题最后集群稳得很数据库却被回源流量打崩了。高可用设计一定要把缓存层和数据库当成一个整体来看。3. 数据层高可用最难啃也最不能出错的骨头3.1 主从复制与自动切换数据库不挂从哪谈起服务层可以靠加实例、加负载均衡解决但数据库是有状态的数据只有一份或少数几份复制天然就是高可用设计里最难的部分。以最常见的MySQL主从架构为例主库承担写流量从库承担读流量和备份主库故障时将从库提升为新的主库。主从复制的高可用设计中有几个关键点必须考虑清楚。第一复制模式的选择。传统异步复制性能好但主库宕机时已经提交到主库但还没来得及同步到从库的数据会丢失RPO不为零。半同步复制通过让主库等待至少一个从库确认收到binlog再返回事务提交成功可以做到不丢已提交事务但会增加写入延迟。对于金融、订单类强一致业务RPO是硬指标半同步基本是底线要求。第二主从切换不能靠人肉。人工切换从察觉故障到执行操作动辄十几分钟期间业务全部写入失败。现在业界多用高可用管理组件自动完成主从探测、切换和VIP漂移把切换时间压缩到秒级或几十秒级。切换是高风险动作我的经验是高可用组件用起来没问题但每年至少要手动演练一次主从切换确认从库数据完整性、应用重连逻辑、以及切换后的流量恢复都符合预期。第三读写分离带来的延迟问题。主库写完从库因为复制延迟还没看到数据应用立刻去读从库就可能读到旧数据。很多团队顺手做了读写分离结果引入一堆“刚写完就读不到”的问题。解决思路通常有几种刚写入的数据强制走主库读、敏感业务关闭读写分离、或用中间件做同步等待。这里没有标准答案要根据业务容忍度取舍但一定要在方案设计阶段就明确而不是等线上出现不一致再补。3.2 存储与备份没有恢复演练的备份等于零数据库高可用还有一个经常被忽视的底座可靠的备份与恢复机制。分布式系统里数据因误操作、软件bug被批量删除或篡改不是靠主从复制能解决的——因为删除操作同样会被复制到所有节点。只有备份能在这种场景下救你。备份策略建议遵循3-2-1原则至少准备三份数据副本存储在使用至少两种不同介质上其中至少一份存放在异地进行容灾。日常做法是全量备份加binlog增量备份全量周期根据数据量决定增量备份实时采集。这里最核心的一条建议是备份一定要做恢复演练不能只看到备份成功就算完。我见过不止一个团队备份任务每天都显示成功真到需要恢复时才发现备份文件损坏、恢复流程没人跑过、恢复耗时远超RTO。备份的价值只在恢复那一刻才能兑现所以定期做一次完整的恢复演练比备份任务本身更重要。3.3 数据分片把单库瓶颈拆开也把故障面拆小当单库容量和写入性能到达瓶颈时数据分片Sharding是横向扩展的必经之路。分片把一张大表按分片键比如用户ID、订单ID分布到多个数据库实例上每个实例只负责一部分数据。分片设计中最难的是分片键的选择。选得好数据分布均匀查询路由清晰扩容方便选得不好会出现数据倾斜某个分片数据特别多、跨分片查询、扩容要迁移大量数据。我的建议是分片键不能只看“当前哪个字段用得多”要考虑业务未来三五年的增长趋势以及是否有自然均匀分布的属性。一个常见的反面案例是把订单表按订单号分片结果运营侧经常按用户ID跨分片查询订单每次查询都扫描所有分片性能完全不可控。从高可用的角度看分片还有一层好处故障面变小。假设单库能扛住的上限是某个值分片之后单个分片故障只会影响一部分用户而不是全站不可用。但也要注意分片引入的中间件或自研路由层本身必须是高可用的否则它就成了新的单点。同时分片后的数据备份、监控、容量管理都要按分片维度独立规划复杂度是实打实增加的。对数据量还没到瓶颈的系统不要为了追求“先进架构”提前分片成本不划算。4. 流量治理与容错把故障挡在业务链路之外4.1 超时与重试最简单的参数最致命的连锁反应高可用方案里超时和重试看似是两个小小的参数实际却是很多线上故障的根源。先说超时。如果下游接口没有设置超时或者超时设置得很大比如30秒一旦下游变慢上游线程就会全部阻塞在等待中导致自身线程池耗尽、健康检查失败最终整个服务雪崩。正确做法是每个依赖调用都设置合理的超时时间并区分连接超时和读超时。连接超时通常设1到3秒读超时根据接口TP99延迟再留出一定余量不能拍脑袋定个大值。再说重试。重试是提高成功率的手段但也是最容易引发重试风暴的地方。假设某个下游服务已经故障上游100个实例集体重试每个请求重试3次相当于把故障服务的流量放大到原来的3倍甚至更多直接让局部故障演变成雪崩式故障。关于重试我的几条硬性经验仅对幂等接口做重试。非幂等操作比如下单、转账重试前必须保证接口设计支持幂等。重试次数控制在1到2次不是越多越好。重试必须配合退避策略比如指数退避加随机抖动避免所有实例在同一瞬间重试。如果下游已经进入熔断状态熔断期间一律不重试直接走降级或快速失败。4.2 限流削峰填谷保护系统不被流量打死流量突增是互联网业务最常见的故障触发器。限流的作用是在系统入口或关键链路上控制请求速率保证进入系统的流量不超过系统能处理的上限。限流算法选型上令牌桶和漏桶是两种经典模型。令牌桶允许一定程度的突发流量适合大多数在线业务漏桶速率恒定适合保护下游脆弱系统。单机限流实现简单但有明显的缺陷如果实例数量很多每台机器的限流阈值需要根据实例数动态分配实例增减时容易出问题集群限流则需要依赖分布式协调组件成本更高但限流效果更准确。我的建议是优先做单机限流加网关层集群限流兜底把两层组合使用。网关层能拦截入口流量保护整个集群单机限流则能在瞬间热点流量进来时保护单实例不被打垮。限流还有一个经常被忽略的维度限流粒度。按IP限流可以防攻击按用户限流可以公平分配资源按接口限流可以保护关键服务按集群维度限流可以保护后端整体容量。很多方案只做了应用层全局限流热点用户或异常流量依然会穿透保护。正确姿势是结合业务特点做多维度限流并给限流配置一个合理的触发阈值——阈值太小会误伤正常用户太大会失去保护意义。这里没有普适公式只能靠压测和历史流量数据来校准。4.3 熔断与降级给故障一个“被拦截”的出口前面提到超时、重试、限流但即使这些都做了下游故障或者依赖异常依然可能穿透到业务层面。熔断和降级就是在这种情况下兜底的两大武器。熔断机制借鉴了电路熔断器的思路当下游错误率达到阈值熔断器打开直接拒绝后续请求快速失败不给下游增加压力经过一段冷却时间后进入半开状态放少量请求探测成功率达到阈值才关闭熔断。熔断的关键参数有三个错误率阈值、最小请求数、熔断恢复时间。错误率阈值设得太低容易误触发太高则起不到保护作用。我一般从10%到20%开始调再根据下游的容错能力做调整。降级则是主动的、有损的容错策略。它的核心思想是系统资源有限优先保证核心链路舍弃非核心功能。比如商品详情页推荐模块挂了就返回空列表不阻塞页面主体评论区在高峰期可以先返回缓存数据延迟更新到最新。降级通常需要一套配置管理系统做到业务开关随时可切换而不是每次都要发版。线上做降级操作时一定要有明确的降级预案规定什么指标达到什么阈值、降哪一层、降多久。否则故障发生时几个人在群里争论“要不要降、降哪个”那一刻的决策时间成本高得吓人。4.4 消息队列的高可用削峰解耦不能变成新的故障点很多高可用方案依赖消息队列做削峰填谷和异步解耦但消息队列本身如果出问题反而会给系统引入新的故障点。生产端发消息失败、消费端积压、队列数据丢失、消费者重复消费这些都是消息队列高可用必须考虑的问题。生产端和消费端的高可用设计里有一个关键指标需要单独盯消息积压量。消费能力跟不上生产速度时积压会持续增长最后导致消息延迟过高业务受影响。高可用方案通常会给消费端配置自动扩容能力或者提前做消费性能压测。另一个容易被忽略的问题是消费者重复消费消息队列的“至少一次”语义决定了消费端必须实现幂等否则重试或故障恢复时同一条消息会被处理多次造成数据重复。我见过一个印象很深的案例某个团队把订单确认消息投递到消息队列消费端做库存扣减结果消息队列集群某节点抖动导致消费重试扣库存逻辑没有做幂等用户只下了一单库存被扣了两次。事后排查发现这个问题不是消息队列的问题而是消费端设计时根本没考虑重复消息场景。高可用方案设计一定要把“故障发生时数据会怎样”想透消息队列的幂等消费就是一个典型场景。5. 可观测性没有数据支撑高可用只是一句口号5.1 监控体系指标、日志、告警三件套高可用设计的目的是应对故障但如果系统内部像黑盒一样故障发生了都说不清发生了什么那就谈不上快速恢复。可观测性建设是缩短MTTR的核心手段我把它拆成三件套。指标监控覆盖系统层CPU、内存、磁盘、网络、应用层QPS、RT、错误率、线程池状态、中间件层连接池、队列堆积、GC频率。应用层指标最好是按接口维度采集这样才能在故障时快速定位是哪个接口出了问题。业界常用Prometheus加Grafana这套组合数据采集和展示都很成熟告警规则也能灵活配置。日志日志要结构化、集中化并且带上足够上下文信息比如traceId、用户ID、参数摘要。分散在各台机器上的日志是灾难必须统一采集到日志中心否则排查故障时只能一台台机器翻效率极低。我习惯在业务关键节点打日志同时要求日志信息能支撑“从入口到出口”的完整还原避免出现“日志打了一堆但关键参数没记”的尴尬。告警告警不是越多越好而是越准越好。告警阈值要基于系统正常水位的数据统计来定避免出现“每天报警一百次但全是误报”的情况——一旦团队对告警脱敏真故障来临时反而没人响应。我的经验是按紧急程度分级P0页面不可用、核心链路错误率飙升走电话或IM强提醒P1容量水位过高、非核心服务异常进值班看板同时每季度清理一次无效告警规则。5.2 链路追踪与故障定位从“系统挂了”到“哪里挂了”单体时代排查问题看一台机器就行分布式架构下一个用户请求会经过网关、多个微服务、缓存、数据库和消息队列任一处异常都会表现为“接口变慢”或“报错”。链路追踪的作用就是把一次请求的完整调用路径串联起来让我们能一眼看到时间消耗在哪个服务、哪个环节。实现原理并不复杂请求入口生成一个全局唯一的traceId在服务调用和中间件访问时透传每个节点记录自己的耗时和状态最终汇聚到链路追踪系统。排查问题时用一条报错信息里的traceId就能搜出整条调用链。链路追踪对高可用最大的帮助是它能把系统的真实依赖关系画出来、找出不合理的串行调用和慢节点也能在上游报错时快速判断是自身问题还是下游拖累。没有这套能力分布式系统的故障定位基本靠猜。5.3 容量规划与压测为故障提前做一次“体检”可观测性除了用于故障时排查还有一个重要用途支撑容量规划。高可用不能只等故障发生后再反应更需要提前知道系统在什么流量下会达到瓶颈。定期做全链路压测是很多团队能扛住大促流量的关键。压测不能只压单个服务要尽可能做全链路的。因为高可用设计里的限流、降级、缓存、负载均衡只有在真实流量经过时才可能暴露问题。压测过程中重点关注每个环节的水位数据库连接数、Redis内存命中率、消息队列堆积量、各个服务的CPU和内存。用压测数据反推出一份容量水位表格明确各核心链路的告警阈值和扩容建议。我第一次带团队做全链路压测时发现一个平时看不出来的问题网关层的连接数配置在流量翻倍后先被打满导致后端集群毫无压力时用户已经被挡在网关外。这种坑不压测根本发现不了。6. 故障演练与实战中踩过的坑6.1 混沌工程用“故意搞破坏”的方式验证高可用高可用方案做了配置上了不等于真正可用。很多系统在“正常情况下”一切安好一旦某个节点真的故障才发现切换脚本有bug、依赖配置写错、自动恢复逻辑没生效。混沌工程的核心思路就是在受控环境中主动制造故障验证系统在真实故障面前的表现。故障注入可以从最小场景开始杀一个服务实例、模拟一台机器宕机、注入网络延迟、让某个下游接口返回500。每次演练要提前设计好场景、预期行为和回滚方案演练后必须输出复盘报告记录“系统表现与预期是否一致”“手工干预了什么”“哪些环节需要改进”。千万别一上来就对生产环境做大规模故障注入先在线下环境跑通再逐步扩展到生产环境的小流量演练。我自己经历过一次印象很深的演练模拟数据库主库宕机后应用层所有写请求全部失败原因是高可用组件能切换数据库但应用配置里的连接地址没有自动跟随切换。演练前谁都没发现这个问题真想等真实故障发生再处理后果不敢想。混沌工程的价值恰恰就在这里把问题暴露在可控成本下而不是等真实事故来教育你。6.2 最容易踩的五个高可用设计“坑”为了把高可用设计的边界说清楚我把实战中反复出现的几个错误做法整理成对照表每条都是真金白银换来的教训常见做法潜在问题推荐方案只做应用层多实例数据库仍是单点数据库一挂全链路瘫痪数据库做主从复制并配置自动切换下游故障后所有服务无限重试重试风暴把故障面扩大数倍限制重试次数配合退避和熔断健康检查只检查进程存活服务已无法处理请求流量仍然进入检查核心接口健康度连续失败自动摘除故障恢复全靠人肉操作MTTR长达十几分钟止损效率低关键故障场景预置自动切换与应急预案备份存在但从不做恢复演练恢复时才发现备份不可用定期执行完整恢复演练纳入常态管理这张表想说明一个核心观点高可用不是单点技术而是端到端的体系。每一层都有对应的风险每个风险都要有对应的治理手段缺一环就会出现“木桶效应”。6.3 高可用设计中的权衡可用性、一致性与成本最后谈一个经常被忽略的问题高可用设计不是无限堆资源而是在可用性、一致性和成本之间做权衡。CAP理论告诉我们网络分区发生时必须在一致性和可用性之间取舍。落到具体业务不同系统对“一致”的要求天差地别支付转账要求强一致RPO接近零社交动态的点赞数偶尔延迟几秒完全可接受。如果对前者用最终一致性方案会出事故对后者用强一致方案又会白白浪费大量性能和成本。我给团队做架构决策时习惯引入一个简单的成本意识每提升一个9的可用性架构复杂度、资源成本和运维难度往往是指数级上升。从99.9%做到99.99%通常只需要多部署、做好主从和自动切换等常规手段但从99.99%做到99.999%可能就需要多活、单元化、全链路压测、变更风控等一整套能力。业务上到底值不值得要跟产品和技术负责人坐到一起把故障损失算清楚再拍板。高可用方案的终点不是“把所有故障都消灭”而是“在可控成本内让故障的影响范围可控、恢复速度可预期”。做了这么多年高可用我越来越觉得它的成败更多取决于团队是否真正敬畏故障、是否愿意在平时投入演练和运维建设而不是选用了多复杂的架构。很多团队的问题不是没有方案而是方案停留在文档里。如果你正负责一套系统的高可用改造我建议从最容易见效的几件事入手把数据库从单点改成主从并配置自动切换、给核心接口加上超时和限流、完善监控告警、做一次故障演练。先让这四个基础动作形成闭环你会发现可用性已经有了明显提升。高可用不是一次性的项目而是反复打磨、持续改进的过程这条路没有终点但每走一步系统都会比前一天更稳一些。
阅读完成 · 觉得有帮助？
