Как правильно разделять приложение node js на микросервисы?

Question

[komarevtsev]

Как правильно разделять приложение node js на микросервисы?
Использую express 4
Есть ли смысл выносить например чат или же любую другую часть, логика которой отличается от основного приложения - в отдельное нодовское приложение?
Как в таком случае осуществлять общение между приложениями (http запросами сейчас у меня реализовано)

Answer 1

[Владимир Грабко]

Ну вообще обычно есть "точка входа" которая имеет публичный Api и занята она проксирование запросов к микросервисам.

По поводу протокола.
Я юзаю Go и думаю что тоже подойдёт к любому ЯП.

У меня между микросервисами сделано подобие json RPC по верх TCP и UNIX SOCKET. Второе сделано на случей если микросервисы на том же сервере и каждый микросервис слушает как tcp так и unix socket.

Обычно каждый модуль выносят в микросервис (а-ля Авторизация, Чат, Отправка EMAIL и т.д.)

Answer 2

[Dmitry]

Попробуйте почитать тут:
Очень годное руководство по микросервисам: https://www.nginx.com/blog/introduction-to-microse...
node.js: codewinds.com/blog/2015-11-14-microservices-nodeve... (https://github.com/jeffbski/microservices)

Answer 3

[Antoxa Zimm]

Думаю, что node.js вполне может использовать общие принципы микросервисной архитектуры, реализация зависит от фантазии и опыта.
По опыту проекта социальнй сети на микросервисах и шины сообщений:
Небольшой кусочек логики выносится в несколько микросервисов, для этого куска логики обычно легко создать схему в БД(обычно 1-4 таблицы) и запретить другим сервисам доступ к этой схеме. Если сервис (или несколько) написан правильно, то он легко может быть перенесен с одно сайта на другой без лишних проблем с интегрцией.
Сервисы можно разделить на разные типы:

• "CRUD микросервис" с бизнес логикой и работающий с БД, может запросить данные у других микросервисов (например баланс счета пользователя или разрешение на выполнение какой-то операции), может отправить инфурмацию о сделанной работе (например сохранил сообщение чата в БД -- отправь инфу, что сообщение сохранение)
  
• "Маршрутизаторы сообщений" читают из очереди сообщения, иногда запрашивают данные у других микросервисов, переписывают/дописывают сообщения и пересылают по другим адресам или блокируют отправку сообщений далее (например пользователя можно информировать отправкой письма или push нотификацией т.к. пользователь пользуется только приложением)
  
• "Таймеры" получают сообщение из очереди, на основании конфигурации создают таймер и потом пересылают сообщение по другому адресу (например у пользователя подписка на месяц и через 3 недели нужно информировать его о завершении)
  

Для общений микросервисы могут использовать RabbitMQ с какой-то обверткой поверх него.

Comments

[komarevtsev]

я сейчас реализовал общение через redis pub/sub. Насколько это приемлимо?

[littleguga]

А почему RabbitMQ, а через redis или например, сокеты - не рекомендуется?

[Yeah]

А как насчет целостности? При монолите можем использовать foreign keys. А как с этим в случае микросервисов?

[Сергей Рогожкин]

Вы описали распределенный монолит, который при отладке съест мозг.

[Antoxa Zimm]

komarevtsev: я не работал с redis pub/sub, вполне может быть, что это хорошая альтернатива RabbitMQ. В микросервисе я пользовался только только несколькими функциями: [1] получить сообщение из очереди и обработать его; [2] отправить сообщение сообщение в очередь на обработку, важно, что для некоторых сообщений требовалось получить ответ о том, что оно обработалось удачно/неудачно в другом микросервисе (это в rabbitmq реализованно из коробки и очень удобно), цепочка взаиможействия микровервисов может быть просто огромной (что сильно затрудняло работу на первых этапах)

[Antoxa Zimm]

littleguga: Я затрудняюсь ответить т.к. я пришел на проект которому уже было более 3х лет. Точнее там было больше 5 проектов, написанных на микросервисах и они шарили между собой некоторые из микросервисов. Проекты иногда закрывали, иногда открывали новые. Что мне кажется важно в отношении новых проектов: просто рисовали новый UI и создавали новый проект в CI, накидывали в него список микросервисов из уже имеющихся и за месяц!!! работы был готов новый проект с понятным всем разработчиком функционалом и стеком технологий)))

RabbitMQ добольно распространен и его часто используют, новые проекты на нем пишут, думаю он подходит для определенных задач. Из личного опыта могу сказать, что с ним удобно работать, у него есть хорошая админка, он понятен и удобен. У RabbitMQ сообщения из очереди могут быть записаны на диск, например если какой-то микросервис не работает несколько часов, то сообщения в очереди будут накапливаться и могут быть обработаны через час или два после отправки, что довольно удобно в некоторых ситуациях.

[Antoxa Zimm]

Yeah: В рамках схемы foreign keys/primary keys без проблем, они есть и работают хорошо. В рамках нескольких схем foreign keys/primary keys не работали (и они не требоались в принципе).

Проектирование БД позволяло не завязиваться на другие схемы, если правильно выбраны сущности и взаиможействие между ними в рамках одной схемы, то все будет ок. Было такое правило, что взаиможействие между схемами БД запрещено в принципе и каралось.
Проблема с UserId -- часто был такой столбец в таблицах в других схемах (другие столбцы реже), который не имел связи с таблицей Users, но проблем с отсутствием foreign keys не было. Проблем с целостностью данных тоже не замечал (они вероятно были, но социальная сеть, не банковское приложение или запуск ракет, все зависит от того, что вам требуется и что Вы можете себе позволить, а что нет).

[Antoxa Zimm]

Сергей Рогожкин: Почему Вы так думаете? Я более чем уверен, что у нас были реплики некоторых микросервисов, семантическое версионирование микросервисов, балансировка нагрузки на микросервисы, пачка процессов и т.д.

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

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

[komarevtsev]

Antoxa Zimm: Да, вот callback-ов у механизма pub/sub нет, с этой проблемой столкнулся когда реализовывал проект. Но это нужно было всего лишь в одном месте, поэтому написал костыль.

[komarevtsev]

Думаю, что pub/sub redis стоит использовать, только если у вас на проекте уже стоит redis для других задач, и чтобы не подключать лишнюю либу - юзать redis.

Answer 4

[Ivan Zmerzlyi]

Свое время тоже задумался вопросом организации проектов. Для нескольких личных, и пары проектов на заказ начал организовывать структуру на основе модулей высокого уровня.

По требованиям, что стояли предо мной, мне нужно было создать проекты в которых есть админка SPA (Single page application), есть API, и есть публичная часть (front, морда) которая для одного проекта может быть SPA, для другого чисто монолит с рендерингом вьюшек.

В итоге получилось такая вот основа - https://github.com/DangelZM/simplicitjs Сейчас нет времени как то дорабатывать. Но мне для старта небольших проектов с админками пригодилось.

Comments

[wided]

Ссылка мертва.

[Ivan Zmerzlyi]

Поправил