架构设计：
第二版：
实现了第一版收集的需求。
解决了之前agg单点，不能横向扩展，不能并发执行，没有高可用的问题
解决了文件打包，文件编排，扫描一致性问题
i) 编排。类似spark 的driver，executer，有向无环图。参考：https://spark.apache.org/
ii）服务注册与发现。参考：https://blog.csdn.net/CSDN2497242041/article/details/117999871
iii）单机进程组协调管理。
1，文件对单台机器只下载一次（不会下载多次）
2，支持扫描编排
3，支持文件打包
4，可以横向扩展扩容，MySQL，mongo，http微服务均可以横向扩展扩容
5，良好的扩展性，支持动态增减扫描引擎。服务注册与发现机制，及声明式编排部署，支持动态增减扫描引擎
6，高可用性。服务注册发现，MySQL，mongo，http 都是高可用的
目标
支持200w的扫描能力，能够扫完每天s新增的，并能够支持Q2商业用户的量( MySQL，mongo，http微服务均可以横向扩展扩容）
支持WEB用户扫描（数据库字段，或额外表，甚至格外机器）
支持基础的回扫策略（含义是重投front吗）
支持中等规模业务量，可以保证技术故障情况下的可用性，故障发生时可以通过手动切换到备用资源，故障发生时保证数据不丢失（自动切换，数据不丢失）
1. 保证web用户扫描进度有较好的体验；（支持优先级，扫描细粒度编排。可根据表中数据与扫描平均速度做进度条）
2. 保证商业用户API调用，每个文件平均的最短返回时间；（可水平扩容，降低数据量，从而优化到需求时间）
3. 灵活扩容,运维友好（灵活扩容）
4. 保证最少的US3下载次数（一个机器只下载一次）
5. 扫描流程变更时可以快速调整，而不是大规模改代码和部署变更 （支持扫描编排）
需求
-
- 良好的扩展性，支持动态增减扫描引擎;支持每天200w/day的扫描量，并支持扩展到300w/day以上的能力（支持）
- 高可用，设计时应当考虑扫描服务的可用性；（支持）
- 支持限流、熔断（在front端？）
多租户支持？账户系统- 扫描时支持优先级（支持）
- 支持微服务编排，支持灵活的扫描策略；支持编排能力，允许持续改进扫描流程（支持）
- 运维友好，监控关键指标并告警；整个系统业务运行具被可观测性（支持）
- [WWW]支持WEB调用，能够高优先级扫描；扫描进度支持，（支持，进度可读MySQL计算）
- 支持扫描完成后主动通知用户 notify（支持）
- 降低单个文件扫描下载次数，尽量做到最多两次下载（linux、windows各一次)（支持）
- 文件类型识别，web 脚本走webshell检测（支持，已经支持定向投递和编排）
- 支持沙箱静态检测能力（Q3？）（支持）
- 富文本检测 （支持）
- 调度策略可用性，保证at least once （支持，write ahead log）
- 自动化可控样本分发服务SDS上线
- 支持大文件扫描，支持FTP接入
- 多引擎虚拟化？
- 任务系统对S提供接口，集成S的多引擎
三，FAQ
1，重试队列是啥？怎么实现的？
重试队列，用MySQL表 write ahead log
后台协程做checkpoint
成功的扫描。
master往下走
写表成功（1，2，3，4）所谓重做，就是重新投递路由模块
下边操作失败（返回）
操作
操作
2，web用户，或其他用户，被卡，或者失败补偿时如何处理。保证高体验性？
设置超时时间，超时后自动失败，调高优先级重新投递路由模块开启新的扫描
3，整体扫描时间是多少？
扫描最短时间取决于最慢的扫描引擎
4，win1，lin1，lin2
lin1和lin2还没有返回值，正在扫
win1断开，失联，获取不到信息状态
路由模块怎么处理这种情况？
1，win1断开，路由模块一定知道失败了。控制模块知道失败了，同步情况下，lin1和lin2返回成功也忽略了。
2，win1断开，路由模块一定知道失败了。控制模块知道失败了，异步情况下，lin1和lin2已经入库，checkpoint重做表时，发现lin1和lin2已经扫了，就只重扫win1
评审答疑：
agg使用MySQL如何解决扩展和并发及高可用的？
MySQL的表，支持两个时间复杂度是O(1)的操作，分别是select max(id) from table. select min(id) from table。这样任意一个表，相当于是取到了表头和表尾的下标，头尾指针向中间扫。所以一种扫描策略也可以并发
然后有了首尾下标后，min(id) = 1,比如取前10条加写锁处理。这时候第二个进程再取1到10加写锁，我记得是会返回失败。然后第二个进程就可以从10+1=11，取到20了。 因为加锁失败的速度很快，第一个进程文件没扫描完，第二个进程已经开始进入11到20的处理了
如图测试环境复现：
前两条会快速失败，只有第三条才成功，因为第三条的id已经大于4了。第一条语句只把id为1和4的两条数据加了行锁。这样就可以集群交替并发，而且保障事务等。
四，记录输出：
一，哪里可以做
1，MySQL可以做vstask打包，但需要提供golang用哪一个mysql客户端？
gorm就可以，gorm是支持事务的，参考https://www.kancloud.cn/sliver_horn/gorm/1861176
2，DAG可以用，怎么实现？
第一版，可根据扫描策略，每个扫描策略实现自己的dag流程。
二，哪里需要改进
1， 如果同步，http长连接时间的问题，这里怎么解决？如果异步怎么做编排？
可以使用类netty的网络通信模型，路由模块和扫描中控模块分别设置两个收发消息的结构，inbox和outbox，使用异步的AIO通信模型。
参考：https://blog.csdn.net/Android_xue/article/details/102919623
https://blog.csdn.net/u011564172/article/details/60143168
https://blog.csdn.net/u010374412/article/details/103478654
https://github.com/ColZer/DigAndBuried/blob/master/spark/spark-network-netty.md
https://masterwangzx.com/2020/07/23/RpcMessage/
三，还需要cover哪些需求与场景
1，引擎对文件是能并行扫的吗？还是会锁文件，导致串行扫描。哪些引擎会？
5-16请教，有可能有冲突
2，多个引擎同时并发扫大量文件，最多能支持多少个文件的同时扫描。（比如多少进程。）
四，需要补充
这个架构，扫200w,需要多少资源，机器,cpu 内存
之前架构资源需求量，及实现业务量： 实现了每天20w-30w的扫描能力，使用了
linux：
1个 2c2g
2个 4c8g
4个 16c16g
8个 4c4g
12个 2c4g
共10+64+32+24=130核cpu
2+16+64+32+48=162g内存
windows：
4个 16c16g
4个 8c8g
16个 4c4g
共 64+32+64=160核cpu
64+32+64=160g内存
共，290核cpu，322g内存
第一版后，收集到的新需求：
1. 保证web用户扫描进度有较好的体验；
2. 保证商业用户API调用，每个文件平均的最短返回时间；
3. 灵活扩容
4. 保证最少的US3下载次数
商业API调用，扫描要达到分钟及响应
1：优先级扫描
二次扫优先级
文件类型check
，在分发之前
架构更细化到流程图
每个case覆盖到
扫描流程变更时可以快速调整，而不是大规模改代码和部署变更
商业用户分钟级别，api级别的响应时间
windows容器化研究
wine windows虚拟机
扫描流程逻辑覆盖
标签：架构设计,模块,扫描,支持,编排,https,MySQL From： https://www.cnblogs.com/mmgithub123/p/17136927.html