# FetchesPublic

**Repository Path**: lsp5201314/fetches-public

## Basic Information

- **Project Name**: FetchesPublic
- **Description**: 这是一个测试中的分布式爬虫设计,基于.net core 3.1。开源只是为了回馈大家一点不一样的爬虫思路,还有很多坑没填。写了一个月,前面的两百次提交里,有好几次是大的重构 ,所以就不放出来扰乱思路了。
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-05-27
- **Last Updated**: 2021-07-31

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

## **Fetches**:这不是一个高性能爬取或方便数据抽取的爬虫框架
  首先，非常感谢webmagic项目，对该项目的学习使用是我采集程序框架化的起点。不过因为个性化需求和对c#的偏好，我转而为自己设计了Fetches爬虫框架。**Fetches的设计理念是，数据到手再说其他**  

  Fetches的概念中对一个页面的爬取会分为截然不同的两个阶段，**分别是由[fetcher](doc/fetcher.md)负责的数据获取阶段和由[processor](doc/processor.md)负责的数据加工分析阶段**。Fetches将fetcher作为核心管理调度，可以通过更换FetchFactory实现对fetcher弹性的部署调度(具体调度设计为与用户无关的黑盒)。对于数据的爬取，用户只需要将指定了fetcher类型的入库单提交到FetchFactory实例，之后凭回执消费爬取到的页面快照，由FetchFactory确保按要求入库数据。而对于页面快照的消费，Fetches框架未做分布式调度设计，只是简单的通过队列实现多线程处理，可能一次没处理完得重新处理。这样设计是因为两点因素：  
1.页面的获取通常是长期执行的低计算低IO型任务，可能大部分时间都在等待以避免触发目标站点的反爬虫机制。而页面的加工处理是瞬时的计算密集型任务，爬了几天的数据都不一定需要十分钟处理的  
2.对fetcher的定制基本是因为无法采取通用手段处理目标站的反爬虫手段，这种情况不是很多，太特殊的站还不如用python来获取页面了。但是processor的定制可能是从不同的维度提取数据，对同一个站可能会反复测试调整很多次，可能产生同名但实际效果完全不同的逻辑代码，processor甚至可能只是本地的一个lambda函数。所以为了避免频繁更新部署程序、降低部署难度，processor不考虑复杂的部署调度  
  Fetches中最大的特色就是分配到爬取任务的每个fetcher具有唯一ID，这样就可以简易的分配FetcherId来实现fetcher的本地和远程变换。

  **Fetches架构快速上手**：在OrderSubmit项目中创建订单(建议指定Fetcher数量为1)并提交到LocalFetchFactory爬取，单步调试跟踪运行流程。  
![输入图片描述](doc/architecture_diagram.png?v=1&type=image)  
  Fetches开发中主要的经验教训是 ***[不要盲目追求分布式，自己创造复杂性！](doc/notice.md)***