爬虫技术实践: 搭建高效稳定支撑内部数据业务的采集平台

背景

写这篇文章主要目的是想记录个人在工作中的爬虫技术工程实践和体系化建设过程。好处有以下3点

1. 个人技术体系的沉淀与梳理。爬虫技术涉及的知识维度广泛且迭代迅速，通过系统性的总结，既能巩固自身技术认知，也为后续优化提供清晰的演进路径。

2. 寻求行业内的深度交流需求。相较于其他技术领域，爬虫技术的专业讨论圈层较为局限，希望借此文与同业者建立更深入的技术对话，共同探讨工程实践中的解决方案。

3. 当前技术社区中，针对企业规模化爬虫平台建设的探讨相对匮乏。作为一线实践者，希望分享我在真实业务场景中的架构设计与技术选型经验，是否能为爬虫行业提供有价值的示例。

平台介绍

当前采集平台（简称平台）利用爬虫技术模拟互联网上的网络请求进行数据获取，形成企业内部一条稳定、丰富的数据管道。帮助企业内部业务开展，典型场景包括搜索引擎、商品比价、数据分析等。

P.S 采集平台应用爬虫技术的前提应是：企业需要获取大量数据，但无法从现有平台或第三方合规获取；同时必须遵守法律法规约束，在不损害目标平台服务的前提下进行数据采集。

平台服务范围

• 按业务领域划分：主要应用于内容、安全审核、广告业务、内部支撑等领域。

• 按采集时效性划分：

  • 实时采集：需达到分钟级的交付标准，对采集成功率要求最高，需要多种兜底方案保障采集过程正常运作。
  • 离线采集：时效性要求相对较低。

• 按面向客户划分：

  • 线上系统模块：服务于线上业务系统，对时效性和可靠性要求最高，基本需要分钟级响应数据，投入的维护人力成本也最高。

  • 内部业务支撑：主要面向公司内部其他团队或合作系统，负责提供数据支撑。通常作为合作流程的一部分，只需满足约定的交付要求即可。

核心业务场景

平台的核心使命是为各业务团队提供稳定可靠的数据源支撑。因此需要平台不仅提供原始数据的采集能力，还需要集成了多样化的数据处理功能，支持如视频抽帧、APK解包分析、聚合清洗等关键场景。

主要核心业务领域及应用如下表所示：

业务领域	数据应用场景	技术挑战
​​内容业务​​	社区UGC素材采集、AIGC内容流式生成、热点新闻追踪	动态渲染页处理、反爬机制应对、通用抓取能力
​​安全审核​​	异常IP库/号码库聚合、视频内容抽帧审核	多源视频整合、文本信息提取、视频高效处理、实时更新能力、实时告警
​​广告业务​​	广告应用SDK分析、应用信息提取	反爬机制应对、大规模文件下载处理
​内部支撑​​	订单数据聚合与清洗	合规性挑战、验证码识别、实时告警

由上表可见，平台覆盖了差异显著的多元化业务场景。不同业务领域的数据采集逻辑各具特点，这对平台提出双重要求：一方面，平台需作为稳定可靠的系统工程，保障数据准确性与时效性；另一方面，平台需具备高度敏捷性，能够实现多源数据的高效聚合，并针对不同站点的数据类型特征快速适配采集策略，支撑高效开发。

技术保障措施

为满足平台稳定可靠和高度敏捷的要求，主要采取以下几项关键保障措施：

1. 采集链路全链路监控： 对爬虫运行全流程进行指标追踪与上报。监控维度覆盖运行环境（CPU、内存、IO、线程数）及核心业务指标（请求成功率、字段解析成功率）。

2. 多数据源/多路径冗余： 在架构设计阶段即纳入多数据源或多请求路径支持。此机制旨在规避单一数据来源失效风险，确保在一条路径异常中断时，数据采集流程仍能无感知切换，保障业务连续性。

3. 基于Docker的多版本部署机制： 依托Kubernetes实现容器化管理，支持多个版本（包含不同功能分支）的爬虫程序并存。通过容器编排实现服务版本间的平滑切换与灵活部署。

难点与挑战

作为企业内部的公共数据服务平台，平台承载了不同业务线的数据需求。与常规单一功能的后台系统不同，它基于爬虫技术从外部平台获取数据，因此需要应对多场景适配性、广泛的应用范围，以及目标平台的反爬机制等一系列挑战。

1. 针对不同业务领域，爬虫技术面临的核心挑战

4. 验证码识别：传统验证码、AI 模型生成验证码、第三方打码平台

