Question

我正在寻找AWS architictural决定的方向。我的目标是允许用户将文件ftp到EC2实例，然后对该文件运行一些分析。我的重点是尽可能以面向服务的方式构建它。并且在未来将其扩展到多个客户端，其中每个客户端都有自己的ftp服务器和处理队列，而不会混合数据。

目前我有一个安装了vsftpd的dev EC2实例和一个运行Chokidar的node.js进程，该进程持续监视要删除的新文件。当该文件丢失时，我希望通知另一台服务器或服务器组获取文件并进行处理。

ftp服务器是否应该将文件移动到S3然后使用SQS让处理服务器池知道它已准备好进行处理？我应该使用SQS然后将服务器池ssh放入ftp实例（或其他方法）来获取文件而不是使用S3作为中介吗？有更好的方法吗？

非常感谢任何指导。随意学习任何可能在高文件量下节省资金的其他想法。

Answer 1

我将它分成小组件。

这样，您可以根据需要扩展ftp服务器，或者扩展处理服务器（在SQS队列长度或处理器利用率上）。您可能最终得到一台ftp服务器和5台处理服务器，反之亦然 - 但至少这种方式只能缩小瓶颈。

您可能想要看的另一件事是DataPipeline - 它（虽然不知道您的工作细节）听起来像是为您的用例量身定做。

S3和队列很便宜，它可以根据需要对不同组件进行更细粒度的控制。围绕通配符策略和IAM可能会有一些明智之处，可以用来收紧数据隔离。

Answer 2

理想情况下，我会尝试在当前放置的服务器上处理该文件。这将节省大量的网络流量和CPU负载。

但是，如果您希望其中一个服务器像反向代理并在服务器场之间进行负载平衡，那么我将通过http调用通知服务器该文件已到达。我会通过ftp使文件可用，因为你已经有了工作vsftp这将不会有问题，并且将在http调用中包含文件ftp url，因此将进行处理的服务器可以获取文件并立即开始处理它

通过这种方式，您可以通过不使用任何额外的S3或SQS或任何其他附加服务来节省资金。

如果服务器群由相同类型的服务器组成，那么如果服务器具有不同容量，则分配负载的算法应为RoundRobin，然后应根据服务器性能进行负载分配。

例如，如果服务器ONE的执行速度是服务器3的3倍，服务器TWO的性能是服务器3的2倍，那么您可以这样做：

1: Server ONE - forward 3 request
2: Server TWO - forward 2 request
3: Server THREE - forward 1 request
4: GOTO 1

理想情况下，应该有来自服务器的报告当前负载的反馈，因此负载均衡器知道谁是下一个请求的最佳候选者而不是使用硬编码算法，因为可能请求不需要完全相等的要处理的资源，但这开始看起来像Map-Reduce paradigm并且超出范围......至少在开始时。：）

Answer 3

如果您想坚持使用S3，可以使用RioFS将S3存储桶作为FTP和处理服务器上的本地文件系统进行安装。然后你可以进行常规的文件操作（例如：在创建/修改文件时获取通知）。

Answer 4

RioFS s3fs-fuse利用FUSE提供可安装的文件系统（虚拟本地）; s3fs-fuse目前是well-maintained。

相比之下Filesystem Abstraction for S3, HDFS and normal filesystem swineherd-fs允许使用不同的（本地虚拟）方法：

All filesystem abstractions implement the following core methods, based on standard UNIX functions, and Ruby's File class [...]。

作为本地抽象层＆＃39;已经Only thoroughly tested on Ubuntu Linux我亲自去找一个更主流/固体/更少实验性的堆栈，即：

或者，更实验性的是，有一些github项目可能适合它：

最后但并非最不重要的是，如果在OSX上，我建议使用donationware Cyberduck - 一个舒适（并且非常类似FTP）的客户端直接连接S3。对于Windows，有一个名为S3 Browser的（ PRO 可选）免费软件。