我已经找到了Event loop for large files?,但这主要是关于下载的.我从那篇文章中得出的结论是,node.js可能已经足够进行下载,但是Nginx是一个经过艰苦奋战的解决方案,“永不中断”.

但是上传呢？我们正在上传大量文件.我们进行基因组学研究,人类基因组数据集的大小高达200GB.据我所能确定的,Nginx总是在将完整的请求,标头和正文转发给后端之前,对整个请求进行缓冲.我们的内存用完了,无法同时处理三个上载.

我们的应用程序中运行着大量小型服务器,“做一件事情并做得很好”,其中一台用于处理基因组数据的上传(以及将类型转换为内部格式),另一台提供套接字. .io处理,以使客户对我们的应用程序生态中的上传进度和其他事件进行评估.其他人则处理身份验证,客户数据处理和普通在线媒体服务.

如果我正确阅读了节点的http / https模块的代码,则node.js将是处理这些问题的理想工具：它本身就是HTTP / 1.1,因此websocket传递将起作用,并且它会处理(请求,响应)在处理了HTTP HEAD之后将元组添加到处理程序函数,但保持BODY不变,直到处理程序函数绑定request.on(‘data’,…)事件以耗尽BODY缓冲区.

我们为我们的服务提供了一个细分的,基于url的名称空间：“ / import”,“ / events”,“ / users”,“ / api”,“ / media”等.Nginx仅正确处理了后三个.用node.js应用程序替换Nginx来处理所有这些操作是否困难或不合适？还是有一些晦涩的反向代理(Nginx,Pound和Varnish都有类似的限制),它们已经可以满足我的所有需求了？