一、项目背景

某平台把模型能力开放给内部几十个业务线调用，一开始大家你好我好，统一限流。后来少数业务线写得糙，重试风暴、超大 payload、低频长连接什么都有，几次把网关拖垮，影响的是所有业务线。我们再一刀切限流，正常业务又被误伤，投诉从一边转到另一边，夹在中间里外不是人。

我们复盘那几次故障，发现根子不是流量大，是少数调用方人品差，把公共资源当自己家。但网关当时只看总量，看不出是谁在胡来。要治，得先能区分好孩子和熊孩子，再分别对待，而不是一棍子全打死。

二、落地场景

我们做的第一件事是给每个调用方建行为画像，重试次数、payload 大小、错误率、长连接占比这些信号持续采集。调用方行为画像是第一段，把人品量化出来。信誉评分是第二段，画像信号合成一个动态分，高分松、低分紧。弹性限流放第三段，限流阈值跟着信誉分走，烂调用方自动收紧，好调用方不背锅。异常行为降级兜底，信誉跌破线直接降级或熔断，不拖全场。

案例片段（已脱敏）： 调用方信誉评分与弹性限流配置片段（示意）：profile:  signals: [retry, payload, err_rate, long_conn] score:  range: [0,100]  update: sliding_5m limiter:  base_qps: by_score  low_score: tighten  degrade_below: 30上线后异常调用拦截率约 95%，正常调用受损率降到约 1%，网关因少数业务线导致的稳定性事故从每月约 3 起降到约 0，评分更新时延约 5 分钟。

三、关键技术挑战与解决思路

第一个坑是行为画像建模。哪些信号算差，容易拍脑袋，结果误伤正常业务。我们做法是信号可配置、权重可调，且先观察一段时间不打分，用真实数据标定阈值，避免一上来就冤枉人。这一步比直接限流重要，因为评分不公，联动限流就是瞎限。

第二个难点是信誉评分的公平性。新接入的调用方没历史，一上来就是低分容易被误杀。我们设了冷启动保护，新调用方先给中性分，跑一段再动态调，不因为没数据就当坏人。这里有个权衡，冷启动保护会不会被滥用，我们加了观察期上限，过了就得用真实表现说话。

第三个点是弹性限流的平稳。信誉分是滑动更新的，如果限流阈值跟着抖，调用方会体验到忽快忽慢。我们让阈值变化做平滑，避免评分微小波动就触发限流跳变，用户体验才稳。

四、效果数据

异常调用拦截率约 95%，正常调用受损率约 1%，网关因少数业务线导致的稳定性事故从每月约 3 起降到约 0，评分更新时延约 5 分钟。最明显的改变是故障少了，两边投诉都下来了，我们终于不用在业务线之间当和事佬。我们复盘时发现，评分公开后，几个糙业务线居然开始主动改调用方式，因为不想被收紧。（数据均为脱敏示意值）

治理侧把信誉分接进了调用方门户。每个业务线能看见自己的分和扣分项，改起来有方向，从被限流了才知道错变成看着分提前改。平台也按分做资源倾斜，好调用方高峰期优先，形成正向激励。这套机制后来被复用到了对外 OpenAPI 的治理上，逻辑通用。

五、可复用经验总结

限流不能只看流量，得看调用方人品，把重试次数、payload 大小、错误率合成一个信誉分，烂调用方自动收紧，好调用方不背锅，网关稳了误伤也少了。评分要可配置、先观察后标定，不公就成瞎限。新调用方给冷启动保护，别因没数据当坏人。我后来觉得，网关治理的本质是管人不是管流量，能区分出谁在胡来，问题就解决了一大半。

结语

我们后来把信誉分接进了调用方的准入和 quota 申请，分低的业务线想扩额度要先改调用方式，把治理从事后限流前移到了事前，矛盾少了一大半。还有一个之前没想到的，是信誉分公开后带来的行为引导，业务线开始主动优化重试逻辑、压缩 payload，因为看到分在掉，这种自驱比我们催有效得多。治理的最高形态大概不是罚，而是让做个好调用方变成对业务自己有利的事。我们也遇到过信誉分被短期流量冲高的假象，某业务线平时很乖，大促瞬间糙起来，分数来不及跌就被打挂，后来我们给分加了短期波动的权重，让它在流量尖峰时也敏感。往后看，调用方治理会越来越多地和成本挂钩，信誉好不仅不限流，还能拿到更便宜的算力价格，把好行为直接翻译成省钱，这条激励链准备继续打通，这比单纯限流高明，因为动力来自业务自身。我们也准备把信誉信号开放给业务线自己看实时分，让优化变成日常习惯而不是季度运动。

我们也开始把信誉分作为业务线考核的参考之一，不是惩罚，而是让大家看见自己的技术债。治理一旦和组织绩效轻轻挂钩，重视程度完全不一样，这是超出技术本身的收获。我们也在考虑把信誉看板对业务线负责人周报化，让优化变成持续的日常动作。