5. 加密参数：JS 代码反混淆、黑盒 API 调用

6. 登录校验：Cookie 池维护、自动化登录流程

7. 环境检测：指纹浏览器、设备指纹伪造

8. 行为检测：自动化操作（如 undetected-chromedriver）

9. 数据动态加载：浏览器渲染（如 Puppeteer、Playwright）

10. IP 出口检测：代理池管理（住宅 IP、数据中心 IP、轮换策略）

11. 指纹检测：curl_cffi模拟浏览器指纹、RPC 调用

当前市面上已有一些成熟的工具和方案，帮助爬虫开发人员应对复杂场景，例如：

• curl_cffi：模拟浏览器 TLS 指纹，绕过协议检测
• undetected-chromedriver：规避自动化检测（如 Headless Chrome 识别）
• unidbg：动态执行加密算法，破解黑盒调用

但由于目标平台也会时刻更新自身的反爬策略，这不仅需要爬虫开发人员对日常运行程序建立完善监控体系和告警策略，还需要有突破反爬的应对能力。这个过程可能需要额外花费购买代理资源、账号资源，从而导致成本上升的问题。

2. 爬虫业务本质上是一场爬虫方与被爬取方的成本对抗

• 被爬取方：需要以合理的成本保障数据安全（如风控升级、反爬策略）
• 爬虫方：需要以低成本获取目标数据（如代理池优化、自动化运维）

如果爬虫的开发成本 + 维护成本 > 业务收益，则该爬虫项目不具备可持续性。因此，爬虫业务的开展必须综合考虑：

• 项目收益（数据价值、业务需求）

• 投入成本（开发、运维、代理、验证码等）

• 人力成本（开发、维护、优化）

3. 爬虫与反爬是技术能力与成本效益的平衡

成功的爬虫业务需要有以下几点：

12. 技术突破：持续优化反反爬策略，提高数据获取效率
13. 成本控制：合理评估投入产出比，确保业务可持续性
14. 合规运营：遵循法律法规，避免法律风险

只有在技术可行、成本可控、业务有价值的前提下，爬虫业务才能长期稳定运行。

4. 案例：订单对账场景（30+ 渠道订单汇总）

以30+渠道订单汇总的运营订单导出工作为例，在未引入爬虫服务前，该环节存在大量重复性人工操作：工作人员需逐个登录各渠道后台（每个后台都有不同类型的验证码校验），手动导出订单数据并完成汇总，单周需耗费7小时人力。按此推算，每月人力成本近30小时，相当于4个标准人天，极大占用了运营人员的核心工作精力。

引入爬虫服务后，该场景实现了显著的降本增效：单仅需投入2人天完成前期开发（自动登录，pass验证码，自动导出上传），后续订单核对工作即可通过自动化流程闭环解决。即便部分平台出现规则调整，也无需重构系统，仅需在原有爬虫基础上优化点击及数据抓取规则，整体维护耗时短、成本低，彻底摆脱了对重复性人工操作的依赖。

​​指标​​	​​无爬虫服务​​	​​使用爬虫服务​​
​​人力投入（天）​​	1 人天/天	0（自动化运行）
​​维护/导出耗时​​	1 小时/天	30 分钟/周
​​开发成本​​	低（手动）	前期投入高（自动化）
​​长期收益​​	低效	高效、可扩展

平台核心指标

1.准确性

目标：确保采集的数据与源平台完全一致，避免错采、漏采或数据篡改。

关键要求：

• 数据一致性：入库数据必须与采集时的源数据严格匹配，任何偏差均视为异常。

• 错误检测机制：

  • 字段级校验（如关键字段缺失、格式错误）
  • 数据比对（如与历史数据或第三方数据源交叉验证）

• 容错与修复：

  • 自动重试机制（针对解析失败的数据）
  • 人工复核流程（对关键业务数据二次校验）

典型问题：

• 网页结构变动导致解析失败

• 反爬机制干扰（如动态加密字段）

• 数据更新延迟（如采集时点与源平台实际更新不同步）

2.完整性

目标：保障当日数据100%覆盖，任务需按时触发且无遗漏。

关键要求：

• 任务调度监控：

  • 实时记录任务执行状态（成功、失败、延迟）
  • 对未执行任务自动告警并触发补采

• 漏采根因分析：

  • 网络异常、目标平台限流、系统资源不足等
  • 代理IP失效或反爬策略升级

• 数据闭环验证：

  • 统计每日采集量，对比历史均值或预期值
  • 设置数据完整性阈值（如覆盖率≥99.9%）

