RPC、IPC 还是其他？ NodeJS 中的多进程架构

Question

我正在构思一个应用程序，该应用程序使用几个较小的程序来支持它。粗略的图像是：

一个进程（可能创建几个 worker）处理 HTTP 和 WS
处理通知队列（发送电子邮件、推送等）的进程
另一个通过 JSON-RPC 或其他方式公开 API 来处理聊天的进程。

我想拆分我的进程，以便更好地分配资源，万一其中一个进程由于错误而退出，它可以由主进程恢复。然而，似乎没有任何库或框架真正做到这一点——然而，我怀疑每个人都只是创建了一个可以处理所有事情的整体进程，尤其是在 multi-core/-thread 机器上。

虽然我知道我基本上可以使用 child_process 生成子进程，将它们与 master 的 RPC 端口通信，然后使用 JSON-RPC，但我想知道是否有更多有效的方法。

有什么想法吗？提前致谢！

Answer 1

However, there does not seem to be any library or framework that really does that

它们有很多，只是它们不是 Node.JS 简单的程序。 IE。您将需要队列的一些高性能持久性，这可能会涉及另一个进程。

单独的 couplig 是有道理的，但您需要持久的消息传递架构 - 这在大型系统中是 40 年左右的完全标准。

我建议你考虑好你想运行在哪个平台，然后根据网站规则的要求进行一些研发。您的平台选择范围太窄，在这种情况下没有意义。消息传递是必须的（这样您就可以在电子邮件服务关闭时对电子邮件进行排队）。

Answer 2

这听起来很像微服务架构。而js中有构建微服务的框架如moleculer a lot of microservice implementations are language agnostic. In fact, Amazon, one of the oldest success stories of microservices, does not use a single programming language or platform for the Amazon.com website. It is a mix of multiple servers in PHP, Java, Perl and even some C++.

微服务架构的核心是HTTP反向代理前端。这可以是 Apache2 或 Nginx，也可以是更专业的东西，例如 HAProxy。当网络服务器配置为以这种方式代理微服务时，它们通常被称为 "Application Gateways".

传统上，架构是拥有前端模板渲染器（例如，一个简单的 PHP 网站），它从可以用任何语言编写的其他服务获取数据：

                                                           ┌───────────┐
                                                         .-│ Service 1 │
                         ┌─────────────┐                /  └───────────┘
┌─────────┐              │ Web Server/ │ ┌───────────┐-'   ┌───────────┐
│ Browser │-- internet --│ Load        │-│ Front-end │-----│ Service 2 │
└─────────┘              │ Balancer    │ └───────────┘-.   └───────────┘
                         └─────────────┘                \  ┌───────────┐
                HTTP                                     '-│ Service 3 │
                                  HTTP/FastCGI             └───────────┘
                                                    HTTP/RPC/REST
                                                  Kafka/RabbitMQ etc.

随着 CORS 的出现，Facebook 等服务越来越多地将大量后端服务直接暴露给网页：

                            ┌───────────────────┐
┌─────────┐              ---│ Static web server │
│ Browser │-- internet -'   └───────────────────┘ ┌───────────┐
└─────────┘            \         ┌─────────────┐  │ Service 1 │ services
                        \        │ Web Server/ │--└───────────┘ on same
React/Angular/Vue        \-------│ Load        │  ┌───────────┐ server
  front-end               \      │ Balancer    │--│ Service 2 │
                           \     └─────────────┘  └───────────┘
                            \                  HTTP
                  HTTP+CORS  \
                   (ajax)     \               ┌───────────┐ service on
                               '--------------│ Service 3 │ separate
                                              └───────────┘ server

为此，网页和服务之间的通信仅限于 HTTP 和 Websocket，因此后端服务需要是 HTTP 服务（REST/json-RPC/SOAP 等）。

服务监控和重启通常使用专门的服务监控和重启机制来完成。 node.js 一个流行的崩溃检测和重启软件是 PM2 or forever however there are other generic software for this such as monit。事实上，并不要求所有服务都使用相同的重启系统（例如亚马逊允许每个功能由不同的团队开发并在团队认为合适的情况下部署）。

如果您仔细设计您的会话系统（粘性会话、JWT 令牌等），您可以通过简单地运行安装更多服务器来扩展您的后端。例如，如果聊天占用大量资源，只需运行 3 或 4 个聊天服务器，而运行仅使用一台前端服务器。

RPC、IPC 还是其他？ NodeJS 中的多进程架构

RPC, IPC or something else? A multi-process architecture in NodeJS

node.js

ipc

rpc