amazon-s3 - 什么是 RESTful Web 服务最具可扩展性和高性能的 Amazon Web Service (AWS) 配置？

Question

我正在构建一个异步 RESTful Web 服务，并试图找出最具可扩展性和高性能的解决方案是什么。最初，我计划使用 FriendFeed 配置，使用一台运行 nginx 的机器来托管静态内容，充当负载均衡器，并充当运行 Tornado Web 服务器的四台机器的反向代理以获取动态内容。建议在四核机器上运行 nginx，在单核机器上运行每个 Tornado 服务器。 Amazon Web Services (AWS) 似乎是最经济、最灵活的托管服务提供商，所以我的问题如下:

1a.) 在 AWS 上，我只能找到 c1.medium(双核 CPU 和 1.7 GB 内存)实例类型。那么这是否意味着我应该在 c1.medium 上运行一个 nginx 实例，在 m1.small(单核 CPU 和 1.7 GB 内存)实例上运行两个 Tornado 服务器？

1b.) 如果我需要扩大规模，我如何将这三个实例链接到同一配置中的另外三个实例？

2a.) 在 S3 存储桶中托管静态内容更有意义。 nginx 还会托管这些文件吗？

2b.) 如果没有，性能会因为没有 nginx 托管而受到影响吗？

2c.) 如果 nginx 不托管静态内容，它实际上只是充当负载均衡器。有一篇很棒的论文 here比较了不同云配置的性能，并谈到了负载均衡器:“HaProxy 和 Nginx 在第 7 层转发流量，因此由于 SSL 终止和 SSL 重新协商，它们的可扩展性较差。相比之下，Rock 在第 4 层转发流量，没有SSL 处理开销。”您是否建议将 nginx 作为负载均衡器替换为在第 4 层上运行的负载均衡器，或者亚马逊的弹性负载均衡器是否足够高性能？

Answer 1

1a) Nginx 是异步服务器(基于事件)，只有单个工作人员本身可以处理大量同时连接( max_clients = worker_processes * worker_connections/4 ref )并且仍然表现良好。我自己在 c1.medium 类型的盒子(不是在 aws 中)上测试了大约 20K 的同时连接。在这里，您将工作人员设置为两个(每个 cpu 一个)并运行 4 个后端(您甚至可以测试更多以查看它在哪里中断)。仅当这给您带来更多问题时，请选择更多类似的设置并通过 elastic load balancer 链接它们

1b)如(1a)中所述，使用弹性负载平衡器。见 somebody tested ELB对于 20K reqs/sec，这不是限制，因为他放弃了，因为他们失去了兴趣。

2a) 在 cloudfront 中托管静态内容，它的 CDN 正是为了这个目的(比 S3 更便宜、更快，它可以从 s3 存储桶或您自己的服务器中提取内容)。它的高度可扩展性。

2b) 显然，使用 nginx 服务静态文件，它现在必须为相同数量的用户提供更多请求。减轻负载将减少接受连接和发送文件的工作(减少带宽使用)。

2c)。完全避免使用 nginx 看起来不错的解决方案(少一个中间人)。弹性负载均衡器将处理 SSL 终止并减少后端服务器上的 SSL 负载(这将提高后端的性能)。从上面的实验它显示了大约 20K 并且由于它的弹性它应该比软件 LB 拉伸(stretch)更多(参见 this nice document 关于它的工作)