Вытаскивание сервиса из модульного монолита

Не существует единственно правильного способа сделать это

Я видел два основных подхода, причем второй подход имел дополнительный необязательный компонент.

1. Используйте центральную шину событий, как вы упомянули. Это легко реализовать, и каждый сервис знает, где публиковать сообщения, и они знают, откуда приходят все сообщения. Недостатком является то, что ваша архитектура микросервисов теперь имеет единую точку отказа. Если шина сообщений выйдет из строя, вся экосистема рухнет в одно мгновение.

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

2. Каждая микрослужба получает свою собственную очередь сообщений. Это децентрализует обработку сообщений. Сбой в одной очереди сообщений не приведет к краху всей системы. Недостатком является то, что теперь каждой службе необходимо знать имена хостов и порты для всех очередей сообщений, которые им нужны. Это увеличивает сложность при добавлении новых услуг или закрытии старых.

   1. Этот вариант № 2 включает концепцию, называемую обнаружением службы. Это помогает решить проблемы с развертыванием новых сервисов и отключением старых. Каждый сервис регистрирует себя при подключении к сети. Но теперь мы вводим еще одну единую точку отказа. Если агент обнаружения служб не работает, новые службы или узлы не могут зарегистрироваться. Обнаружение службы решает одни проблемы, но создает другие.

Шлюз API на самом деле не решает проблемы с архитектурой обмена сообщениями. Даже если все службы совершают вызовы через шлюз API, шлюз API должен решить, в какие очереди сообщений перенаправлять вызовы. Кроме того, шлюз API создает еще одну единую точку отказа. Обычно шлюз API используется для централизации аутентификации и ограничения скорости. Опять же, это решает некоторые проблемы, но добавляет еще несколько.

Какой подход вы выберете, сильно зависит от потребностей вашей системы. Вы должны взвесить преимущества и недостатки каждого подхода и сделать собственное суждение. Не забудьте сохранить микросервисы:

• Независимо развертываемый
• Независимо масштабируемый

Делайте это превыше всего.

Рекомендую посмотреть эти видео для лучшего погружения в вопрос:

Прикрепленное видео 1 - Модульные монолиты и DDD, Бесплатный вебинар OTUS

Прикрепленное видео 2 - Владимир Лобода "Как разделить монолит на части и выжить после этого"