典型问题：

• 任务调度系统故障导致漏跑

• 目标平台分页或动态加载未完全抓取

• 增量采集逻辑缺陷（如未识别新数据）

3.时效性

目标：异常情况快速发现、快速定位、快速恢复。

关键要求：

• 实时监控体系：

  • 采集成功率、耗时、错误率等指标可视化
  • 设置多级告警（企业微信、短信、邮件）

• 自动化应急响应：

  • 失败任务自动切换备用采集方案（如降级解析、切换代理池）
  • 多数据源兜底（避免单一平台的反爬）

• SLA 保障：

  • 核心业务数据采集延迟≤15分钟
  • 非核心数据延迟≤1小时

典型问题：

• 代理IP大规模失效导致采集停滞

• 突发反爬策略（如验证码频次激增）

• 系统资源争抢（如高并发导致节点崩溃）

保障措施

指标	核心目标	关键措施
​​准​​确性	数据零误差	字段校验、版本更新检测、AI判断
​​完整性	任务零遗漏	调度监控、漏采分析、数据验证
​时效性	不超过3天水平线	实时告警、自动切换、多策略兜底

核心优化方向

• 技术层面：强化自动化检测（如动态反爬识别）、提升采集稳定性（如多数据源兜底）。
• 流程层面：建立数据质量日报机制，定期复盘异常根因。
• 成本层面：平衡资源投入与业务需求，避免成本过高导致业务运营成本上升。

平台能力架构

平台面临的业务挑战（多场景适配、反爬对抗）和核心指标（准确性、完整性、时效性），平台需构建以下五大核心能力，形成一套功能完善、监控全面的数据采集体系，支撑企业各类业务场景的需求。

1. 核心能力

​​能力维度​​	​​功能说明​​
​​1. 多业务场景接入​​	支持不同业务线（如内容、安全、内部部门）的灵活接入，提供标准化API和配置化采集流程
​​2. 多数据源开发​​	适配各类数据源（Web、API、文件下载等），支持动态解析、增量采集、数据清洗
​​3. 数据质量保障​​	实时监控数据准确性、完整性，支持多数据源自动切换，异常自动修复
​​4. 反爬对抗体系​​	集成代理池、账号池、验证码破解、指纹伪造、RPC黑盒调用等方案，降低采集风险
​​5. 任务调度管理​​	提供任务编排、优先级调整、失败重试、资源隔离等能力，确保采集任务高效稳定运行

2. 功能架构

（1）业务领域层

支撑企业核心业务的数据需求，包括但不限于：

• 内容业务：热点新闻追踪

• 安全审核：黑手机号/IP库

• 内部支撑：多平台订单聚合（如Apple、Google、iPay88）

• 广告业务：竞品数据监控

（2）平台能力层

提供任务管理、工作流编排、反爬对抗等核心功能：

​​模块​​	​​功能​​
​​任务系统​​	- 任务调度（定时/实时） - 优先级调整 - 采集策略配置（并发控制、增量采集）
​​异步工作流​​	- 任务流水线管理 - 业务隔离（资源分配、限流） - 失败自动重试
​​验证码管理系统​​	- 公共手机号池 - 邮件转发管理 - 打码平台集成（自动/人工）

（3）基础能力层

提供数据采集、代理管理、监控告警等底层支撑：

​​模块​​	​​功能​​
​​数据抓取​​	- HTTP/API请求管理 - 动态渲染（Puppeteer/Playwright） - 文件下载
​​代理池管理​​	- 住宅/数据中心IP轮换 - 隧道代理 - 可用性检测
​​账号池管理​​	- Cookie自动续期 - 多账号轮换 - 登录态维护
​​定时任务管理​​	- Cron表达式配置 - 任务依赖管理
​​下载队列管理​​	- 大文件分片下载 - 断点续传
​​配置中心​​	- 动态Header/UA管理 - 请求频率控制
​​监控配置​​	- 采集成功率监控 - 耗时统计 - 异常告警（企业微信/邮件）
​​验证码统一服务​​	- OCR识别 - 行为验证码绕过（如reCAPTCHA）
​​RPC黑盒服务​​	- 加密算法破解（unidbg） - 协议模拟（curl_cffi）

平台演进流程

平台获取数据其中一个手段是爬虫进行采集，客观上讲爬虫是一项基础但不确定性较高的数据采集手段。因此平台建设的核心目标始终围绕稳定性、可靠性和效率的提升。以下是平台从早期脚本模式到未来智能化架构的演进历程：

