可伸缩Web应用程序的服务器体系结构

Question

我们计划使用Amazon OpsWork部署网络应用程序，我只是想与您联系，看看我们的架构是否存在任何设计缺陷。

我们有4个组成部分：

1. 负载balanacer（最好是亚马逊）
2. Express基于Node.js
3. MongoDB的
4. ElasticSearch

以下是我们组件的通信图：



前端是负载均衡器，可将http请求分发到多个Web服务器。

Web服务器是无状态的，因此每次负载需要时都可以克隆它。所有Web服务器实例都相同。会话信息保存在MongoDB中。

在“后端”中，我们计划使用MongoDB和ElasticSearch的内置集群功能。因此，每个Web服务器实例仅连接到单个MongoDB和ElasticSearch主实例。然后MongoDB和ElasticSearch相应地进行扩展。此外，ElasticSearch主服务器与MongoDB主服务器通话以检索用于构建索引的数据。

我们如何看待它，设置这样一个系统最具挑战性的任务是使用MongoDB和ElasticSearch集群配置OpsWorks。

非常感谢提前！

Answer 1

  

如果我们的架构可能存在任何设计缺陷。

好吧，请记住，我们不能从通用图表中说出太多。但这里有一些注意事项：

1）MongoDB不像其他数据库（如DynamoDB，Riak或Cassandra）那样容易扩展。例如，如果您超过单个主设备的容量（无论您有多少个从设备，所有写入都转到单个主设备），您将不得不进行分片。但是切换到分片是非常具有破坏性的，而且设置起来非常繁琐。

如果您不希望超过一个节点的写入容量，那么MongoDB就可以了。

2）您将如何处理异步任务，例如发送电子邮件，创建长报告等？

可以在请求循环中执行这些操作，这可能是一个很好的入门方法。但是当你有更多的盒子时，失败的可能性就会增加。当一个盒子死掉时，所有的异步任务都会消失，没有人会知道它们是什么。你也可能遇到一个问题，即一个盒子负载过多的异步任务（使用太多的CPU或内存），问题会变得越来越糟，因为它会获得更多的任务并且更慢地完成它们。

此外，像ELB这样的前端将有60秒的限制，如果您的某些请求可能需要更长时间，这可能会导致问题。 （通过轮询等方式将它们转移到异步作业中。）

3）ELB不支持Web套接字。考虑一下，如果您认为自己可能需要使用websockets。

Answer 2

在弹性搜索方面没有掌握这样的东西。您拥有分片的主副本和分片的副本，但它们基本上通过弹性搜索在群集中移动。节点可能是一个分片的主节点，另一个是副本的副本。所以，你可以简单地在它前面放一个负载均衡器。

但是，您可以将节点专门化为数据节点或路由节点，如下所述：http://www.elasticsearch.org/guide/reference/modules/node/

路由节点有效地成为负载平衡器。你可以有一些（冗余）并在它们之间分配负载。或者，您可以在每个Web服务器上运行专用路由器节点。基本上路由节点非常轻，您节省了一些带宽/延迟，因为您的Web服务器与localhost通信，并且从那里它是所有弹性搜索内部群集流量。

Answer 3

我建议用Amazon Dynamo DB替换MongoDB（它有node.js SDK）。