Данная статья является продолжением первой
части.
Архитектура с брокером
Что на изображении: В этой архитектуре все общение между
микросервисами происходит через посредников - группу брокеров. Брокеры - это серверные
программы, использующие некоторые собственные алгоритмы маршрутизации.
Каждый микросервис подключается к брокеру. Все сервисы могут получать и
отправлять сообщения через одно соединение. Микросервис, отправляющий сообщения, называется
издателем, а получатель - подписчиком. Сообщения
публикуются со специальной "темой". Подписчик получает сообщения, на которые он подписан.
Плюсы:
- Балансировка нагрузки: большинство брокеров поддерживают балансировку нагрузки из
коробки. Это делает общую архитектуру более простой и легко масштабируемой. Некоторые
брокеры (например, RabbitMQ) имеют встроенные повторы и многое другое для повышения
надежности канала связи.
- Безопасность данных: Конкретные сервисы не доступны пользователям при использовании
серверной части обмена сообщениями. Все микросервисы выступают в роли клиентов.
Единственный сервис, который может быть обнаружен, - это брокер сообщений.
- Fan In и Fan Out: серверная часть обмена сообщениями облегчает распределение рабочей
нагрузки и агрегирование результатов. Самое приятное то, что добавление рабочих
микросервисов может быть выполнено прозрачно без необходимости обновления других
микросервисов.
- Потоковое проектирование: Такой подход также порождает концепцию потоков. Каждая тема
по сути является потоком сообщений. Любой подписчик может подключиться к этим потокам по
мере необходимости. Возможности моделирования системного дизайна с использованием
потоков безграничны.
Минусы:
- Масштабирование брокеров. Несмотря на то, что преимущества поразительны,
масштабирование самих брокеров становится проблемой для сильно распределенных систем.
Это просто еще одна вещь, которую нужно поддерживать вместе с вашими микросервисами.
- Более высокая задержка: количество прыжков в шине сообщений увеличивает общую задержку.
Это особенно верно для случая использования, подобного RPC. В критически важных
приложениях это может быть непреодалимым препядствием.
- Более высокое расходование ресурсов. Для работы брокерам необходимы ресурсы CPU, памяти
и хранилища. Эти ресурсы могли бы быть использованы для запуска других микросервисов.
Накладные расходы, связанные с архитектурой брокера, могут быть нерентабельными для
небольшого кластера.
Недостаточно просто знать преимущества и недостатки различных архитектур. Важно
понимать, что выбор архитектуры сильно зависит от задачи, которую ставит перед собой
приложение.
Вы всегда должны по умолчанию использовать архитектуру без брокера. Сделайте
переключение, если вам нужна гибкость потоков или вам нужно использовать семантику pub-sub
шины сообщений. Если вы начинаете с нуля, имеет смысл начать с дизайна без брокера, а затем
переключиться, когда появится такая необходимость.
Нет необходимости выбирать конкретную архитектуру для приложения. Вы можете
использовать обе. Для нашего инструмента мы используем архитектуру брокера для реализации
вызовов RPC. Связь с нашим уровнем базы данных осуществляется без брокера, чтобы обеспечить
более низкие задержки.
Заключение
Использование правильного подхода к построению микросервисов важно. Выбор
способа общения является фундаментальным решением, которое необходимо принимать с большой
осторожностью.
Есть разные варианты реализаций для обоих подходов к архитектуре. Придерживаться
устоявшейся основы почти всегда имеет больше смысла, чем создавать что-то с нуля. Чаще всего
есть вариант решения без смены парадигмы. Для брокеров сообщений у вас есть RabbitMQ, Nats,
Kafka и т.д., И каждый из них создан для определенной семантики обмена сообщениями.
Еще один замечательный способ - использовать Backend как сервис, такой как
Space Cloud, например. Space Cloud автоматизирует весь бэкэнд, поэтому вы сможете
сосредоточиться на бизнес-логике, а не на облачной архитектуре.
Помогла ли вам эта статья? Как сделать так, чтобы ваши приложения были
облачными? Поделитесь своим опытом в комментариях.