企业官网建设流程全解析

高并发这三个字，做后端的人听到耳朵起茧，但真正能把高并发场景下的保障措施讲清楚、落到实处的，其实不多。前阵子我正好把一个核心交易系统从日均几万请求压到秒级上万QPS，过程中把限流、熔断、降级、隔离、缓存、异步化这一整套组合拳完整过了一遍，踩了不少坑，也沉淀出一些能直接复用的经验。这篇就把高并发场景下最核心的保障思路和实战配置拆开揉碎了讲，尤其会结合 Alibaba Sentinel 在微服务流量治理里的落地细节，给正在做系统压测、容量保障或者准备接 Sentinel 的团队一个可参考的路径。

这套东西适合谁？如果你是负责核心接口稳定性、正在被突刺流量打挂过线上，或者领导让你“把系统的抗压能力提上去”但不知道从哪下手，这篇应该能帮你建立完整的保障框架。我会把原理、参数、配置、坑点都铺开，不搞玄学，全是能抄作业的内容。

1. 高并发保障的整体思路：先搞清楚系统是怎么被打挂的

1.1 高并发场景下的三大典型故障模式

先说个很扎心的现象：大部分系统不是慢慢变慢的，而是突然就崩了。我经历过一次典型的线上事故，某个营销活动零点上线，流量在30秒内涨了50倍，数据库连接池瞬间被打满，紧接着服务端出现大量超时，超时又导致上游重试，重试又放大了流量，最后整个服务集群雪崩，页面全部 502。事后复盘发现，系统其实有缓存、有集群、有读写分离，但缺了最关键的一道闸门——流量入口没有做任何保护。

高并发场景下系统被打挂，基本逃不出三种模式：

第一种是资源耗尽型。线程池被打满、数据库连接池被占满、内存被大对象撑爆，属于硬资源被流量堆死。这种最直观，但往往也是最难提前发现的，因为你不知道流量峰值能到多少。

第二种是级联故障型。一个下游服务慢了，导致上游线程全部阻塞等待，接着上游也跟着慢，然后一路传染上去，最后整个调用链全挂。这就是典型的雪崩效应，Hystrix 当初就是为了解决这个问题才诞生的。

第三种是热点集中型。某个商品、某个用户、某条数据突然变成热点，单个缓存 Key 被疯狂读取，单台机器网卡被打满，而其他机器却闲着。这种问题最难处理，因为普通的路由策略把流量分散了，但热点 Key 的流量是没办法均匀分散的。

这三种故障模式，对应到保障措施上就是：限流挡流量、熔断断故障、隔离控范围，再加上缓存和异步化从源头削减压力。一套完整的高并发保障体系，是在这些维度上同时发力，而不是只靠某一个组件。

1.2 保障体系的六大核心维度

我把高并发保障体系拆成六个维度，团队做技术方案时可以对着这个清单自查：

• 流量控制：用限流算法对入口流量进行整形，保证进入系统的请求量不超过系统的承载能力，这是在“源头”保护系统。
• 熔断机制：当下游故障率达到阈值时，快速失败，不再继续调用下游，避免故障级联放大，这是在“调用链”上做保护。
• 降级兜底：当核心链路压力过大时，主动牺牲非核心功能（比如商品详情页的评论数、推荐位），把资源留给核心交易链路。
• 隔离容错：通过线程池、信号量、分组等方式隔离不同业务之间的相互影响，防止一个业务拖垮所有业务。
• 缓存加速：把热点数据放在离用户更近的位置，减少对数据库的直接访问，这是在“数据面”削峰。
• 异步化：把非实时的操作（发短信、写日志、更新库存流水）丢到消息队列里异步处理，削峰填谷。

这六个维度不是孤立的，而是层层递进的关系。我习惯用“水坝”来类比：流量像洪水，限流是上游的拦水坝，决定放多少水进来；缓存和异步化是水库和分流渠，把水先存起来慢慢放；熔断和降级是泄洪闸，水太大时主动放弃一些非核心区域，保核心区域不被淹；隔离则是把整个水系分成多个独立的水库，一个溃堤不会淹掉全部。

后面几章，我会重点讲 Sentinel 在这个体系里承担的流量治理角色，再补上实操配置、规则参数和生产落地细节。

2. 流量治理的底层机制：限流、熔断、降级的原理与选型

