Соединение между несколькими приложениями node.js

Question

Я хотел бы знать, как лучше всего подключить несколько приложений node.js, которые все работают как http-серверы.

Например: у меня есть приложение express node.js под названием MasterApp. Это должно обрабатывать аутентификацию, учетные записи пользователей, целевую страницу и т. Д. Но я также хотел бы иметь другие приложения, которые выполняют определенную область веб-сайта, например, вики и чат-комнату.

Так что мой набор может выглядеть примерно так:

          Web
           ^
           |
        MasterApp
         ^     ^
         |     |
ServiceApp1   ServiceApp2...   

Одним из возможных решений было бы превратить небольшие приложения в модули и включить их в MasterApp, но у меня есть причины этого не делать. Во-первых, я хочу поддерживать время безотказной работы MasterApp, в то время как ServiceApp1 и ServiceApp2, в экспериментальной и / или в разработке.

Другим решением, которое кажется разумным, было бы создать прокси в MasterApp с node-http-proxy , который перенаправляет запросы после уровня аутентификации на ServiceApp1, ServiceApp2 ... Это рекомендуемое решение? Или это опрометчиво?

Или это другое решение, которое мне не хватает. Или я на правильном пути, чтобы использовать прокси-сервер, но, возможно, вместо него следует использовать HAProxy, оставив прокси-сервер внешним по отношению к узлу (хотя мне нравится идея динамической настройки узла-http-прокси).

Спасибо

Answer 1

Предполагая, что ваше приложение использует AJAX на стороне клиента для доступа к вашему серверу, проще всего будет запустить какой-нибудь прокси. Вы можете настроить его так, чтобы сначала использовать node-http-proxy, а затем поместить прокси nginx вперед, если обнаружите, что node-http-proxy слишком медленный.

Запуск других модулей в памяти, конечно, будет выполняться быстрее всего, но, как вы указали, это означает, что основной процесс будет зависеть от ошибок в другом.

То, о чем вы говорите, похоже на сервис-ориентированную архитектуру, которая становится популярной благодаря своей модульности с точки зрения эксплуатации. Разбивая приложение на отдельные службы, каждая из которых имеет свою собственную базу данных, HTTP-сервер и т. Д., Вы можете независимо обновлять, масштабировать, управлять и отслеживать компоненты, что может быть полезным. Это приводит к снижению производительности (особенно к задержке) и использует больше ресурсов, но имеет определенную надежность. Читать подробнее: http://en.wikipedia.org/wiki/Service-oriented_architecture

С сервис-ориентированной архитектурой вам действительно нужно выяснить, как справиться с некоторыми основными проблемами, такими как авторизация и аутентификация. Иногда у вас есть прокси-сервер перед всеми службами, который действует как привратник и проверяет учетные данные пользователя перед передачей запросов в соответствующую службу, либо сами службы могут проверять учетные данные, передавая их другой серверной службе или используя общий кусок кода (обычно что-то, связанное с HMAC).

Answer 2

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