架构设计

架构设计：

第二版：

实现了第一版收集的需求。

解决了之前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虚拟机

扫描流程逻辑覆盖