2.1 限流算法对比：从固定窗口到令牌桶，Sentinel 用了哪种

限流是整个高并发保障的第一道大门，也是最容易用错的组件。很多团队接 Sentinel 或者 Guava RateLimiter，配个 QPS 阈值就完事了，其实限流算法的选择直接决定流控效果。我在生产中实际比较过四种主流算法，各有优劣。

固定窗口算法最简单：把时间切成一个个窗口（比如1秒），每个窗口内允许通过的请求数是固定的，窗口切换时计数器清零。但有个很明显的问题——临界突变。假设限制100 QPS，第1秒最后100ms通过了100个请求，第2秒开始100ms又通过了100个请求，实际上200ms内打进来200个请求，系统早就扛不住了。固定窗口算法就是这种“窗口边界容易被击穿”的缺陷。

滑动窗口算法做了改进，不是整秒切换，而是把时间切得更细（比如切成10个100ms的小格子），随着时间推移，窗口整体向后滑动，统计最近1秒的请求数。这样能解决大部分临界问题，但本质上还是计数器的思路，无法做到均匀平滑的流量整形。Sentinel 的默认限流模式之一就是基于滑动窗口实现的，适合大多数业务场景。

漏桶算法和令牌桶算法都是平滑限流方案。漏桶的模型是一个固定容量的桶，请求先进入桶里，底部按固定速率漏出，超过桶容量的请求直接丢弃。优点是流量绝对均匀，缺点是无法应对突发流量。令牌桶则相反，桶里装着令牌，请求要拿到令牌才能通过，令牌按固定速率生成，但桶可以积攒令牌，允许一定程度的突发。Guava RateLimiter 的平滑突发模式就是令牌桶思想。

Sentinel 的底层限流统计采用的是滑动窗口，它不是纯令牌桶也不是纯漏桶，而是结合了计数器统计和流量整形策略。实际配置时，如果你的接口能容忍突发，用默认的快速失败模式即可；如果下游数据库只能承受匀速写入，那就用匀速排队模式（对应漏桶思想）。我在生产环境里通常是：读接口用快速失败，写接口和调用外部慢服务的接口用匀速排队。

来看一段 Sentinel 的限流规则配置（这是我在一个订单查询接口上实际用过的配置）：

// 订单查询接口限流：单机 QPS 500，超出直接快速失败 FlowRule flowRule = new FlowRule(); flowRule.setResource("order-query-api"); flowRule.setGrade(RuleConstant.FLOW_GRADE_QPS); flowRule.setCount(500); flowRule.setLimitApp("default"); // 快速失败模式，超出的请求直接拒绝 flowRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_DEFAULT); FlowRuleManager.loadRules(Collections.singletonList(flowRule));

提示：setControlBehavior这个参数很容易被忽略，但它恰恰是最影响用户体验的。快速失败模式下客户端会直接收到异常，必须在网关层统一处理成友好的提示信息，而不是把异常堆栈抛给前端。

2.2 熔断与降级的配合逻辑：什么时候断、什么时候降

熔断解决的是“下游已经不行了，上游别再打了”的问题。我见过不少团队把熔断做成“单纯的下游异常统计”，比如下游调用失败率超过50%就熔断，但这样有一个很大的盲区——只统计了异常，没有统计慢调用。慢调用对系统的伤害往往更大，因为线程会一直阻塞等待，逐步耗尽线程池。

Sentinel 的熔断策略要注意MaxAllowedRt这个参数的设定。我遇到过这样一个案例：一个下游接口平时响应50ms，但网络抖动时响应时间变成5秒，由于并没有抛异常，错误率其实是0，如果只配置了异常比例熔断，根本不会触发。后来改成慢调用比例熔断，设置最大RT为500ms、比例阈值0.5、最小请求数20，抖动一旦持续，熔断立刻生效，这才把上游线程池保住。

熔断器的状态机是经典的关闭 → 打开 → 半开 循环。关闭状态正常放行流量；打开状态直接快速失败，不调用下游；半开状态允许少量探测请求通过，看下游是否恢复，如果恢复了就关闭熔断器，否则重新打开。这里有个容易被忽略的细节：半开状态下放行的探测请求数量，决定了恢复速度。放少了，恢复慢；放多了，故障中的下游可能又被压垮。Sentinel 的MaxHalfOpenRetryNum配置（半开状态允许的探测请求数）默认是1，生产环境我一般调到3到5，太低会导致恢复期过长，太高在极端故障下会给下游补一刀。

