Микросервисная архитектрура
Один из самых интересных и обсуждаемых за последние лет 10 архитектурных стилей.
Для чего на неё переходят:
1. Улучшение возможностей масштабирования.
При запуске монолитного приложения на 1 физической машине существует предел для его масштабирования, который определяется физическими характеристиками машины (процессор, память).
Микросервисная архитектура предполагает полную развязку компонентов системы на уровне предметной области. Каждый компонент в этом случае представляет собой отдельное приложение, которое может быть запущено в своём процессе (физическое устройство, виртуальная машина, контейнер).
2. Удобство и скорость разработки и тестирования за счёт уменьшения связанности.
Благодаря ограничению контекста компонентов в микросервисной архитектуре, получаем большую независимость приложений. Исключается использование приложениями общих классов. Дублирование кода считается более предпочтительным явлением, чем использование общих библиотек классов.
Основные требования, предъявляемые к микросервисной архитектуре:
1. Гранулярность
У каждого приложения должны быть строго определены границы:
- предметной области,
- транзакций,
- минимум (а в идеале - полное отсутствие) хореографии.
2. Изолированность данных
Каждоеприложение имеет свою собственную базу данных. Приемлемыми считаются следующие пособы распространения данных между приложениями:
- считать одну предметную область источником истины и обращаться к ней за соответствующими данными,
- репликация базы данных,
- кэширование данных.
3. API уровень не должен использоваться в качестве медиатора (оркестратора)
Sidecar:
Сайдкаром называют общую "инфраструктурную" логику:
- логирование,
- мониторинг,
- выключатели,
- и т.д.,
которая может работать со всеми приложениями системы.
Несмотря на требования гранулярности, в мире микросервисов невозможно обойтись без использования такой общей логики.
Код этой логики может как включаться в код приложений в виде отдельного компонента, так и разворачиваться полностью независимо от приложений, входящих в микросервисную архитектуру.
В случае независимого развёртывания sidecar-а предоставляет для микросервисов панель обслуживания (шину, API), через которую сервисы могут предоставлять свои данные (логи, метрики, URL-ы) для нужд инфраструктуры. Такое объединение микросервисов через общую панель называется service mesh.
А что фронтенд?
На фронтенде ситуация похожа на бэкенд. Фронтенд может быть монолитным:
Или микросервисным:
Транзакции:
Транзакции, пересекающие границы одного приложения (микросервиса), называются расперделёнными транзакциями.
По общему мнению, лучше постараться избежить вознкновения таких транзакций, так как они:
- нарушают основной принцип разделенности в архитектуре микросервисов
- создают наихудший вид динамической коннасценции, а именно - коннасценцию значений.
Если всё-таки распределённая транзакция появляется, то предпочтительным вариантом является корректировка гранулярности (границ) микросервисов.
Если корректировка гранулярности невозможна или нецелесообразна, то распределённые транзакции могут быть реализованы с помощью паттерна "Сага".