1. 2022年之前：单机时代（单体爬虫）

技术特点：

• 开发模式：以 Python 为主的单体脚本，逻辑与数据采集强耦合

• 部署方式：物理机部署，通过XXL-JOB定时启动

• 问题与挑战：

  • 组件耦合：爬虫逻辑、数据解析混在一起，维护困难

  • 故障恢复差：进程崩溃后需手动重启，无自动容错机制

  • 分布性能力不足：基于redis实现分布式爬取，可能会出现任务丢失等场景。难以应对大规模并发采集需求

2. 2022-2023：容器化与初步平台化

技术升级：

• 开发模式：以 Python 为主的单体脚本，开始搭建基本的框架工具库

• 部署方式：将XXL-JOB执行器部署在K8S上，固定节点数据，仍通过XXL-JOB定时启动

• 组件解耦：代理池、验证码识别等公共功能抽离为独立服务

• 核心改进：

  • 任务隔离：不同业务线的爬虫负责消费指定队列，避免相互影响

  • 基础服务：隧道代理、验证码平台初步建设

  • 监控雏形：基础指标（成功率、耗时）上报

3. 2023-2024：平台化升级

技术突破：

• 开发模式：统一使用内部爬虫框架部署

• 部署方式：新增常驻型爬虫和定时爬虫，前者由K8S独立环境部署通过HPA自动扩缩容，后者依旧由XXL-JOB定时调度；

• 框架引入：内部爬虫框架统一，代码规范落地

• 服务建设：

  • 链路追踪：全流程日志采集上传，问题定位效率提升50%+
  • 网关接入：爬虫相关API服务全线接入Kong，实现API统一鉴权与流量控制
  • 云真机/浏览器集群：应对动态渲染与高防站点（如电商、社交平台）

• 运维增强：

  • 自动扩缩容（根据任务负载动态调整Pod数量）

  • 任务熔断（异常率超阈值时自动暂停）

4. 2025-至今：服务化与智能化

演进方向：

1. 数据监控：

   1. 字段级监控：实时校验每个字段的准确性（如价格、库存）
   2. 分钟级实时采集：核心业务数据延迟≤15分钟

2. 高可用增强：

   1. 跨大区机房容灾（如美洲+亚洲大区3机房部署）
   2. 智能切换数据源（主源失效时自动降级）

3. 统一数据服务：

   1. 整合内外数据源（爬取数据+API数据+数据库）
   2. 提供标准化数据API服务供内部业务方调用

4. AI模型接入：

   1. 反爬能力强化：引入AI视觉识别与语义分析模型，解决逻辑推理等复杂验证码。
   2. 内容提取优化：应用AI爬虫框架的自然语言处理能力，自动识别并提取核心信息，降低无效数据干扰。
   3. 运维智能化升级：搭建API协议变更检测服务，通过AI算法实时比对目标平台接口的版本差异，并生成优化建议，提前发现协议变更进行应对。

平台系统主要技术挑战和实践

平台的核心能力聚焦于数据抓取与数据处理领域，因此融合了爬虫技术、数据清洗、后端服务等多项技术，是一个综合性的业务技术平台。其核心挑战主要体现在两大方面：

1. 高效的业务支撑能力：需快速响应多样化业务需求，适配不同场景的数据采集与处理，同时优化开发效率与资源成本。
2. 系统的稳定性与高可用：需保障7×24小时稳定运行，应对高并发、反爬对抗、异常恢复等复杂场景。

围绕这两大挑战，通过持续的技术调研与实践，我积累了丰富的爬虫技术经验，构建了一套高效、可靠的企业级数据采集体系。

功能设计：解耦、抽象与复用

早期的平台以具体业务场景开发为核心，采用小步快跑的方式进行开发。导致负责不同业务渠道的开发人员彼此使用风格不同的独立脚本开发，代理提取、数据请求、解析入库等流程均各自实现，代码风格各异，功能重复率高。因此面对新需求时，由于缺乏抽象设计，往往需要重新开发，难以高效支撑业务迭代。

1. 模块化重构：功能解耦与复用

在后续迭代中，我重点推进功能模块的抽象化、解耦与复用：

• 流程标准化：将爬虫流程拆解为代理提取、任务获取、数据请求、解析处理、文件下载、数据入库、异常告警等环节。

• 模块化设计：

  • 固定环节（如代理池、任务系统、通用下载器）抽象为独立服务，通过队列或HTTP通信。
  • 可变环节（如站点解析逻辑）插件化，支持动态扩展。

