Sentinel限流规则配置：防止恶意刷单耗尽DDColor计算资源
在AI图像修复服务逐渐普及的今天，一个看似简单的“老照片上色”功能背后，可能隐藏着巨大的算力消耗风险。以DDColor为例，这项基于深度学习的黑白图像智能着色工具，依托ComfyUI平台为用户提供直观的工作流体验，广泛应用于人物与建筑类历史影像的数字化还原。用户只需上传一张黑白照片，系统即可自动生成色彩自然、细节丰富的彩色版本。
然而，开放的服务接口也引来了非正常访问——自动化脚本批量提交请求、高频刷单抢占GPU资源、集中调用高负载任务导致显存溢出……这些行为不仅让服务器疲于应对，更直接影响了普通用户的使用体验。一次突发的流量冲击，就可能导致整个服务响应延迟甚至宕机。
面对这一挑战，我们引入了Sentinel作为核心流量治理组件，构建起一套精细化、可动态调整的限流防护体系。它不像传统防火墙那样粗暴拦截IP，而是深入到业务层面，对每一个请求进行实时评估和控制，确保宝贵的GPU资源始终服务于真实、合理的使用场景。
资源定义与保护：从接口粒度开始
在Sentinel的世界里，“资源”是流量控制的基本单位。它可以是一个HTTP接口、一个方法调用，甚至是一段关键逻辑。对于DDColor服务而言，我们将两个主要的图像修复接口分别标记为独立资源：
private static final String RESOURCE_BUILDING = "ddcolor_building"; private static final String RESOURCE_PERSON = "ddcolor_person";为什么要做如此细粒度的划分？因为不同类型的修复任务对计算资源的消耗差异显著。建筑物类图像通常分辨率更高、结构复杂，推理时间长、显存占用大；而人物类虽然对肤色和五官颜色还原要求高，但输入尺寸较小，整体负载相对可控。将它们视为不同资源，意味着我们可以实施差异化限流策略——比如允许每秒处理5次人物修复请求，但仅允许2次建筑修复，从而更科学地匹配实际资源供给能力。
通过SphU.entry(resourceName)在代码中对关键路径进行埋点，Sentinel便能自动捕获每一次调用，并纳入统计与控制范畴。一旦触发限流规则，BlockException会被抛出，我们可以在异常处理中统一返回友好的提示信息，而不是直接抛出500错误或超时。
try { entry = SphU.entry(RESOURCE_PERSON); // 执行图像处理 } catch (BlockException e) { return ResponseEntity.status(HttpStatus.TOO_MANY_REQUESTS) .body("请求过于频繁，请稍后再试"); } finally { if (entry != null) entry.exit(); }这里有个容易被忽视的关键点：必须在finally块中调用entry.exit()。否则会导致统计链路中断，影响后续的滑动窗口计数准确性，严重时还可能引发内存泄漏。这并非理论问题，在早期测试中我们就曾因疏忽导致限流失效，最终通过日志分析才定位到这个细节。
多维度限流：不只是QPS那么简单
很多人理解的限流就是“每秒最多放行X个请求”，但在真实生产环境中，这种单一维度的控制远远不够。Sentinel的强大之处在于其支持多维度、多层次的流量控制策略，让我们能够针对不同的攻击模式做出精准防御。
按调用来源（origin）限流
最典型的恶意刷单行为来自单一IP的高频请求。为此，我们启用了基于调用方的限流机制。例如：
- 普通用户IP：每人每秒最多3次请求；
- VIP用户或白名单IP：放宽至8次/秒；
- 对特定时间段内超过阈值的IP自动加入临时黑名单。
实现方式是在规则配置中指定limitApp字段为origin，并结合自定义的上下文解析器提取客户端IP地址。这样，即使多个用户共用同一个公网出口（如公司NAT），也能在一定程度上识别个体行为。
热点参数限流：防止单一高负载组合被滥用
除了整体频率，某些特定参数组合也可能成为攻击目标。例如，有人专门请求1280p分辨率的建筑修复任务，这类请求单次耗时长达5秒以上，极易造成资源堆积。对此，我们启用Sentinel的热点参数限流功能，监控size参数的调用频次：
{ "resource": "ddcolor_building", "paramIdx": 0, // 假设size是第一个参数 "threshold": 10, "durationInSec": 60 }上述规则表示：同一size值（如1280）在一分钟内最多被调用10次。超出后对该参数值的请求将被拦截。这种方式有效遏制了“专攻高消耗任务”的脚本行为。
系统自适应保护：当GPU快撑不住时
即便做了前置限流，仍有可能因突发流量或模型异常导致系统负载飙升。这时，Sentinel的系统规则（System Rule）就派上了用场。我们设置了基于CPU使用率和平均RT的动态保护机制：
- 当CPU利用率 > 85% 或 平均响应时间 > 2s 时，自动降低全局入口的QPS阈值；
- 同时拒绝新的并发请求，直到系统恢复稳定。
这相当于给服务加了一层“自我调节”的安全阀，避免雪崩效应的发生。
工作流执行与资源调度的协同设计
DDColor的核心推理运行在ComfyUI环境中，这是一个基于节点式图形界面的AI工作流引擎。用户选择对应场景的JSON配置文件（如DDColor建筑黑白修复.json），上传图片并设置参数后，即可一键生成结果。
这种可视化操作极大降低了使用门槛，但也带来了新的管理难题：如何防止某个用户长时间占用GPU？
我们的解决方案是将限流逻辑前置到API网关层，确保只有合规请求才能触达ComfyUI。具体流程如下：
- 用户发起
/api/ddcolorize/building请求； - Sentinel Client 实时检测该IP的QPS及并发任务数；
- 若未超限，则放行请求，后端服务向ComfyUI提交异步任务；
- ComfyUI加载对应工作流，执行推理，输出图像至OSS；
- 返回结果URL给前端。
在这个链条中，限流发生在最上游，避免无效请求穿透到计算层。同时，我们为每个用户设置了最大并发任务数（如2个），防止一人开启多个浏览器标签页同时提交任务。
值得一提的是，首次部署时我们曾遇到一个问题：部分用户上传超大图像（如4K扫描件），导致显存溢出（OOM）。后来通过在预处理阶段增加图像尺寸校验解决——超过1280px的自动缩放到合理范围，并提示用户“建议上传适配分辨率的图片”。
动态规则管理与可观测性建设
静态的限流规则难以应对不断变化的业务需求和攻击手法。因此，我们采用了Sentinel Dashboard + Redis的组合，实现运行时动态规则推送。
运维人员可通过Web控制台实时查看各资源的QPS、RT、异常比例等指标，并根据当前负载情况即时调整阈值。所有规则变更无需重启服务，几秒内即可生效。
（示意图：Sentinel Dashboard展示资源监控数据）
同时，我们将关键指标接入Prometheus + Grafana体系，建立完整的监控告警机制：
- 实时绘制被限流请求数趋势图；
- 设置阈值告警，当日活IP数突增或某资源QPS持续高位时通知值班工程师；
- 结合日志分析工具（如ELK），追踪异常IP的行为轨迹。
这些措施让我们不仅能“挡住攻击”，还能“看清攻击者是谁、怎么来的、想干什么”，为后续的安全策略优化提供数据支撑。
实践中的经验与反思
在实际运营过程中，我们也走过一些弯路，积累了一些值得分享的经验：
1. 阈值设定不能拍脑袋
初期我们为ddcolor_person接口设置了10 QPS的上限，结果上线后发现大量合法用户被误拦。经排查才发现：单次处理平均耗时3秒，意味着一台GPU每秒最多处理约0.33个任务。若总QPS设为10，理论上需要30块GPU才能支撑——显然不现实。
最终我们根据硬件资源配置反推合理阈值：现有4块A10G GPU，每块可并发处理2个任务，平均耗时3秒 → 最大吞吐量约为(4×2)/3 ≈ 2.66 QPS。考虑到留有余量，我们将总入口QPS设为8（含VIP优先级调度），并通过分层限流分散压力。
2. 区分资源类型比统一限流更有效
最初我们将所有图像修复请求归为一个资源ddcolor_all，结果发现低负载的人物修复经常被高负载的建筑修复“挤掉”。拆分为两个独立资源后，问题迎刃而解。
3. 慢启动模式的价值
新版本上线或服务重启后，常会遭遇瞬间高峰。我们启用了Sentinel的Warm-Up（预热）模式，让阈值在几分钟内逐步上升，避免冷启动期间被突发流量打垮。
4. 日志记录要包含上下文信息
光知道“被限流了”还不够，我们需要知道“谁、在什么时候、调用了什么、参数是什么”。因此，在拦截逻辑中加入了详细的日志输出：
log.warn("Request blocked by Sentinel: ip={}, resource={}, params={}", clientIp, resourceName, requestParams);这对后续审计和攻击溯源至关重要。
写在最后
技术本身没有善恶之分，但开放的服务必须具备抵御滥用的能力。DDColor的价值在于让更多人能轻松修复珍贵的老照片，而Sentinel的作用则是守护这份便利不被少数人破坏。
这套“前端易用 + 后端可控”的架构设计，不仅解决了当前的资源耗尽问题，也为未来扩展提供了坚实基础。无论是新增视频上色、语音修复，还是支持更多AI模型接入，都可以沿用类似的流量治理体系。
更重要的是，它提醒我们：在追求AI普惠化的同时，不能忽视工程层面的健壮性设计。真正的用户体验，不仅体现在功能是否强大，更在于服务是否稳定、公平、可持续。
这种以流量为核心、兼顾性能与安全的设计思路，正成为现代AI服务平台不可或缺的一环。
