如何设计一个分布式node.js web服务器

Question

假设我需要实现一个有大量并发用户的web应用程序。我决定使用node.js，因为它的伸缩性很好，它有很好的性能，开源社区等等，等等。然后，为了避免瓶颈(因为在同一个事件循环中可能有大量用户),我决定使用一个进程集群来利用多核CPU。此外，我有3台机器(main 2 ),因为我需要用Cassandra处理大数据。太棒了，这意味着我有3*n个node.js进程，其中n是cpu的核心数(机器是相同的)。

好的，然后我开始一项研究，并以以下模式结束：

< li>Nginx侦听端口80，仅用于提供静态内容(img、css、js等)。< br >将动态流量转发给haproxy。我知道如何配置nginx，但我仍然需要看看haproxy，所以我会说haproxy正在监听4000端口。Nginx和haproxy安装在主机中(入口点)。 < li台机器之间的Haproxy负载平衡。它将流量转发到端口4001，即node.js进程正在侦听4001。 < li >每个node.js都有一个监听4001的n进程集群。

如果我是正确的，那么单个http请求将被转发到单个节点。js流程。

创建会话是很正常的，对吧？会话只是一个映射，而这个映射是一个Object，而这个Object生活在一个node.js进程中。Haproxer将配置一个循环调度程序，因此同一个用户可以被转发到不同的node.js进程。如何在所有node.js进程中共享同一个会话对象？如何共享一个全局对象（这包括在同一台机器（node.js集群）和整个网络中）？我应该如何设计一个带有node.js?的分布式Web应用程序？有没有什么模块可以简化同步任务？

Answer 1

正如另一位用户所建议的；使用Redis是解决这个问题的一个完全可以接受的解决方案。

它的本质是使用服务来存储会话对象，让中间件来处理其他事情。如前所述，它在节点进程重启、崩溃等情况下非常有用。将会话数据存储在节点流程中存在风险。使用微服务(如Redis)的好处之一是降低了这些风险。

假设您将Express用于中间件，则可以使用名为会话存储。有许多模块可以利用此功能。

其中一个模块是connect redis

像往常一样，安装是轻而易举的：

npm install connect-redis express-session

然后你会这样使用它：

var session = require('express-session')
var RedisStore = require('connect-redis')(session)

app.use(session({
    store: new RedisStore(options),
    secret: 'keyboard cat'
}))

现在您可以像往常一样使用会话对象了。（req.session）

例子：

要设置会话信息（例如，从表单 POST 中）：

req.session.email = req.body.email

< br >要检索会话信息:

console.log( req.session.email )

Answer 2

正如 Ivan 所指出的，您将会话对象存储在内存缓存或 redis 中，甚至是沙发库（内存缓存存储桶）中。我还想补充一点，如果你想构建一个可扩展的系统，你的目标应该是以一种可以线性扩展的方式构建系统，以根据需求增加吞吐量。我的意思是，您应该能够随时（最好在高峰期）将更多主机添加到基础架构中的不同层以处理需求。

所以你必须非常小心你选择的技术和你在开发过程中做出的设计决策。

因此，我需要实现一个将具有大量并发用户的Web应用程序。

我想补充的另一件事是，如果你不能衡量它，你就无法管理它。一个好的开始是定义“大量并发用户”对您意味着什么？这是脸书还是应用程序类型的卷/并发？首先通过与您的利益相关者（如果有的话）合作来定义这些，然后您就可以开始做出设计决策和选择技术。

在构建可扩展系统时，一个好的试金石是问自己，“是否存在单点故障？”，如果是，那么你的系统将无法扩展。

Answer 3

您可以使用memcache或redis来存储会话对象。这在重启节点进程的情况下非常有用(如果会话数据存储在进程的内存中，它将会丢失)。

此外，您还可以查看pm2功能列表，其中一些可能对您有用。

构建微服务架构将具有良好的可扩展性。