• 部署优化：容器化封装，支持滚动发布与快速回滚，降低版本升级风险。

2. 智能体与低代码实践

随着AI技术发展，团队引入低代码开发与智能体编排，进一步提升效率：

• 低代码转型：从传统硬编码转向配置化开发，通过HTTP/RPC调用复用功能模块，提升代码质量与协作效率。

• AI智能体应用：基于Dify平台构建任务编排系统，支持：

  • 自定义插件开发：对接爬虫数据获取、模型调用等能力。
  • 流程自动化：例如新闻热点追踪场景，实现从文章抓取、摘要生成到视频合成的全链路自动化。

• 核心优势：

  • 模块隔离：业务逻辑清晰，减少交叉影响。
  • 高效复用：功能模块可跨项目组合，快速响应新需求。

消息队列实践

平台广泛采用消息队列实现服务解耦，通过异步通信提升系统吞吐能力、削峰填谷，并增强故障恢复韧性。在组件选型上，形成了 "双队列" 协同模式：与外部数据系统交互以Pulsar为主，平台内部服务通信则基于redis的redis实现消息队列。这一选型源于团队技术栈特性 —— 核心开发语言为 python，而redis队列在内部已经在内部广泛使用，不易进行切换；对于外部业务合作方（多采用 C++、Java 技术栈），则适配其常用的 Pulsar/Kafka。仅此需要兼容一些消费流程的适配。

使用消息队列需考虑消息可靠性保障，需重点解决重复消费与堆积恢复问题。因此需要考虑以下几个问题

1. 队列治理策略

Topic分治设计平台消息队列主要传递任务数据，若按业务逻辑合并使用同一 Topic，可能因某类消息激增或耗时过长，导致整个 Topic 消费延迟，进而影响高优先级业务。因此采用 "业务线 ID + 业务场景" 的复合维度拆分 Topic，既避免单队列阻塞风险，又防止过度细分导致的 Topic 膨胀。

2. 全链路监控与可靠性保障

   • 针对每个 Topic 及对应消费者组，部署积压监控机制，实时感知消费状态；

   • 消费进程强制实现幂等性，支持消息重入、重复消费或丢弃，从根源规避重复处理风险；

   • 制定队列积压故障恢复方案，需精准识别消费者依赖的下游瓶颈点，针对性优化处理链路。

3. SDK封装

因基于日常问题与业务场景，封装了 Python 版 MQ 消费 SDK，核心特性包括自动重试、重复消费 / 丢弃控制、优先级重试及延迟执行。其架构采用多线程并发模式，由三大组件构成：

• 消费主线程：负责从业务的消息队列拉取消息并分发；
• 重试子线程：定时遍历 Redis 重试 ZSet，根据记录的 offset 从原队列回溯消息进行重试；超过最大重试次数则移入死信队列；
• 执行线程池：处理消息业务逻辑，失败则更新重试 ZSet 的下次执行时间，成功则移除记录。

同时，通过 Prometheus 定时监控重试 ZSet 与死信 ZSet 长度，触发告警机制及时响应异常。

4. 消费堆积优化方案

尽管通过扩容执行线程可缓解部分压力，但消息堆积仍是队列架构难以完全避免的问题。为此，还设计基于 Apollo 配置中心的动态消费规则 —— 支持热更新的配置项可在积压发生时，快速触发任务处理策略调整，包括：加速消费流程、临时忽略低优先级消息、暂停特定任务、剔除异常消息，或转发至备用 Topic 分流处理，实现故障场景下的灵活调度。

隧道代理：代理IP请求稳定性保障，实现代理故障切换，自定义轮询

1. 核心功能

• 多出口IP动态切换

  • 单域名绑定多个出口IP，支持按地区指定出口。
  • 客户端无感知切换，无需修改代码即可适配不同代理策略。

• 智能代理调度

  • 策略多样化：支持轮询、按成功率加权、黑名单自动剔除等策略。
  • 自动容灾：实时检测代理IP可用性，异常IP自动隔离并切换备用节点。

• 统一管理后台

  • 代理账号管理、IP分配规则配置、权限控制（如分业务线配额）。
  • 成本统计功能，按项目/业务线核算代理资源消耗。

2. 监控与运维增强

• 全链路监控

  • 采集代理IP的请求成功率、延迟、封禁率等指标，集成Prometheus+Grafana可视化。
  • 异常告警（如连续失败率超阈值触发企业微信通知）。

