Паттерн Microservice Architecture

Компании, такие как Netflix, Amazon и Twitter, одними из первых начали активно использовать микросервисы

Контекст
ПРоблемная Маша:
Слушай, нам поставили задачу быстро и часто вносить изменения на прод. Что делать? Нас тут 30 программеров, мы заливаем код по графику, что бы не сильно мешать друг другу, а на прод выкатываем релизами раз в два месяца.
Выручающий Саша:
Делов то! Вам просто надо разбить монолит на микросервисы и организоваться в кросс функциональные команды, которые будут использовать девопс технологии для непрерывной доставки и развертывания.
ПРоблемная Маша:
Звучит круто!
Выручающий Саша:
Ну тогда пошли учить микросервисные паттерны. Главное не накосячить на этапе проектирования!
Проблема
Как организовать код для разработки большого приложения независимыми частями, чтобы можно было эти части независимо друг от друга масштабировать, менять и доставлять в продакшен.
Решение
  1. Разбиваем модель на бизнес сущности (агрегаты DDD).
  2. Бизнес сущности образуют поддомены - единица безнес-функциональности (к примеру регистрация).
  3. В одном микросервисе может быть один или несколько поддоменов. Несколько поддоменов включаются в один микр когда это логично и оправдано с точки зрения архитектуры.
По сути это и есть первая главная задача в проектировании микросервисной архитектуры - собрать поддомены так, чтобы не было чрезмерной нагрузки на сеть и проблем с производительностью из-за слишком мелких микров и в тоже время сохранялась гибкость и возможность быстро и независимо вносить изменения и масштабировать отдельные микры.
Преимущества
  • Упрощение кода
    Простые микросервисы, состоящие из нескольких поддоменов, легче понимать и поддерживать.
  • Команда независимая
    Команда теперь может разрабатывать, тестировать и развертывать свой микросервис независимо от других команд.
  • CI/CD
    Высокая частота развертываний обеспечивается быстрым независимым конвейером развертывания.
  • Разный стек
    В разных микрах можно использовать разные версии технологий или даже разные технологии, даже разные языки.
  • Масштабирование и отказоустойчивость
    У микров разные требования по производительности и доступности, соответственно можно где-то давать много ресурсов и уделить время и ресурсы отказоустойчивости, а где-то можно экономить.
Недостатки
  • Распределенные операции
    Для выполнения одного запроса, может требоваться участие многих микросервисов, что усложняет работу в части отладки, сохранения консистентности, тестирования и проектирования.
  • Сетевые нагрузки
    Всегда взаимодействие в одном адресном пространстве быстрее чем взаимодействие по сети. Большое количество запросов между микрами и объем данных перегоняемых по сети может создавать проблемы с производительностью.
  • Распределенные транзакции
    Транзакция ACID проще и надежнее чем BASE как в SAGA
  • Необходимость в дополнительной инфраструктуре
    Теперь нужны дополнительные системы для мониторинга, балансировки запросов между репликами, маршрутизации запросов и т.д.
JavaGuru.by
Онлайн-школа профессионального программирования на java для коммерческих разработчиков и соискателей.
2 главные задачи, которые мы решаем:
  1. Трудоустройство и успешное прохождение испыталки.
  2. Переход на современный стек middle+
Наше главное достояние:
Менторская поддержка 24/7 и обучение в формате живого общения
Получить консультацию по обучению