资金网关高并发治理与稳定性建设产品系统

1. 业务定位：网关是平台放款链路的统一入口，授信申请、用信、还款、查询这些资金动作都要经它转发到对应的外部机构。
2. 流量特征之一，峰值集中：营销活动和大促时瞬时并发可以达到平峰的数十倍，且来得很急，没有足够的预热时间。
3. 流量特征之二，机构差异极大：响应快的几十毫秒返回，慢的要几秒甚至超时，个别机构在自身系统升级或切换时会长时间不可用。
4. 流量特征之三，链路很长：一次放款要串联额度、风控、账务、机构四个环节，任一环节阻塞都会在网关侧堆积成队列。
5. 原有问题之一，限流粒度太粗：只按服务级做整体 QPS 限制，一家机构变慢就把服务线程池占满，健康机构也被拖住，业务上表现为某家机构出故障、全平台放款都卡住。
6. 原有问题之二，线程池分散：各业务线各自创建线程池，参数写死在代码里，日累计约一百三十个运行时线程池没人说得清配置分别是什么，流量上涨只能改代码重新发版，调参永远滞后于故障。
7. 后果与结论：这两件事叠加，结果是资源争抢、订单积压、故障定位靠猜。资金类系统对可用性的要求又特别高，放款失败直接影响用户体验和合作方结算对账，所以稳定性治理在这个场景里不是优化项，是必须项。

1. 总体思路：治理分两条线，限流隔离与线程池纳管，两条线都要求不改代码即可生效。
2. 限流降维：把规则从服务级下沉到资金方与业务接口两个维度。资金方维度保证单家机构异常不影响其他机构，业务接口维度保证查询类流量不挤占放款主链路。
3. 阈值与持久化：阈值按机构单独配置，来源是该机构的历史流量分位值与容量沟通结果。规则持久化下发，服务重启不回退默认值。
4. 削峰：配合订单积压池，瞬时超出阈值的请求进入有界队列排队，队列满才拒绝，避免直接失败。队列深度与等待时间作为指标暴露，用于判断是限流过紧还是下游变慢。
5. 降级：按机构维度配置，机构不可用时快速失败并返回明确错误码，不让请求挂在超时上消耗线程。
6. 线程池纳管：引入 Hippo4j 并做二次开发，把分散在各业务线的线程池统一注册到管控台，按资金方维度隔离，每个机构独立线程池加一个全局备用池兜底。
7. 动态调参：运行时可以修改核心数、最大数、队列容量与拒绝策略，不需要改代码发版。每次变更记录操作人、时间、变更前后值，支持版本回溯与一键回滚。
8. 观测：接入全链路追踪，按机构、接口、耗时三个维度下钻，定位到具体是哪家机构的哪个接口在拖慢整体。
9. 闭环：三块能力合起来形成闭环，发现异常、隔离影响、调整参数、验证效果，全过程不依赖发版。

1. 角色：我负责这个方向的方案设计与落地。
2. 限流维度拆分：原先是服务级 QPS 阈值，现在拆成资金方与业务接口两个维度的组合规则，每家机构单独配置。技术上用 Sentinel 的 API 模式做业务融合，把限流判断嵌入调用链而不是靠网关层拦截，规则持久化到配置中心。
3. 排队与限流配合：叠加订单积压池，请求先入有界队列，消费侧按机构并发度控制出队速率，队列深度、等待时间与拒绝数三个指标同时监控。
4. 存量盘点：线程池先做清单化，把散落在各处的线程池统一注册，形成一张可查的清单，这一步就把原先说不清的配置暴露出来了。
5. 隔离边界重划：按资金方维度重新划分，每个机构一个独立线程池，核心数与最大数按该机构历史流量与响应时间设定；再留一个全局备用池，应对新机构上线或流量突增。
6. 二次开发：Hippo4j 原生支持的变更项有限，我在它基础上补了队列容量与拒绝策略的动态调整，并加了变更审计。动态调参最大的风险是改错参数放大故障半径，所以每次变更必须留痕、可回滚。
7. 灰度策略：先在一家低流量机构试点，观察一周无异常再逐批放开。
8. 参数边界：真正的风险点在参数之间的联动。核心数调大但队列没动，可能把问题掩盖住；最大数调大但下游没扩容，只是把压力往后推，最终在机构侧爆掉。所以变更规范里明确了参数的联动关系与观察窗口。
9. 结果：在双实例、机器资源配置不变的前提下，核心接口生产观测峰值 QPS 从 1500 提升到 5000，单机构故障不再扩散到全局，线程池调参从发版级降到分钟级。