Основные паттерны микросервисной архитектуры: Strangler Fig, API Gateway, Service Mesh и другие

#чтояпрочитал #микросервисы

Ссылка на оригинал: https://habr.com/ru/articles/904954/

Краткая выжимка

Strangler fig (удушающее дерево) — подход, при котором создаётся некий фасад, изначально перенаправляющий запросы в монолит. По мере реализации микросервисов, перенаправление запросов переключается на них. Процесс повторяется, пока монолит не будет полностью вытеснен.

API Gateway (API-шлюз) — точка для аккумуляции и последующего распределения пользовательских запросов по сервисам. По сути, он и является тем самым фасадом, который может помочь в случае использования паттерна Strangler fig.

API Gateway делят на несколько шаблонов:

- Routing — шлюз выполняет функцию маршрутизатора, прокси
- Aggregation — шлюз агрегирует данные: получая один запрос от клиента, ходит в несколько сервисов, возвращает клиенту единый ответ
- Offloading — шлюз берёт на себя ряд общих задач для сервисов (например, авторизация, логгирование, etc.)

На практике, API Gateway часто совмещает все эти роли.

Service Mesh — архитектурный паттерн для организации умной сетевой прослойки в микросервисной архитектуре. По сути, это распределённая система прокси-серверов, сопровождающая каждый из сервисов. То есть, у каждого сервиса появляется свой прокси под боком. Нужно это для того, чтобы снять с микросервисов необходимость реализации логики для балансировки, шифрования, отслеживания метрик и так далее.

Sidecar — это паттерн, предлагающий вынесение неосновной логики приложения в отдельный контейнер, запускаемый рядом с основным сервисом. Например, логгирование, конфигурация, связи с внешними системами. Это позволяет повысить модульность вашего приложения.

Database per Service — паттерн "база данных на сервис".

CQRS (Command Query Responsibility Segregation) — паттерн, разделяющий ответственность за изменение состояния и чтение состояния приложения между разным компонентами или моделями. По сути, это про использование двух БД для одного сервиса: одна БД для записи, другая для чтения.

Event Sourcing — паттерн хранения состояния системы, при котором каждое изменение состояния сохраняется, как отдельное событие. По сути, мы храним историю изменений каждого объекта в виде списка событий.

Выводы

Отличная статья, довольно подробная, с примерами и обоснованиями что и когда нужно и не нужно использовать. Рекомендую к прочтению.