• 故障排查工具

  • 请求日志追踪（TraceID贯穿代理与业务系统）。

  • 支持手动强制切换IP，便于测试与问题复现。

下载器集群：实现低延迟，可复用的下载组件

在内容业务场景中，资源下载是核心环节之一。面对每日千万级别的文件下载需求，如何高效、稳定地完成大规模资源获取，同时支持多样化下载类型和优先级调度，成为亟待解决的问题。早期方案存在以下痛点：

1. 下载效率不足：单线程或简单多线程下载无法充分利用代理IP带宽，速度受限。
2. 扩展性差：新增资源类型（如视频、APK、压缩包）需重复开发适配逻辑。
3. 任务管理薄弱：缺乏优先级调度与异常任务自动剔除机制。

调研yt-dlp与aria2c的增强型下载器，整合在已有多线程下载服务中，构建了一套高可用、低延迟的下载组件，核心设计如下：

1. 架构设计

• 资源提取层（yt-dlp/自定义插件）

  • 插件化扩展：通过编写yt-dlp插件适配新站点，支持热更新，无需侵入式修改核心代码。
  • 协议兼容性：覆盖主流视频、音频、文件协议（如HTTP、FTP、HLS），与GitHub版本快速同步。

• 下载执行层（aria2c/yt-dlp/多线程）

  • 多线程加速：基于C++的高性能下载引擎，支持分块下载、断点续传，带宽利用率提升50%+。
  • RPC服务化：通过JSON-RPC接口暴露下载控制能力（如启动、暂停、进度查询）。

• 服务增强层（数据协议网关）

  • 功能扩展：封装aria2c原生RPC接口，补充缺失功能（如文件删除、任务优先级动态调整）。
  • 统一接入：提供标准化HTTP API，屏蔽后端技术细节，支持多语言业务调用。

2. 关键优化

• 任务调度

  • 支持任务优先级标记（如高优先级任务抢占资源）。

• 异常处理与容错

  • 自动重试失败任务，剔除连续超时的代理IP。
  • 监控下载速度与成功率，触发告警并降级处理（如切换备用下载源）。

• 资源类型泛化

  • 通过yt-dlp的提取规则与aria2c的多协议支持，统一处理视频、APK、压缩包等异构资源。

异步爬虫：独立部署，异步工作流建设

实时爬虫聚焦低延迟爬取需求，专为用户交互频繁的业务场景设计。为保障响应效率，未引入复杂业务逻辑，而是采用 “单一职责节点 + 多节点协作” 模式，通过拆分不同职能的独立节点，实现高效协同作业。

核心优势如下：

1. 架构灵活可扩展：核心爬虫服务拆分为独立节点，支持按需扩容与单独维护，有效降低服务耦合度，减少迭代风险。

2. 数据处理高效流畅：异步工作流、消息队列与 Flink 流处理联动，实现爬虫执行、数据清洗、存储全流程异步化，大幅提升数据流转速度。

3. 服务调用便捷：同步暴露 API 接口与任务队列接口，适配多样化服务调用场景，兼容性与适配性更强。

4. 职责边界清晰：节点专注核心爬虫与粗粒度数据清洗，后续数据处理由 Flink 与数据库承接，分工明确且易于维护。

云真机平台：设备农场搭建，任务编排执行

我们会有一些竞品调研，一次性抓取数据的业务场景。而这类场景有不少是在app端。但在app的数据获取常常需要先进行一些抓包分析，逆向参数等。为了维持业务高频率敏捷迭代的效率，提高需要相应效率，我们会选择使用通过自动化的手段进行数据获取。

通过分析日常需求场景，发现存在普遍共性的痛点。总结为三层架构，设备层，平台层，执行层

1. 设备层，解决如何找到设备，应该找哪些设备进行执行，应该选择哪种

2. 平台层，解决管理设备，设备状态监控问题

3. 执行层，解决任务定时执行，排队执行的问题

设备层，也可以称为设备农场。他负责提供接入的设备，降低开发人员获取设备的成本，提供多种类型设备接入。以系统分可以是ios，android。以架构类型分可以为x86， arm64。

目前行业常用的行业方案有三种，公有云真机集群，私有云真机集群和私有云虚拟机集群

平台层，依赖于开源云真机sonic项目进行实现，统一进行设备分配，管理，上下管理。同时他提供一套api负责对设备进行管理

执行层，负责管理定时执行任务脚本。这里我们没有使用sonic自带的sdk和定时任务环境。主要考虑是为了与现有执行程序统一调度，方便后续管理。