降级和熔断是一对孪生兄弟。熔断是“完全断掉”，而降级则是“换一条路走”。比如商品详情页里，推荐位接口超时了，降级方案就是直接返回一个空列表；库存接口挂了，降级方案可以用缓存里的库存数据兜底，哪怕库存数字不是实时精确的，也比用户看到报错强。降级的关键是：必须在设计阶段就准备好降级预案，而不是等线上出问题了再写降级逻辑。

我总结了一套降级的分级策略，在团队内部推广后效果不错：

• 一级降级：非核心功能直接关闭（评论、点赞、推荐位），适合大促预热期主动执行。
• 二级降级：核心功能简化返回（商品信息用缓存、库存给预售数据），适合流量高峰时段。
• 三级降级：保命降级，只保留交易链路的最小可用集合（下单、支付），其他入口全部关闭。

生产上配置熔断降级规则时，建议一步一步来。别一来就上很高深的动态规则推送，先在控制台手工配置，观察一两个大流量周期，再沉淀成代码里的规则文件，最后才接配置中心做动态推送。跳过这个循序渐进的过程，我见过有团队直接在配置中心批量推送规则，结果规则有误导致大规模误熔断，线上事故反而更严重。

3. Sentinel 实战：从接入到规则落地的完整路径

3.1 Spring Cloud Alibaba 快速接入 Sentinel 的完整步骤

Sentinel 是阿里开源的流量防卫组件，它的定位就是微服务场景下的流量治理。相比 Hystrix，Sentinel 的优势在于：支持实时监控控制台、规则可以动态生效、细粒度的资源定义、对 Spring Cloud Gateway 和 Dubbo 都有现成的适配。我们项目从 Hystrix 迁移到 Sentinel 后，最大的感受就是规则调整不用再发版了，直接在控制台改完推下去，几秒钟就生效。

接入分三步走。

第一步，加依赖。如果用的是 Spring Cloud Alibaba，直接引入 Sentinel 的 starter 就能和 OpenFeign、RestTemplate 这些组件自动整合：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> <version>2021.0.5.0</version> </dependency>

第二步，配控制台地址。在application.yml里加上 Sentinel 控制台的连接信息，同时把 transport 端口（默认是8719）开放出来：

spring: cloud: sentinel: transport: dashboard: 192.168.1.100:8080 port: 8719

第三步，定义资源。Sentinel 里的“资源”可以理解为你想要保护的一个入口，比如一个接口、一个方法、一段代码块。最常见的做法是直接在 Controller 方法上加注解：

