如何扩展Node.js支持大量用户
如何根据用户量逐步扩展Web应用的性能？过早扩展造成的痛苦反而超过其受益，本指南提供如何从简单开始，随着用户量增长进行扩展的方式。
1.本地一个并发用户
不需要扩展
2.单个服务器，2-9个并发用户
NodeJS是一个事件驱动和非阻塞I / O模型。这意味着它不会堵塞某个单一的请求，而是同时处理所有的请求，从数据库或服务的响应数据则放在一个回调函数/promise函数中。Node应用程序在等待数据库或文件系统来响应的大部分时间内，它可以同时处理多个请求。
你的应用目前是单片整体monolith，不需要复杂化，当然每次修改需要重启应用。建议使用亚马逊AWS t2.micro/t2.nano或同等类型：1 CPU/ 1 GB RAM。
3.垂直扩展，10-99并发用户
请求处理可能会开始需要更长的时间，响应开始变得越来越慢。你需要一个更大的盒子！这就是所谓的垂直缩放。纵向扩展意味着需要更多的资源，更高/更快的CPU，内存，硬盘，HDD I/O
如果使用亚马逊，建议升级 t2.medium，2CPU/4 GB RAM.
具有多个处理器内核的额外好处是。我们可以使用Nginx作为负载平衡运行两个Nodejs实例。多个实例意味着你可以实现零停机时间进行应用的部署/更新。您可以升级一个服务器，而另一个则继续正常服务。
4.横向扩展，100-999并发用户
这时瓶颈是I/O，数据库花很长时间响应，需要升级m4.xlarge 或(4 CPU / 16 GB RAM). 4个CPU意味着你有多个数据库或应用的实例，这称为横向扩展。
4个CPU是在一台服务器还是4个单CPU服务器呢？这时前者垂直扩展已经不再经济，还有其他问题：将所有的鸡蛋都放在一个篮子里。如果服务器当机，你就完蛋了！另一方面，水平缩放带给你冗余和故障转移。
这时最好采用横向扩展，瓶颈大部分在数据库：
1.将数据库迁移到不同的服务器上，独立地进行缩放。
2.如果数据库达到访问极限，使用备份，注意使用数据库缓存。
由于Node是非常有效率的，它会花费大部分的时间等待数据库返回数据。因此，主要的限制将取决于网络限制。修改/etc/security/limits.d 和 /etc/sysctl.conf，请求队列最大数量取决于net.core.somaxconn，其默认值是128, 改变到1024，这样就能应付100-999范围的并发用户。
5.多服务器，1000以上并发用户
基于之前架构提升如下:
a.增加负载平衡，增加应用单元
b.在不同地区使用多可用区
c.将静态文件划分到不同服务器，增加CDN。
6.微服务，10万以上并发用户
到目前为止，我们一直在利用垂直和水平缩放，我们已经将Web应用从数据库服务器实例中分离出来，并部署到多个区域。然而，我们一直是基于单个一套代码为基础处理所有的工作。我们x现在可以把它分解成更小的碎片，并根据需要独立扩展它们。从单片整体架构到微服务架构。
是时候把我们整体的Web应用程序分解成多个较小的独立组件（微服务/ SOA）。我们不必一下子就把一切都打破了。我们可以让原来的单片整体系统继续做它的工作，我们开始编写小的客户端应用程序替代来一些原来主要应用执行的任务。
7.自动化运维，百万以上并发用户
尽可能自动化。基础设施越来越肥。我们需要数据库副本和分片，水平缩放、多地区、多AZ，自动缩放。
高可用都地区:基于流量源扩展可用区域。
自动扩展：如果你总是根据峰值容量分配服务器数量是很多浪费。用户流量有峰值（如黑色星期五）和山谷（例如，早上4点）。就是说，最好是建立一个自动缩放选项，允许网络根据流量自动调整。有多个策略自动缩放如基于CPU利用率、延迟或基于网络流量进行不同扩展。
度量:你也需要度量，监测和集中记录。测量可以测量的一切。服务器节点失败可能开始是随机的，你不能登录/ SSH到每一个服务器去寻找和确定的原因。集中日志使用ELK栈技术 (Elasticsearch, Logstash, 和 Kibana). 监视使用DataDog。
定制：数据库可能仍然是扩展中一个头痛的问题。如果熟悉了你的业务用例情况，可以使用NoSQL解决方案。