可扩展 Web 应用程序的服务器架构

Question

我们正计划使用 Amazon OpsWork 部署一个 Web 应用程序，我只是想与您确认一下我们的架构是否存在任何设计缺陷。

我们有 4 个组件：

1. 负载均衡器（最好是亚马逊）
2. 基于Node.js的表达
3. MongoDB
4. 弹性搜索

这是我们组件的通信图：

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

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

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

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

非常感谢！

Answer 1

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

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

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

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

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

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

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

3) ELB 不支持网络套接字。如果您认为将来可能需要 websocket，请考虑一下。

Answer 2

弹性搜索中没有大师之类的东西。您拥有分片的主副本和分片的副本，但它们基本上是通过弹性搜索在您的集群中移动的。节点可能是一个分片的主节点，而另一个分片的副本。因此，您可以简单地在其前面放置一个负载均衡器。

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

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

Answer 3

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