这家电商的业务背景是什么？

某跨境电商平台，主营东南亚和北美市场，年GMV在10亿级别。数据采集团队6人，服务于三条核心业务线：

三条线加起来日均请求量在1000万次左右。团队从日均百万级跑了一年半后开始扩容，扩容过程中的四个核心决策构成了这次复盘的主线。

扩容前的架构长什么样？

百万级阶段的架构相对简单：单一代理供应商、统一的短效代理产品、所有业务线共用一个IP池、按月固定套餐采购。

这套架构在百万级时运转正常，但扩到千万级后，三个问题集中爆发。

问题一：请求成功率断崖式下降。日均请求量从200万拉到800万时，整体请求成功率从92%掉到了71%。排查发现，所有业务线的请求共用同一个IP池，跨境选品的高频批量请求导致大量IP被目标平台标记，连带拖垮了广告监测和直播监控的成功率。一条业务线的IP污染传导到了所有业务线。

问题二：成本曲线失控。百万级时月均代理成本约1.8万元，线性外推到千万级预期在9万左右。实际跑到千万级时，月均成本飙到了14万。原因是请求成功率下降后，团队不得不加大IP消耗来维持有效数据产出，形成了"成功率低→多买IP→IP质量进一步下降"的恶性循环。

问题三：故障无法定位。共用IP池意味着任一业务线的异常都会在监控面板上表现为全局性能下降，排障时无法快速判断是哪条业务线引发的问题，平均故障定位时间超过2小时。

第一个决策：IP调度架构怎么重新设计？

团队做的第一个决策是拆掉"所有业务共用一个IP池"的架构，改为按业务线独立分配IP资源。

拆分逻辑：三条业务线的采集特征差异大，对IP的需求维度完全不同。

把三条线的IP池物理隔离后，选品线的高频请求不再污染广告监测线的IP。拆分两周后，广告监测线的请求成功率从71%回升到94%，直播监控线回升到89%。

调度层的第二个改动：引入IP健康度评分机制。每个IP在使用过程中持续记录请求成功率、响应延迟、被限制次数三个指标，低于阈值的IP自动降级到低优先级队列，高健康度IP优先分配给成功率要求高的任务。

这个机制的效果是：IP池总量没有增加，但有效请求的产出率提升了约40%。核心原因是避免了"好IP和差IP混在一起被随机分配"的浪费。

第二个决策：故障隔离机制怎么建？

IP池拆分解决了业务间的污染传导，但每条业务线内部仍然存在故障级联的风险。比如选品线同时采集5个目标平台，如果其中一个平台突然收紧访问频率控制，大量请求失败后的自动重试会挤占其他4个平台的IP资源。

团队建立了三层故障隔离机制：

第一层：目标平台级隔离。每条业务线内部，按目标平台再做一次IP子池划分。平台A的IP不会被分配给平台B的任务。某个平台突然限制时，影响范围控制在该平台的子池内。

第二层：QPS熔断器。为每个目标平台设定QPS上限和动态降级阈值。当某平台的请求失败率在5分钟窗口内超过30%时，自动将该平台的QPS降到基线的50%，15分钟后逐步恢复。这个机制防止了"失败→重试→更多失败"的级联循环。

第三层：供应商级冗余。单一供应商的故障会导致整条业务线停摆。团队引入了主备供应商切换机制，正常流量走主供应商，主供应商响应延迟超过阈值时自动切到备用供应商。切换粒度做到了业务线级别。

三层隔离上线后的效果：

第三个决策：成本模型怎么从"固定套餐"转向"混合计费"？

百万级阶段用固定月套餐，简单省心。但千万级阶段，三条业务线的用量波动差异很大：选品线在大促前一周用量暴涨3-5倍，广告监测线用量稳定，直播监控线在晚间高峰是白天的4倍。

固定套餐的问题是：按峰值采购，平时浪费严重；按均值采购，峰值时IP不够用。

团队最终采用的成本模型是"弹性基础包+按量补足"的混合计费结构。

降本的核心不是"找更便宜的供应商"，而是让采购结构匹配业务的用量曲线。团队做过测算：如果三条线全部用按量计费，月均成本反而会到11万，因为按量的单价高于弹性包。"弹性包兜底+按量补峰"的组合是成本最优解。

另一个细节是账单的可归因性。混合计费之后，每条业务线的成本独立核算，数据采集团队可以清楚地告诉业务方"你这条线上个月花了多少、有效数据成本是多少"。这在组织内部的预算审批中非常关键，比"全团队一个总数"说服力强得多。

第四个决策：合规治理框架怎么搭？

日均千万级请求意味着合规风险被放大了一个数量级。团队在扩容过程中遇到过两次合规事件。

第一次：跨境选品线采集某东南亚平台时，未注意该平台已更新robots.txt限制了部分路径的采集频率，导致被平台技术团队发函警告。

第二次：直播监控线采集的数据中包含了主播个人信息字段，数据入库时未做脱敏处理，在内部数据安全审计中被标红。

这两次事件推动团队建立了采集合规治理的四个基础模块：

合规治理的一个关键原则是前置化：不是出了事再补，而是每个采集任务启动前就完成合规预检。团队把合规检查写进了任务调度的pipeline里，合规预检不通过的任务不允许进入执行队列。

扩容完成后的整体指标变化是什么？

四个决策落地后，整体架构从"单池共用+固定套餐"变成了"业务隔离+分层调度+混合计费+合规前置"。前后对比：

有一个数字值得单独拿出来看：每万次有效请求成本从9元降到6.2元。总成本是涨了，但单位有效产出的成本反而降了31%。这正是架构优化的核心意义：不是花更少的钱，而是让每一块钱产出更多有效数据。

这个案例可以复用的经验有哪些？

从这次扩容复盘中提炼出四条可复用的经验：

经验一：IP池隔离的粒度要匹配业务线差异。不同业务线对IP类型、轮转策略、并发模式的需求差异越大，隔离的必要性越高。混用IP池在小规模时问题不明显，规模放大后污染传导的代价会急剧上升。

经验二：成本优化的抓手是采购结构，不是供应商单价。单纯压单价的效果有限，真正的降本杠杆在于让采购结构与业务用量曲线对齐。稳定用量走弹性包、峰值用量走按量补足，比"全按量"或"全包月"都更经济。

经验三：故障隔离要做到平台级，不能只做到业务线级。业务线级隔离是第一步，但同一业务线内的多平台采集仍然存在故障级联风险。平台级子池+QPS熔断是防止局部故障扩散为全局故障的有效手段。

经验四：合规治理越早前置，成本越低。事后补救的成本远高于事前预检。把合规检查嵌入采集pipeline、让不合规任务无法进入执行队列，是确保千万级规模下合规风险可控的基础机制。

FAQ

Q：日均千万级采集需要多少IP？

没有固定答案，取决于目标平台的访问频率控制策略、单IP可承载的请求频率、IP轮转策略。以这个案例为参考，1000万次日均请求在IP池隔离+健康度管理的架构下，实际活跃IP数维持在日均8-12万级别。但如果是无隔离、无调度的粗放模式，同样的请求量可能需要3-5倍的IP消耗。

Q：多供应商切换会不会增加运维复杂度？

会增加一定的接入和管理成本。建议在调度层做供应商抽象，统一接口协议和鉴权方式，让上层业务代码不感知底层供应商切换。实际运维中，主备切换的自动化程度越高，运维负担越小。这个案例中，供应商切换的自动化率做到了90%以上。

Q：弹性包+按量补足的成本模型适合所有规模吗？

不一定。日均请求量在百万级以下、用量波动不大的场景，固定套餐反而更简单经济。混合计费的优势在用量波动大的场景才能体现，波动越大、峰谷差越明显，混合模型的成本优势越显著。

Q：合规预检会不会影响采集效率？

合理设计下影响可忽略。这个案例中，合规预检的平均耗时在200毫秒以内，相比整个采集任务的执行周期可以忽略。关键是把预检做成异步的、可缓存的：同一平台的合规状态缓存有效期设为7天，7天内重复任务不再重新检查。

Q：IP健康度评分机制的维护成本高吗？

初始搭建需要1-2周的开发投入，主要是埋点采集三个指标、建评分模型、接入调度系统。上线后的维护成本很低，核心工作是定期调整评分阈值。建议从简单的线性加权开始，不要一上来就搞复杂的机器学习模型，够用就行。

Q：这套架构对团队规模有什么要求？

这个案例中的数据采集团队是6人，其中2人负责调度和架构、2人负责采集脚本开发、1人负责数据质量、1人负责合规和供应商管理。千万级采集不一定需要大团队，但需要明确的职责分工。调度架构和合规治理是最容易被忽视、也是规模化后最先出问题的两个方向，建议有专人负责。