大规模员工邮件malware扫描系统架构及组件选型咨询

一、请求处理层（RS）：Hyper-Express的合理性 #

• 针对日均400万次请求的高并发场景，选择Hyper-Express替代Express完全合理。Hyper-Express基于uWebSockets.js，在吞吐量、延迟和内存占用上都远优于Express，能更好支撑大规模Webhook接收（来自Microsoft Graph API的邮件通知）。
• 额外优化建议：启用gzip压缩、设置合理的超时时间、配置连接池复用Graph API的请求连接，进一步提升RS的处理效率。

二、邮件处理层（PS）：Cluster模块的顾虑与替代方案 #

如果担心Node.js Cluster模块的扩缩容灵活性、进程间通信开销问题，可以参考以下方案：

1. 容器化+云原生扩缩容：放弃单纯依赖Cluster模块，将PS封装为Docker容器，部署到AWS ECS/EKS，配合AWS Auto Scaling根据SQS队列长度自动增减实例数。这种方式比Cluster更适合大规模场景，扩缩容粒度更灵活。
2. Cluster+PM2组合：如果坚持用Cluster模块，用PM2管理进程，PM2支持自动负载均衡、进程监控和重启，能降低Cluster的运维复杂度。
3. Worker Threads替代Cluster：对于CPU密集型的恶意软件检测任务，Worker Threads的内存共享和低开销比Cluster更优，适合单实例内的多核利用。

三、Azure Event Hubs对接邮箱订阅的实现路径 #

Microsoft Graph API暂不支持直接将邮件通知推送到Azure Event Hubs，但可以通过中间转接实现：

1. RS中转方案：保持现有RS通过Graph API订阅邮箱的流程，RS收到Graph的Webhook通知后，直接将消息转发到Azure Event Hubs。这种方式不需要额外服务，逻辑简单，且能利用Event Hubs的高吞吐量流式处理能力。
2. Azure服务转接：使用Azure Logic Apps或Azure Functions作为中间层，配置Graph API的Webhook触发逻辑，将通知消息转发到Event Hubs。这种方式无需修改RS代码，适合快速适配。
3. Event Hubs FIFO实现：如果需要类似SQS FIFO的顺序处理能力，可以通过设置Event Hubs的PartitionKey（比如用用户ID作为分区键），确保同一用户的邮件在同一个分区内按顺序处理。

四、高并发场景下的额外优化建议 #

• Microsoft Graph API批量订阅优化：使用Graph API的批量订阅接口（/submissions），一次性创建多个用户的订阅，减少API调用次数；设置合理的订阅过期时间（最长3天），并提前实现自动续订逻辑，避免订阅失效。
• 消息队列配置优化：
  • SQS长轮询设置为20秒（最大值），减少空轮询次数；调整批量获取消息数（可根据PS处理能力上调至10-100条）。
  • Event Hubs配置足够的分区数（建议按每1000条/秒吞吐量设置1个分区），确保高吞吐量下的性能。
• 恶意邮件存储优化：将恶意邮件内容或附件上传到S3时，使用分段上传（Multipart Upload）处理大文件；配合S3生命周期规则，将长期存储的文件归档到Glacier，降低存储成本。

内容的提问来源于stack exchange，提问作者Maya