| ... | ... | @@ -48,6 +48,35 @@ |
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
### 值得学习的地方
|
|
|
|
|
|
|
|
```buildoutcfg
|
|
|
|
1. 为团队引入了基于aiohttp，协程的异步爬虫框架，相比scrapy消耗资源更少，扩展性更好。但是文档相对较少，解决问题和入门的成本有增加。
|
|
|
|
2. `SpiderRequest`类对(POST,GET)请求做了封装。
|
|
|
|
3. 解析部分做的很统一,`Manger`里面注册了`parser_register`,由选择器和解析器共同组成,基于`jsonpath`和`xpath`的解析,解析的方法一目了然，并且具有良好的扩展性
|
|
|
|
3. 类的定义很清晰，多个爬虫之间的隔离很明确，整体结构已读，但是调用流程嵌套太多
|
|
|
|
```
|
|
|
|
|
|
|
|
### 建议
|
|
|
|
|
|
|
|
- `main.py`程序入口
|
|
|
|
- 入口部分主要解析的命令行参数，然后启动一个爬虫实例，可以尝试用`click`代替这部分，更为直观
|
|
|
|
- 目前一个命令行只能启动一个爬虫，如果爬虫数量多是否难以维护。
|
|
|
|
|
|
|
|
|
|
|
|
- 任务相关的一些问题
|
|
|
|
- `Manager.run` 任务失败后会重新将任务放到redis,直到redis为空才会结束任务。
|
|
|
|
- 失败后应记录下失败原因，失败的次数要有限制。
|
|
|
|
|
|
|
|
|
|
|
|
- 关于这个爬虫框架相关的建议
|
|
|
|
- 可复用性不好，假设我要用这个框架来开发新的项目，我希望只写，获取任务的方法，请求方法，解析放法，以及他们的回调关系，并且定义这些的地方不要太分散
|
|
|
|
- 希望异步的请求可以跟业务相关的编码分开，就是编码的最好是同步的，可以通过代码很清晰的读出流程，不要有太多和太多次的方法的传递。`run_func`,`parser_func`
|
|
|
|
- 多定义一些变量，少一些函数的参数传递
|
|
|
|
- 与团队现有的流程可以进行一定程度的融合，并且解析部分其实很容易出错的，这个框架也没看到一个定义期望结果和检验结果的模块
|
|
|
|
|
|
|
|
|
|
|
|
### 改进落实
|
|
|
|
|
|
|
|
```buildoutcfg
|
| ... | ... | |
