Идея микросервисной архитектуры состоит в том, чтобы разбить большое приложение на логические компоненты, чтобы эти компоненты стали отдельными сервисами.
По сути микросервис - это небольшой компонент, который можно развернуть независимо и который помогает реализовать определенную функциональность для более крупного приложения. Он будет иметь свои собственные базы данных, механизм кэширования и API. Они слабо связаны, что позволяет легко масштабировать их индивидуально по мере необходимости.
SAGA
Этот шаблон используется в распределенных системах для обеспечения согласованности данных в микросервисах без использования централизованного диспетчера транзакций. Он разбивает большую транзакцию на ряд более мелких изолированных операций.
В основе последовательность транзакций — действий, выполняемых микросервисом. Если транзакция завершается неудачей, изменения откатываются, чтобы обеспечить согласованность данных. Выполнение транзакции может быть централизованное и децентрализованное.
Пример реализации паттерна SAGA в микрсервисной архитектуре есть у меня в github: https://github.com/Bereshs/SagaPattern
Circuit Breaker
Паттерн "Автоматический выключатель" повышает устойчивость и отказоустойчивость системы, предотвращая каскадные сбои обслуживания.
Он имеет три состояния цепи:
Замкнутая цепь: это нормальное состояние, в котором проходят все запросы. Любые сбои фиксируются по мере их возникновения.
Разомкнутая цепь: если количество сбоев превысило указанный нами порог, цепь разрывается. Это заблокирует дальнейшие запросы на вызов нижестоящей службы.
Полуоткрытый канал: когда канал находится в открытом состоянии в течение определенного времени, он переходит в полуоткрытое состояние, позволяя проходить ограниченным запросам для проверки восстановления нисходящей службы. Если запрос успешен, состояние схемы меняется на «Закрыто», в противном случае оно снова меняется на «Открыто».
Этот паттерн отслеживает ответ нижестоящей службы. Если он обнаружит какие-либо сбои, такие как тайм-ауты, исключения и т. д., это приведет к разрыву цепи.
Преимущества:
Aggregator
Паттерн «Агрегатор» используется для объединения ответов из различных источников в единый результат. Это позволяет клиентам получать все необходимые данные за один вызов, а не делать несколько запросов к разным службам.
Преимущества:
- Клиентская логика упрощается, поскольку не требуется выполнять несколько вызовов.
- Улучшение производительности
- Централизованное агрегирование данных
- Уменьшает чрезмерную сетевую связь за счет уменьшения количества вызовов от Клиентов.
Недостатки:
- Уровень агрегатора действует как единая точка отказа.
- Увеличение задержки
- Агрегатор становится более сложным, поскольку добавляется больше нижестоящих сервисов.
- Если у нас есть разные клиенты, требующие разного ответа, этот шаблон бесполезен.
API Gateway
В паттерне проектирования API Gateway у нас есть одна точка входа, которая обрабатывает все клиентские запросы. Эта точка входа называется API Gateway. Он предоставляет уникальный интерфейс для всех клиентов.
API Gateway выполняет различные задачи:
- Маршрутизация вызовов к микросервисам
- Агрегация ответов
- Аутентификация
- Rate Limiter
Общая схема API шлюза:
- Клиент делает запрос к Gateway.
- Затем шлюз проверяет подлинность запроса, при необходимости применяет политику ограничения скорости, и далее перенаправляет запрос соответствующим микросервисам.
- Микросервисы возвращают ответ шлюзу API.
- Шлюз объединяет различные ответы и отправляет клиенту консолидированный окончательный ответ.
Преимущества
- Централизована безопасность
- Уменьшает чрезмерную сетевую связь от клиентов
- Улучшенное управление версиями API
- Оптимизация производительности
Недостатки
- API-шлюз действует как единая точка отказа
- Сложность масштабирования API-шлюза, поскольку он обрабатывает большое количество запросов.
- Накладные расходы на производительность из-за дополнительного уровня