66 lines
3.5 KiB
Markdown
66 lines
3.5 KiB
Markdown
# 益盟操盘手数据抓取器
|
||
|
||
## 前言
|
||
|
||
比起将其整合到整个平台应用中，解耦出一个数据抓取器更加便于维护和管理。抓取器只需要**获取股票池**并**定时更新**。
|
||
|
||
## 获取股票池
|
||
|
||
股票池从存放 tushare 数据库获取。抓取器应该能配置简单的股票池筛选规则，如仅限沪深 A 股。这个筛选规则可以是默认的，因为似乎益盟操盘手没有北交所数据。
|
||
|
||
获取股票池可以直接通过数据库读取。
|
||
|
||
## 更新
|
||
|
||
### 更新内容
|
||
|
||
应提供后台，对更新的内容进行配置，如：需要更新的指标、指标的参数等。
|
||
|
||
由于从益盟 5.0 版本开始，更新的指标名称由代码替代，所以在系统上也需要提供一份指标名称和代码的对应关系，以便用户能方便地选取指标。~~另外，指标参数是否可以通过逆向工程找到其参数名、值类型和范围？是否有必要？需要评估。~~
|
||
|
||
指标参数除益盟 APK 内默认的 config_ind_online.json 外，每次启动程序还会从网上抓取一份最新的。可以通过实现抓取来获得最新配置。
|
||
|
||
另外，最好在平台上有方式对请求进行测试。每次更新前都需要确保既定的访问正常，一旦发现异常情况须立即停止更新，并对管理员发出警告。
|
||
|
||
### 更新频率
|
||
|
||
考虑以下两种方式：
|
||
|
||
1. 可使用 cron 表达式进行更新频率的配置。该表达式应该是忽略当日是否是交易日的，比如周末当然也可以运行更新。
|
||
2. 使用写死的逻辑代码进行更新。
|
||
|
||
### 更新配置
|
||
|
||
更新过程中的最大线程数、循环延时应提供相应后台进行管理配置。
|
||
|
||
### 更新进度
|
||
|
||
更新进度应可视，进度是已更新股票数÷股票总数。过程应统计平均每支股票的更新时间，得出剩余时间：已用时间÷已更新股票数×未更新股票数。
|
||
|
||
## 日内更新和推送通知
|
||
|
||
对于需要特别关注的股票，应提供接收**特别关注股票**的接口（入池、出池）、推送功能、更新频率设置，供日内特别关注。
|
||
|
||
接口应以某种方式来验证是否是合法请求。
|
||
|
||
## 其他配置
|
||
|
||
益盟 client 参数，包括使用的用户参数、设备参数等，应提供简易后台进行配置。~~未配置时使用 application.yml 的默认配置，配置后优先使用后台配置。后台配置应可以进行导出（复制），方便对 application.yml 内容进行替换。~~使用本地 JSON 保存配置。默认配置应在对应配置类内提供初始值，当本地无 JSON 时从配置类内初始化保存在本地。
|
||
|
||
## 环境配置
|
||
|
||
### 测试环境
|
||
|
||
测试环境需要配置好 Clash、Proxifier。Proxifier 需要指定 Java 访问 80 端口时通过 Clash 出，以免益盟追溯。Clash 部分，需要对益盟网址 Phaser 进行设置，强制使用代理访问。
|
||
|
||
访问数据库不需要过代理，可以直连。
|
||
|
||
### 生产环境
|
||
|
||
暂未确定生产环境是否在本地环境。若在本地环境，可以选用 Windows 电脑，按照测试环境进行配置。若在云环境，必须明确所用云服务器是国外服务器。
|
||
|
||
当使用云环境作为生产环境时，须明确主数据库所在位置。若主数据库位于本地环境，则需要 frp 或其他内网穿透软件进行穿透。
|
||
|
||
## 预案
|
||
|
||
对于可能暴露的情况，需要准备预案，对内容进行销毁。可以为程序添加“毁灭模式”，一旦被触发，自动清除程序和附加的文件。 |