Микросервисная архитектура в nodejs?

Приветствую. Решил переписать старое монолитное приложение на ноде на приложение, использующее микросервисную архитектуру. Но опыта в построении подобных у меня, к сожалению, нет. В и-нете полно информации о микросеврисах (статья Мартина Фаулера), но вот применимо к ноде, увы, нет ничего. На последней встрече nodejs программистов в Киеве этот вопрос поднимался, но в двух словах. Может ли кто-то поделится опытом, может полезные ссылки/статьи и очень буду благодарен примерам. Спасибо
  • Вопрос задан
  • 5054 просмотра
Решения вопроса 1
MarcusAurelius
@MarcusAurelius Куратор тега Node.js
автор Impress Application Server для Node.js
Я бы не противопоставлял монолитные приложения и микросервисы. На самом деле чем лучше приложение разделено на части, тем лучше оно централизовано. Приведу сначала пример житейский, если каждый сотрудник автономно выполняет порученную ему работу хорошо и качественно, то сокращается взаимодействие между сотрудниками, уменьшаются расходы времени на контроль и переделывание работы, при этом монолитность иерархических структур упрочняется чем более автономен каждый сотрудник в организации. Что же противопоставить, что же плохо? Плохо - смешивать уровни абстракции, в ноде распространено смешивать все в кучу, я приводил пример тут: habrahabr.ru/post/247543 цитирую:
Прикладной код часто смешан с системным. Дело в том, что нода, и большинство производных фреймворков, слишком низкоуровневые и каждое приложение обязательно содержит часть системного кода, не относящегося к задачам предметной области. Вот и случается, например, что добавление HTTP заголовка становится методом класса Patient и находится в одном файле с заданием роутинга URLов к сему пациенту и с отправкой событий через веб-сокеты. Это чудовищно.

Монолит - это не плохо. Плохо, когда смешаны слои абстракции, если это не понимать, то микросервисы ничего не дадут. Это приводит к высокой связанности кода, когда каждый фрагмент зависит от множества других. Внутри каждого микросервиса можно сделать полное месиво абстракций. Лучше планировать архитектуру слоями, ниже - слои системные, выше - прикладные. Иногда их нужно 2, иногда 3, иногда больше. В каждом модуле, конечно у вас будут как минимум: внешний интерфейс (содержащий внешние вызовы и спецификации форматов данных для обмена), внутренняя логика и внутренние структуры данных. Задача архитектора сделать так, чтобы интерфейс модуля экранировал внутренние структуры данных и внутреннюю логику от зависимостей. При этом, делить приложение на сотни процессов не обязательно, даже внутри одного процесса вы можете связать компоненты по принципу микросервисов, посадив их на шину событий, это будет называться модель акторов.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
ну.... пишите кучу сервисов - сервер авторизации, еще какие-нибудь штуки... разделяйте все на функциональные модули, связывайте все вместе шиной данных на zeromq например и профит.
Ответ написан
dizballanze
@dizballanze
Software developer at Yandex
Как по мне, то микросервисная архитектура – самый правильный подход для серьезной разработки на Node.js. Поддерживать монолитное приложение на Node.js тот еще ад, а так проще находить ошибки, проще масштабировать приложение, поддерживать его.
В плане реализации тут все достаточно просто, разделяете ваше приложение на структурные части и реализовываете, как отдельные микросервисы (сюрприз!!), которые общаются через что-то вроде Rabbitmq.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы