如何使用多核，反向代理和SSL在云中部署Node.js以实现高可用性 [英] How to deploy Node.js in cloud for high availability using multi-core, reverse-proxy, and SSL

问题描述

我已经发布到ServerFault，但Node.js社区似乎很小，所以我希望这会带来更多的曝光。

I have posted this to ServerFault, but the Node.js community seems tiny there, so I'm hoping this bring more exposure.

我有一个Node。 js（0.4.9）应用程序，并正在研究如何最好地部署和维护它。我想在高可用性的云（EC2或RackSpace）中运行它。该应用程序应该在HTTPS上运行。我会担心以后的东/西/欧盟全面故障转移。

I have a Node.js (0.4.9) application and am researching how to best deploy and maintain it. I want to run it in the cloud (EC2 or RackSpace) with high availability. The app should run on HTTPS. I'll worry about East/West/EU full-failover later.

我已经做了很多关于keep-alive（Upstart，Forever），多核的实用程序（Fugue，多节点，集群）和代理/负载平衡器（node-http-proxy，nginx，Varnish和Pound）。但是，我不确定如何组合我可用的各种实用程序。

I have done a lot of reading about keep-alive (Upstart, Forever), multi-core utilities (Fugue, multi-node, Cluster), and proxy/load balancers (node-http-proxy, nginx, Varnish, and Pound). However, I am unsure how to combine the various utilities available to me.

我有这个设置，需要解决一些问题并获得反馈。 >

I have this setup in mind and need to iron out some questions and get feedback.

1. 集群是Node.js中最积极开发和看似流行的多核实用程序，因此使用它来运行1节点群集每个应用服务器在非特权端口（例如3000）。 Q1：应该使用永远来保持集群存活还是冗余？


2. 使用1 nginx 每个应用服务器在端口80上运行，只需逆向代理端口3000上的节点。 Q2： 节点http-proxy 更适合此任务，即使它不能快速gzip或服务器静态文件？


3. 如上所述，最少有两台服务器，独立服务器充当这些盒子的负载均衡器。使用 Pound 侦听443终止HTTPS，并将HTTP传递给 Varnish ，这将使上述服务器的IP上的负载平衡。 Q3：应该使用 nginx 来代替？ Q4：如果考虑AWS或RackSpace负载均衡器（后者不会终止HTTPS）

1. Cluster is the most actively developed and seemingly popular multi-core utility for Node.js, so use that to run 1 node "cluster" per app server on non-privileged port (say 3000). Q1: Should Forever be used to keep the cluster alive or is that just redundant?
2. Use 1 nginx per app server running on port 80, simply reverse proxying to node on port 3000. Q2: Would node-http-proxy be more suitable for this task even though it doesn't gzip or server static files quickly?
3. Have minimum 2x servers as described above, with an independent server acting as a load balancer across these boxes. Use Pound listening 443 to terminate HTTPS and pass HTTP to Varnish which would round robin load balance across the IPs of servers above. Q3: Should nginx be used to do both instead? Q4: Should AWS or RackSpace load balancer be considered instead (the latter doesn't terminate HTTPS)

一般问题

1. 您是否看到上述（2）的需要？


2. 终止HTTPS的最佳位置在哪里？


3. 如果将来需要使用 WebSockets ，那么您会做哪些nginx替换？ li>
   

1. Do you see a need for (2) above at all?
2. Where is the best place to terminate HTTPS?
3. If WebSockets are needed in the future, what nginx substitutions would you make?

我真的很想听听人们如何设置当前的生产环境以及他们喜欢的工具组合。非常感谢。

I'd really like to hear how people are setting up current production environments and which combination of tools they prefer. Much appreciated.

推荐答案

我问了这个问题已经好几个月了，不是很多答案。 Samyak Bhuta和nponeccop都有很好的建议，但是我想讨论我在问题中找到的答案。

It's been several months since I asked this question and not a lot of answer flow. Both Samyak Bhuta and nponeccop had good suggestions, but I wanted to discuss the answers I've found to my questions.

这是我在这一点上已经解决的问题对于生产系统，但是总是在进行进一步的改进。我希望它可以帮助任何人在类似的情况下。

Here is what I've settled on at this point for a production system, but further improvements are always being made. I hope it helps anyone in a similar scenario.

1. 使用集群来生成尽可能多的子进程，在多核虚拟或物理机器上。这将绑定到单个端口，并使维护更容易。我的经验法则是n - 1个群组工作人员。您不需要永远，因为群集重新启动了工作流程死亡。即使在集群父级别也具有弹性，请确保您使用Upstart脚本（或等效的）来守护Node.js应用程序，并使用Monit（或等效的）来监视集群父级的PID并重新生成它，如果它死了。您可以尝试使用Upstart的重新启动的功能，但是我更喜欢让Monit观看东西，所以不是分担责任，我觉得最好让Monit处理重生。

1. Use Cluster to spawn as many child processes as you desire to handle incoming requests on multi-core virtual or physical machines. This binds to a single port and makes maintenance easier. My rule of thumb is n - 1 Cluster workers. You don't need Forever on this, as Cluster respawns worker processes that die. To have resiliency even at the Cluster parent level, ensure that you use an Upstart script (or equivalent) to daemonize the Node.js application, and use Monit (or equivalent) to watch the PID of the Cluster parent and respawn it if it dies. You can try using the respawn feature of Upstart, but I prefer having Monit watching things, so rather than split responsibilities, I find it's best to let Monit handle the respawn as well.

在端口80上运行的每个应用服务器使用1个nginx，只需在（1）中绑定到的任何端口上反向代理您的集群。 node-http-proxy可以使用，但nginx在服务静态文件时更加成熟，更加功能更快，速度更快。运行nginx精简（不要登录，不要gzip的小文件），以最小化它的开销。

Use 1 nginx per app server running on port 80, simply reverse proxying to your Cluster on whatever port you bound to in (1). node-http-proxy can be used, but nginx is more mature, more featureful, and faster at serving static files. Run nginx lean (don't log, don't gzip tiny files) to minimize it's overhead.

将最少2x服务器如上所述至少2个可用区域，如果在AWS中使用终止端口443上的HTTPS / SSL的ELB，并在HTTP端口80上与node.js应用服务器进行通信。 ELB是简单的，如果你愿意，让它更容易自动调整。您可以运行多个nginx，或者共享一个IP或循环，由DNS提供商自己进行平衡，但是我现在发现这个过度。在这一点上，您将删除每个应用服务器上的nginx实例。

Have minimum 2x servers as described above in a minimum of 2 availability zones, and if in AWS, use an ELB that terminates HTTPS/SSL on port 443 and communicates on HTTP port 80 to the node.js app servers. ELBs are simple and, if you desire, make it somewhat easier to auto-scale. You could run multiple nginx either sharing an IP or round-robin balanced themselves by your DNS provider, but I found this overkill for now. At that point, you'd remove the nginx instance on each app server.

我没有需要WebSockets，所以nginx继续适用，当WebSockets进入图片时，我会回顾这个问题。

I have not needed WebSockets so nginx continues to be suitable and I'll revisit this issue when WebSockets come into the picture.

欢迎回覆。

这篇关于如何使用多核，反向代理和SSL在云中部署Node.js以实现高可用性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！