nginx/node.js/postgres 是一个非常可扩展的架构吗？
我有一个应用程序正在运行：
- 一个 nginx 实例作为前端（提供静态文件）
- 一个 Node.js 应用程序集群作为后端（使用集群和expressjs 模块）
- 一个 Postgres 实例作为数据库
如果应用程序是这样的话，这种架构是否足够需要可扩展性（仅适用于 HTTP / REST 请求）：
每秒 500 个请求（每个请求仅从数据库获取数据，这些数据可能是几个 ko，并且获取后不需要大量计算）。< /p>
20000个用户同时连接
瓶颈在哪里？
I have an app running with:
- one instance of nginx as the frontend (serving static file)
- a cluster of node.js application for the backend (using cluster and expressjs modules)
- one instance of Postgres as the DB
Is this architecture sufficient if the application needs scalability (this is only for HTTP / REST requests) for:
500 request per seconds (each requests only fetches data from the DB, those data could be several ko, and with no big computation needed after the fetch).
20000 users connected at the same time
Where could be the bottlenecks ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于指定的负载（每秒 500 个简单请求），我不会认为这会是一个太大的问题。我的猜测是，甚至不需要节点实例集群。
但是，由于您只有一个实例，因此在扩展时，这很可能成为您的瓶颈。您还遇到了额外的问题，这将是您的单点故障（我不熟悉 Postgres，这里正在使用 Oracle 集群和 dataguard，这意味着我们有一个备份数据库集群来缓解这一问题） 。
如果您不需要关系数据模型，那么 MongoDB 可能是一个更具可扩展性的选择。
另一件需要记住的事情是您的网络基础设施。如果要添加集群/节点，请确保网络可以处理分布式负载。
最后一件事：通常，如果没有性能/容量/压力测试，就不可能确定架构上的应用程序是否可以处理特定负载，因此答案是响亮的“也许”。
For the specified load (500 simple requests/second), I wouldn't have thought that this will be too much of a problem. And my guess would be that a cluster of node instances will not even be necessary.
However, as you've only got a single instance, when it comes to scaling up, that is most likely going to be your bottleneck. You've also got the additional issue that this would be your single point of failure (I'm not familiar with Postgres, here were working with an Oracle cluster and dataguard which means that we've got a backup database cluster to mitigate that).
If you do not require a relational data model, then something MongoDB may be a more scalable choice.
One other thing to bear in mind is your network infrastructure. If you are going to add clusters/nodes, then make sure that the network can handle the distributed load.
One last thing: Generally, it is impossible to determine whether an application on an architecture can handle a particular load without performance/volume/stress testing, so the answer is a resounding "maybe".
每秒 500 次操作应该没问题。如果您希望达到每秒千次操作，请重新设计。
如果不了解您的更多数据，磁盘 I/O 很可能会成为您的瓶颈。如果您从普通硬件上的硬盘驱动器进行 I/O，则这种情况会在 PostgreSQL 数据库中以大约 10k 操作/秒的速度发生，如果您在 SQL 命令上执行 JOIN，也会减慢速度。这也会减慢您尝试访问单个驱动器的更多并发用户的速度。你的驱动器寻道时间将会很糟糕，因为你会不断地随机访问驱动器。
您应该研究数据的结构以及是否需要关系数据库（是否必须进行 JOIN？）。 noSQL 解决方案可能是最佳选择。始终尝试使磁盘 I/O 尽可能分布式和连续。
You should be ok at 500 ops/sec. Redesign if you expect to go into the thousand ops/sec.
Without knowing a lot more data from you, disk I/O will be your bottleneck most likely. This will occur in your PostgreSQL database at around 10k ops/sec if you're I/O'ing from the hard drive on stock hardware and also slow down if you're doing a JOIN on the SQL command. This will also slow down the more concurrent users you have trying to access a single drive. Your drive seek time is going to freak out, as you'll constantly be randomly accessing the drive.
You should research the structure of your data and if a relational database is needed (do you have to do a JOIN?). A noSQL solution might be the way to go. Always try to get your disk I/O as distributed and sequential as possible.