@RestController public class OrderController { @GetMapping("/order/detail") @SentinelResource(value = "order-detail-api", blockHandler = "detailBlockHandler", fallback = "detailFallback") public OrderDetail detail(@RequestParam Long orderId) { // 核心业务逻辑 return orderService.getDetail(orderId); } // 限流/熔断触发时进入的方法，注意参数要和原方法一致，再追加一个 BlockException public OrderDetail detailBlockHandler(Long orderId, BlockException ex) { return OrderDetail.degradedOrder(); } // 业务异常时的兜底方法 public OrderDetail detailFallback(Long orderId, Throwable t) { log.error("order detail error, orderId={}", orderId, t); return OrderDetail.degradedOrder(); } }

这里有个特别容易踩的坑：blockHandler方法的参数列表必须和原方法一致，并且在末尾追加一个BlockException参数，否则启动时就会报错。另外，@SentinelResource注解只对限流、熔断等系统保护生效，如果业务代码本身抛出异常，默认不会走 fallback，需要单独配置fallback属性。如果想两者都处理，blockHandler处理流控触发，fallback处理业务异常，两个可以同时配置。

3.2 核心规则配置与参数解读生产实践

接入 Sentinel 只是开始，真正的工作量在规则配置。我把生产环境最常用的三类规则拆开讲，都是踩过坑之后总结出来的。

流量控制规则是最基础的。核心参数是resource（资源名）、count（阈值）、grade（限流维度：QPS 还是并发线程数）、controlBehavior（限流效果）。生产上我一般优先用 QPS 做限流维度，因为它直观、好评估。并发线程数限流适合那种“单请求耗时长、系统线程资源珍贵”的场景，比如调用外部 AI 接口，单个请求可能要好几秒，这时候用并发线程数限流能避免大量线程被慢请求占住。

配置阈值的时候，不要拍脑袋定数字，要通过压测拿到系统真实承载能力，再乘以 0.7 到 0.8 作为安全阈值。举个例子，压测发现订单查询接口在单机 4C8G 的配置下，最大能扛住 800 QPS，那生产配置就设成 600，留出 25% 的缓冲区间，防止流量毛刺直接打满。

熔断降级规则里的三个参数需要重点解释：

• grade：熔断策略，分别是慢调用比例、异常比例、异常数。日常用的最多的是慢调用比例和异常比例。
• count：触发阈值。慢调用比例模式下这个是最大 RT（单位毫秒），超过就算一次慢调用；异常比例模式下这个是异常比例，比如 0.5 表示 50%。
• timeWindow：熔断时长，单位秒。熔断打开后持续多久进入半开状态。这个数值要根据下游故障的平均恢复时间设置，如果下游是一个依赖数据库的接口，数据库故障恢复可能需要一两分钟，熔断时长设成 30 秒可能还没等数据库完全恢复就放流量进去了，又触发一次熔断。我一般建议设成 60 秒起步。

下面这套是我在订单支付链路下的降级规则配置，可直接参考：

DegradeRule degradeRule = new DegradeRule(); degradeRule.setResource("order-pay-api"); // 慢调用比例模式 degradeRule.setGrade(RuleConstant.DEGRADE_GRADE_RT); // 最大 RT 为 300ms，超过即算慢调用 degradeRule.setCount(300); // 慢调用比例触发阈值 degradeRule.setSlowRatioThreshold(0.6); // 最小请求数，防毛刺误触发 degradeRule.setMinRequestAmount(20); // 熔断时长 60 秒 degradeRule.setTimeWindow(60); // 半开状态下允许探测请求数 degradeRule.setMaxHalfOpenRetryNum(3); DegradeRuleManager.loadRules(Collections.singletonList(degradeRule));

注意：有一个常见的误配置是setMinRequestAmount设得太小。默认是5，但在低流量场景下（比如凌晨订单少），5个请求里只要有3个慢调用，就会以60%的慢调用比例触发熔断，这就是典型的数据量太少导致的误判。生产上这个值我最低设到20。

系统保护规则是 Sentinel 的另一个特色，它不针对某个具体接口，而是面向整个系统的自适应保护。核心思路是：根据系统的 Load、RT、线程数、入口 QPS 等维度，自动判断系统是否处于危险状态，如果是就限制入口流量。我建议在入口网关或核心服务上打开系统保护，设置一个合理的最大 Load 阈值（比如 4 核机器设成 5），这样即使某个接口没有配置限流规则，系统整体压力过大时也会自动拦截，起到兜底作用。

3.3 规则持久化：不接配置中心，重启就白配了

新手用 Sentinel 最容易踩的坑是：在控制台上手工配置了一堆规则，验证没问题，开心地下线。结果第二天服务一重启，所有规则全部消失。因为默认情况下，Sentinel 的规则是存在内存里的，控制台改完只是推送到应用内存，并没有持久化到任何存储。

生产环境必须接入持久化方案。Sentinel 官方提供了文件、Nacos、Apollo、ZooKeeper 等多种数据源适配。我们团队用的方案是 Nacos，因为配置中心本来就在用，Sentinel 规则可以当作一种 Nacos 配置来管理，改配置不用重启服务，还能和配置中心已有的审计、灰度能力打通。

核心配置写法是加一个SentinelDataSource的 Bean：

@Configuration public class SentinelNacosDataSourceConfig { @Bean public DataSource flowDataSource() { String dataId = "sentinel-flow-rules"; String groupId = "DEFAULT_GROUP"; Properties properties = new Properties(); properties.setProperty("serverAddr", "127.0.0.1:8848"); properties.setProperty("dataId", dataId); properties.setProperty("groupId", groupId); // flow 表示流控规则 return new NacosDataSource<>(properties, ConverterManager.loadConverter( "com.alibaba.csp.sentinel.datasource.Converter", String.class, List.class)); } }

接入 Nacos 数据源之后，每次服务启动时会先从 Nacos 拉取最新规则，后续 Nacos 上的变更也会自动推送到应用。这就不怕重启丢规则了，规则变更也有了审计记录。关于规则装载器，FlowRuleManager.loadRules、DegradeRuleManager.loadRules这些入口在持久化场景下不需要手动调，数据源会自动回调更新，代码里避免重复调用导致规则被覆盖就行。

4. 高并发保障的另一半：配套手段才是最终胜出的关键

4.1 缓存与异步化：从源头削峰，别把所有压力都丢给限流

限流、熔断是做“防守”，但高并发系统光靠防守是不够的，防守做到极致也只是保证系统不死，真正让系统在大流量下还能丝滑响应的，是缓存和异步化这套“进攻”手段。

先聊缓存。我接手过一个详情页接口，QPS 峰值能到 3000，所有流量打到 MySQL 上，数据库 CPU 直接 100%。加了 Redis 缓存后，命中率做到了 95% 以上，数据库 QPS 降到 100 左右，限流阈值都从 800 降到了 200。这就是缓存的价值——你根本不需要无限扩容，只要把热数据挡住，系统压力自然就降下来了。

缓存不是随便加就完事的，三个问题必须解决：

第一是缓存击穿。某一个热点 Key 突然失效，大量请求同时去数据库查，数据库直接被打爆。解决办法是缓存重建加锁，让只有一个线程去查库并回填缓存，其他线程阻塞等待。用 Redisson 的tryLock可以很干净地实现分布式锁。

第二是缓存穿透。查一个根本不存在的 Key，缓存没有，数据库也没有，每次请求直接打到数据库。经典的解决方案是布隆过滤器前置拦截，另一个更省事的方案是把空结果也缓存起来，过期时间设短一些（比如 30 秒），也能挡掉大部分无效流量。

第三是缓存雪崩。大量 Key 在同一时间段集中过期，数据库瞬间收到大量请求。解决思路有两个：过期时间加随机偏移量，让过期时间分散；或者用多级缓存，Redis 挂了还有本地缓存兜底。

再聊异步化。有些操作根本不需要在请求线程内同步完成，比如下单后发短信、写操作日志、更新商品销量、通知运营系统，这些全都应该丢到消息队列里去异步处理。把一次请求里耗时的非核心操作异步化，接口 RT 能从 200ms 降到 50ms，线程池占用率也能下降一大截，系统的整体吞吐自然上去了。

异步化的核心原则是：核心链路不能依赖非核心系统的处理结果。比如下单操作，订单主流程应该只写订单表和扣库存，发短信、推送、更新搜索引擎索引这些统统异步化。如果消息队列挂了，不能影响订单主流程的正常执行，最多就是短信晚发一会儿，这是可以接受的代价。这是我反复强调设计原则的原因：异步化不仅仅是技术手段，更是梳理业务核心边界的契机。

4.2 线程池隔离与容量预估公式

高并发场景下，线程池隔离是防级联故障的物理隔离手段。线程池隔离的思想是：不同接口、不同下游服务的调用，走不同的线程池，一个线程池的资源耗尽，不会影响其他线程池。我用一个具体例子来解释：一个服务里同时调用了用户服务和库存服务，如果两个调用共用一个线程池，库存服务变慢会把线程池占满，用户服务的请求全部排队，整个服务就废了。如果拆成两个独立的线程池，库存服务的线程池慢了，用户服务的线程池照样能处理请求。

Sentinel 不像 Hystrix 那样强制用线程池做隔离，它默认用信号量隔离（并发线程数限流）。信号量隔离更轻量，不增加线程上下文切换开销，适合大部分场景。但如果你有一个极端场景，比如某个下游服务非常慢且不可控，线程池隔离是更安全的方案。在 Sentinel 中做线程池隔离，可以给慢服务单独配置一个线程池，在调用时用ThreadPoolExecutorexecute，同时对线程池设置拒绝策略，满了直接抛异常走降级逻辑。

容量预估是保障措施里最容易被忽视的一环。做容量规划时，我一般用这个公式算：单机支撑 QPS = 1000 / 单请求平均 RT，再乘以单机可用线程数。举例：接口平均 RT 是 100ms，单机分配 200 个工作线程，那单机理论最大支撑 QPS 是1000 / 100 * 200 = 2000。但实际上线程不可能 100% 都在干活，要留出 GC、网络抖动、日志写入的开销，所以再乘一个 0.7 的冗余系数，得出单机安全 QPS 是 1400。集群 10 台机器，整体容量就是 14000，这时把限流总阈值设在 12000 左右，同时保证单机限流在 1400 以内，就能做到均匀分布。

这个公式的价值不在于算出精确数字，而在于让你明白一个道理：提升高并发容量，要么缩短 RT，要么增加线程数，要么加机器。限流规则必须基于容量评估结果来设，否则就是无根之水。

5. 生产环境常见问题与排查技巧实录

5.1 规则不生效：80% 是资源名对不上

Sentinel 用得多了就会发现，好多人反馈“我配置了限流，怎么不生效”，最后排查下来 80% 都是资源名不匹配。Sentinel 的资源名就是一个普通字符串，控制台配置的resource必须和代码里@SentinelResource注解的 value 完全一致，大小写、空格都不能差。有一个项目，代码里写的是order-detail-api，控制台配的是orderDetailApi，限流当然触发不了。

排查这个问题的快速方法是：在控制台的“实时监控”页面，找到你要保护的接口，看它有没有独立的资源链路。如果这个接口的调用量在监控页面上显示的是汇总到其他资源里了，那就说明资源定义有误。还有一种情况是用了通配符路径，比如/order/{id}，Sentinel 默认不解析路径参数，所有路径会被当成同一个资源，需要手动在UrlCleaner里做归一化处理，否则会按不同 URL 各算各的限流，闸门形同虚设。

5.2 高频毛刺与误限流：阈值设置的艺术

系统上线限流后，最怕的不是流量被挡住，而是正常流量被误杀。这种情况有个典型特征：监控上看平均 QPS 才 300，但限流配置是 500，按理说不应该触发，可偏偏时不时就出现几条限流日志。原因是“平均”掩盖了毛刺，虽然平均 QPS 300，但某一瞬间可能突然冲到 800。

针对这种场景，我的调优经验是：不要把阈值卡死在一个精确值上，要结合压测数据留出 25% 到 30% 的余量。同时，根据接口的重要程度选择不同的限流效果：

• 重要接口（下单、支付）：用快速失败，宁可丢弃边缘流量，也不能让核心流程图阻塞。
• 一般查询接口：用 Warm Up 预热模式，让流量在冷启动阶段逐渐上升，避免刚启动就被限流打死。
• 写接口/慢下游调用：用匀速排队模式，让请求排队匀速通过，保护下游数据库。

如果是大促等场景有明确的流量预估，可以在活动前提前压测、提前配好规则，别等活动开始了再现场调阈值。我在大促前一般会做三轮压测，第一轮测基准容量，第二轮带着限流规则测，第三轮做故障演练——人为kill一台机器、模拟数据库抖动，看看限流熔断是否按预期触发。

5.3 故障演练：保障措施上了线不等于万事大吉

最后说一下我在团队里强制推行的一个习惯：故障演练。很多团队接完 Sentinel，规则配好了，控制台也连上了，就以为高并发保障工作结束了。其实规则搭没搭对、参数配得合不合理、降级逻辑有没有写对，只有真刀真枪演练过才能验证。

我们每次大促前必做的演练清单包括：

先模拟单机故障。手动杀掉一台应用节点，观察流量是否自动转移到其他节点，限流阈值是否会自动调整（如果是集群限流，还要验证令牌是否重新分配）。

再模拟下游慢调用。用一个测试工具把用户服务的响应延迟提升到 3 秒，观察 Sentinel 熔断是否触发，降级方法是否被正确调用，有没有把降级后的空数据返回给前端。

最后模拟流量突刺。用压测工具持续抬高 QPS，超过限流阈值 20%，观察被拦截的请求是不是返回了友好的提示，而不是一堆让人看不懂的异常堆栈。

演练过程中发现的问题，大多数是规则配置不符合真实场景、降级方法因参数不匹配导致启动报错、或者返回信息不友好。这些问题如果不演练，是根本发现不了的，等到线上真出了故障再发现就晚了。

从我个人的角度看，高并发保障根本不是“装一个组件、配几条规则”这么简单，它是从架构设计、容量评估、规则配置到故障演练的一整套闭环。Sentinel 给了我们趁手的工具，但使用工具的人得对系统有足够深入的理解。如果这些内容能帮你在自己的系统里少踩几个坑，把高并发保障从口号落到实处，那这篇就值了。