RP C, IP C или что-то еще? Многопроцессная архитектура в NodeJS

Question

Я работаю над созданием приложения, которое использует несколько небольших программ для его поддержки. Грубое изображение:

• Один процесс (который может создать несколько рабочих) обрабатывает HTTP и WS
• Процесс обработки очереди уведомлений (отправка электронных писем, pu sh, et c.)
• Еще один процесс обработки чата путем предоставления API через JSON -RP C или что-то еще.

Я хочу разделить свой процессы, так что ресурсы распределяются лучше, и в случае сбоя одного из процессов из-за ошибки он может быть восстановлен главным процессом. Тем не менее, похоже, что не существует какой-либо библиотеки или инфраструктуры, которая действительно это делает - и все же я сомневаюсь, что каждый просто создает один монолитный c процесс, который обрабатывает абсолютно все, особенно на многоядерных / многопоточных машинах.

Хотя я знаю, что могу в основном использовать child_process для порождения подпроцессов, сообщать им порт RP C мастера и затем использовать JSON -RP C, я подумал, есть ли еще эффективный подход к этому.

Есть идеи? Заранее спасибо!

Answer 1

Это очень похоже на микросервисную архитектуру. Несмотря на то, что в js есть фреймворки для создания микросервисов, такие как молекулярный , многие реализации микросервисов не зависят от языка c. Фактически, Amazon, одна из старейших историй успеха микросервисов, не использует ни одного языка программирования или платформы для веб-сайта Amazon.com. Это сочетание нескольких серверов в PHP, Java, Perl и даже некоторых C ++ .

Ядром архитектуры микросервиса является интерфейс обратного прокси-сервера HTTP , Это может быть Apache2 или Nginx или что-то более специализированное, например HAProxy . Когда веб-сервер настроен для прокси-микросервисов таким образом, их часто называют «шлюзами приложений».

Традиционно архитектура состоит в том, чтобы иметь интерфейсные средства визуализации шаблонов (например, простой веб-сайт 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 et c.).

Мониторинг и перезапуск службы обычно выполняются с использованием специального механизма мониторинга и перезапуска службы. Для node.js популярным программным обеспечением для обнаружения и перезапуска cra sh является PM2 или forever , однако для этого есть другое универсальное программное обеспечение c, например monit . Фактически, не требуется, чтобы все службы использовали одну и ту же систему перезапуска (например, Amazon позволяет каждой функции разрабатываться другой группой и развертывать ее по своему усмотрению).

Если вы тщательно проектируете свой Система сессий (sticky session, токен JWT и c) позволяет масштабировать свой бэкэнд, просто запустив больше серверов. Например, если чат занимает много ресурсов, просто запустите 3 или 4 сервера чата, в то время как работает только один интерфейсный сервер.

Answer 2

Однако, похоже, не существует какой-либо библиотеки или фреймворка, которые бы на самом деле это делали

Их множество, но они не просто Node.JS простые программы. Т.е. вам понадобится некоторое постоянство высокой производительности для очередей, что, вероятно, потребует другого процесса.

Раздельное связывание имеет смысл, но вам нужна постоянная архитектура передачи сообщений - это похоже на стандарт в течение примерно 40 лет или около того. более крупные системы.

Я предлагаю вам подумать, на какой платформе вы хотите работать, а затем провести некоторые исследования и разработки, как того требуют правила сайта. Ваш выбор платформы просто слишком узок, чтобы иметь смысл в этом сценарии. Передача сообщений является обязательной (то есть вы можете ставить электронную почту в очередь, когда служба электронной почты не работает).