📚 课程目录第4章渗透测试平台架构设计

模块化 · 插件系统 · 分布式扫描

平台架构的模块化程度直接影响扩展性、部署效率和扫描稳定性。面试官会重点考察你对“高内聚、低耦合”的实现能力，以及面对分布式场景下的任务调度、数据一致性与性能瓶颈的权衡思路。

Q1：如果让你设计一个模块化的渗透测试平台，你会如何划分模块？为什么？

考察点	架构能力、高内聚低耦合原则、对渗透测试流程的理解
回答框架	①按职责划分：扫描引擎、插件管理、数据存储、任务调度、报告生成；②每个模块暴露接口，通过配置或SPI实现解耦；③举例说明模块间通信采用事件驱动。
示例回答	我会划分为五模块：引擎层（负责协议/端口/漏洞扫描）、插件层（热插拔各类检测脚本）、数据层（结果持久化与缓存）、调度层（任务分发与重试）、展示层（报告与可视化）。模块间通过事件总线通信，例如扫描完成触发结果存储与报告更新，互不阻塞。
可能追问	模块间若需要共享状态（如扫描进度），你会怎么设计？
避坑提醒	避免“大泥球”式分层：不要把全部逻辑塞入一个“通用模块”。必须明确每个模块的职责边界，否则后期分布式拆分会非常痛苦。

Q2：插件系统如何保证热加载安全和版本兼容？

考察点	类加载机制、沙箱隔离、插件生命周期管理
回答框架	①自定义ClassLoader实现隔离，避免冲突；②定义插件接口（Plugin接口+Manifest描述）；③卸载时清理资源（线程池、连接池）；④版本通过语义化版本号做兼容校验。
示例回答	使用单独的URLClassLoader加载每个插件JAR，并设置父ClassLoader为框架类加载器以共享核心API。插件必须实现Plugin接口并声明版本。卸载时调用plugin.destroy()，再drop ClassLoader引用，确保GC回收。同时通过版本比较器阻止不兼容的低版本覆盖高版本。
可能追问	如果插件A依赖插件B的某个版本，你怎么处理？
避坑提醒	不要以为插件卸载后系统一定正常：要处理线程残留、文件句柄泄漏、定时任务未取消等。务必在测试环境验证热加载后再上线。

Q3：分布式扫描任务如何分片？如何保证扫描结果不重复不遗漏？

考察点	分布式一致性、分片算法、去重与幂等设计
回答框架	①按IP段/域名哈希一致性分片；②使用消息队列（Kafka/RocketMQ）保证at-least-once投递；③worker处理时写入任务状态表（如Redis+DB双写），通过分布式锁或乐观锁防止重复执行；④扫描结果通过唯一ID（task_id+target_key）去重。
示例回答	按目标哈希值模worker数量分片，保证相同IP始终路由到同一worker便于缓存。任务使用RocketMQ顺序队列，worker消费时更新任务状态为“执行中”，写入结果前用任务ID+目标地址作为唯一键做upsert。使用Redis SETNX加锁防止同一任务被两个worker同时处理。
可能追问	如果某个worker扫描到一半宕机，任务如何恢复？
避坑提醒	别高估网络稳定性：消息队列的重复投递是常态，worker端必须实现幂等。另外分片粒度过细会导致调度开销过大，过粗则负载不均，建议以/24网段为单位预分片。

项目名称	分布式安全扫描平台 “VulnEye”
业务背景	内部安全团队需对每日新增的500+业务系统做自动化漏洞扫描，并支持自定义检测插件，要求扫描结果1小时内产出。
规模指标	日均扫描目标IP数 20万+；插件库 300+；结果存储量 1TB/月；平均扫描时长 45分钟。
技术栈	Spring Boot + Netty（插件容器）、Redis + MySQL（任务状态）、Kafka（消息队列）、Kubernetes（worker弹性伸缩）、S3（结果存储）
核心难点	①热加载插件导致内存泄漏；②高并发下任务分配不均衡，部分worker过载；③国产系统（麒麟）上扫描引擎兼容性问题。
面试高频追问	Q：你是如何定位并解决插件内存泄漏的？ Q：任务倾斜时你如何动态调整分片？ Q：如何保证K8s上worker缩容时正在执行的任务不被中断？
可迁移回答话术	“我们通过自定义ClassLoader隔离每个插件，并周期性执行`weakReference + referenceQueue`检测未回收的类，配合`jmap`分析发现部分插件持有静态线程池引用，改为插件销毁时强制`shutdown()`后解决。对于任务倾斜，我们引入分段动态分片：worker心跳上报当前负载，调度器根据负载系数重新分配待扫描队列，而非固定哈希分片。”

💡 备考建议： 架构设计题在面试中通常以场景题出现，不要只背框架，要结合你实际做过的项目说明决策依据。分布式部分重点理解“幂等”、“最终一致性”、“任务回溯”三个核心概念。