Взаимодействие микросервисов между собой
Следующий возникающий в голове вопрос, когда разобрался с тем, как работать с данными в данной архитектуре (а может у кого то этот вопрос стоит первым) — как микросервисы будут взаимодействовать между собой?
Основные подходы к взаимодействию микросервисов
Синхронное взаимодействие
Разберем несколько преимуществ:
В синхронном подходе взаимодействия есть несколько интересных преимуществ, такие как простота. Подобного рода запросы в виде HTTP легко понять и использовать, так как это по сути своей стандартная клиент-серверная модель.
В синхронных системах проще реализовать транзакции на уровне взаимодействия между сервисами, так как операции выполняются последовательно и сразу же возвращают ответ.
В системах с минимальными требованиями к производительности и низкой задержкой синхронный подход эффективен, так как позволяет сразу получать результаты.
За имением выше описанных плюсов, мы так же имеем следующие минусы
Взаимодействие становится уязвимым к временной недоступности сервисов. Если один микросервис не отвечает, это может заблокировать всю цепочку вызовов. (Далее будет пример решающий данную проблему)
Каждый запрос в синхронном взаимодействии требует сетевого запроса и ожидания ответа, что может вызвать высокие задержки, особенно если взаимодействие происходит через интернет или в распределенных системах с большой латентностью (В сетевых технологиях латентность — задержка или ожидание, которая увеличивает реальное время отклика по сравнению с ожидаемым).
Синхронные вызовы блокируют поток до получения ответа, что делает их менее эффективными при высоких нагрузках. Невозможность параллельной обработки запросов увеличивает нагрузку на ресурсы.
В случае сбоя одного из микросервисов система может зависнуть, так как синхронное взаимодействие предполагает ожидание завершения запроса
Способы взаимодействия:
Асинхронное взаимодействие
Преимущества:
Асинхронное взаимодействие позволяет микросервисам обрабатывать запросы и события независимо от скорости отклика других сервисов. Это уменьшает блокировки (Собственно, это и решает проблему с уязвимостью к временной недоступности сервисов) и позволяет системе справляться с большими нагрузками.
Это прямым образом влияет на производительность в случае если у вас большая система.
Уменьшение связности между микросервисами. В подобном случае, микросервисы не зависят напрямую от немедленного ответа друг друга.
Использование брокеров сообщений или событийной модели позволяет системам легко работать с потоками данных в реальном времени, такими как обработка событий IoT, логирование и аналитика.
Если один из сервисов временно недоступен, система продолжает работать, поскольку запросы могут накапливаться в очереди сообщений и обрабатываться, когда сервис снова станет доступен.
Собственно, реализовать это самое взаимодействие можно следующими инструментами
Сообщение через брокеры сообщений (Kafka, RabbitMQ, NATS, NSQ, и др.).
Event-driven подход. (Событийно ориентированный подход)
Возможные сложности:
Асинхронные системы сложнее разрабатывать и поддерживать, так как необходимо учитывать порядок сообщений, повторные обработки и согласованность данных. Но чаще, подобные проблемы решать приходиться на старте проекта, чем на уже сформированном понимание и видение проекта.
Отладка и трассировка становятся сложнее, так как запросы могут проходить через несколько сервисов с задержкой, и их порядок обработки может варьироваться.
Требуется дополнительная логика для обработки потерь сообщений, дублирования и их последовательности. Необходимо внедрять механизмы подтверждения получения и обработки сообщений, такие как транзакции, ретраи и компенсационные действия.
Использование брокеров сообщений или событийных систем требует дополнительной инфраструктуры и управления, что может увеличивать сложность обслуживания и стоимость системы.
Вызовы и сложности в межмикросервисном взаимодействии
Сетевые задержки и отказоустойчивость
Как обрабатывать сетевые сбои и недоступность сервисов?
Таймауты / Повторы
Circuit Breaker (Паттерн Предохранитель)
Как и проговорил ранее — асинхронное взаимодействие
Дублирование и репликация сервисов для повышения доступности
Мониторинг и алерты
Темпоральное распределение нагрузки (Распределение запросов по временным интервалам (rate limiting) поможет снизить нагрузку на сервисы, что уменьшает вероятность сбоя)
Грейсфул дегредейшен
Реализация режима деградации, для того, что бы ваши сервисы могли продолжать работу с ограниченной функциональностью в случае сбоя одной из частей системы.
Транзакционность
Как обеспечить консистентность данных (SAGA паттерн)?
За поиском ответа на данный вопрос, ссылаю тебя читатель на данную статью — Паттерн «сага» как способ обеспечения консистентности
Безопасность
Как защитить межмикросервисное взаимодействие (аутентификация, авторизация, шифрование данных).
Не буду тут расписывать как реализовывать разные виды авторизации/аутентификации пользователей, важный вопрос в контексте микросервисов, это как реализовать эту самую проверку авторизации пользователей в системе?
На этот вопрос есть в качестве ответа 2 замечательные статьи на хабре
Мониторинг и трассировка
Какие инструменты для реализации мониторинга можно использовать?
Prometheus — система мониторинга и алертинга, ориентированная на time-series данные. Он идеально подходит для микросервисов благодаря своей способности собирать метрики из контейнеров и поддерживать запросы через язык запросов PromQL.
Grafana — мощный инструмент для визуализации метрик.
ELK Stack (Elasticsearch, Logstash, Kibana) — позволяет собирать, хранить и анализировать логи микросервисов. Logstash используется для сбора и обработки логов, Elasticsearch для хранения и поиска, а Kibana для визуализации данных, что упрощает анализ событий и метрик.
Jaeger, Zipkin — система трассировки, которая помогает отслеживать запросы в распределенных системах.
OpenTelemety — это набор инструментов и API, который позволяет собирать, обрабатывать и экспортировать данные о метриках, трассировках и логах. Он поддерживает интеграцию с различными инструментами мониторинга и трассировки, что делает его универсальным решением.
Datadog, New Relic — облачный сервис для мониторинга и аналитики.
Паттерны взаимодействия микросервисов
API Gateway
Централизация запросов через единую точку доступа.
Зачем?
По своей сути, корневой компонент вашей распределенной системы, способствующих эффективному взаимодействию между различными сервисами.
Вот основные причины, почему API Gateway необходим:
Централизованный входной пункт и Управление маршрутизацией — служит единой точкой доступа для всех клиентских запросов и отвечает за маршрутизацию запросов к соответствующим микросервисам.
Аутентификация и авторизация — может выполнять функции контроля доступа, обеспечивая безопасность микросервисов. Преимущество такого подхода в том что он позволяет избежать дублирования кода аутентификации в каждом сервисе.
Лимитирование нагрузки и защита от DoS-атак — может управлять нагрузкой, вводя лимиты на количество запросов от клиента.
Консолидация ответов — может агрегировать данные из нескольких микросервисов и возвращать их клиенту в одном ответе.
Версионность — можно управлять версиями API, что упрощает обновление микросервисов и взаимодействие с клиентами, которые могут использовать разные версии приложения.
Service Mesh
Контроль трафика между микросервисами.
Подробнее почитать об этом паттерне можно тут — Сценарии использования service mesh
Материалы для изучения
Микросервисы
RabbitMQ
Apache Kafka
