Microservices Flashcards
Что такое микросервис?
- Исполняется в собственном контексте
- Имеет собственный публичный API
- Реализует определенную бизнес-логику.
- одна команда разработчиков владеет 1 или несколькими МС
https://mcsjournal.ru/blog/26-osnovnyh-patternov-mikroservisnoj-razrabotki
Шаблон «Разбиение по бизнес-возможностям» (Decompose By Business Capability)
Паттерн декомпозиции на микросервисы
Предполагает определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них. Бизнес-возможности представляют собой функции, которые будут доступны пользователям при работе с приложением.
- Управление созданием заказов -> Order Creation Service
- Управление доставкой заказов -> Order Delivery Service
- Управление платежами -> Payment Service
- Управление клиентами -> Client Service
- …
При разбиении по бизнес-возможностям могут появиться так называемые «божественные классы» (God Classes) — сущности, которые будут общими для нескольких микросервисов. Как правило, их очень сложно разделить.
Шаблон «Разбиение по поддоменам» (Decompose By Subdomain)
Паттерн декомпозиции на микросервисы
Чтобы избежать появления God Classes, можно использовать шаблон разбиение по поддоменам. Он основан на концепциях предметно-ориентированного проектирования (Domain-Driven Design, DDD).
DDD разбивает всю модель предметной области (домен) на поддомены. У каждого поддомена своя модель данных, область действия которой принято называть ограниченным контекстом (Bounded Context). Каждый микросервис будет разрабатываться внутри этого ограниченного контекста. Основная задача при использовании DDD-подхода — подобрать поддомены и границы между ними так, чтобы они были максимально независимы друг от друга.
Шаблон «Душитель» (Strangler)
Паттерны рефакторинга для перехода на микросервисы
Этот шаблон означает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы. Настраивается маршрутизация запросов между устаревшим монолитом и микросервисами. Когда очередная функциональность переносится из монолита в микросервисы, фасад перехватывает клиентский запрос и направляет его к микросервисам. Новые функции при этом реализуются исключительно в микросервисах, минуя монолит. После переноса всех функций монолитное приложение полностью выводится из эксплуатации.
- Шаблон «Уровень защиты от повреждений» (Anti-Corruption Layer)
Паттерны рефакторинга для перехода на микросервисы
Он предназначен для изолирования различных подсистем путем размещения между ними дополнительного уровня, который может быть реализован как компонент приложения или независимая служба. Этот уровень связывает две подсистемы, позволяя им оставаться максимально независимыми друг от друга. Он содержит всю логику, необходимую для передачи данных в обе стороны: при взаимодействии с каждой из подсистем используется именно ее модель данных.
- Шаблон «База данных на сервис» (Database Per Service)
Шаблон Управления Данными
Основная рекомендация при переходе на микросервисы — предоставить каждому сервису собственное хранилище данных, чтобы не было сильных зависимостей на уровне данных. При этом имеется в виду именно логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же физическую базу данных, но в ней они должны взаимодействовать с отдельной схемой, коллекцией или таблицей.
Основанный на этих принципах паттерн Database Per Service повышает автономность микросервисов и уменьшает связь между командами, разрабатывающими отдельные сервисы.
Шаблон «API-композиция» (API Composition)
Шаблон Управления Данными
Этот шаблон является одним из возможных вариантов получения данных из нескольких сервисов после применения к ним паттерна Database Per Service. Он предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти. Паттерн можно рассматривать как вариант использования другого шаблона — API Gateway, о котором мы поговорим ниже.
Шаблон «Разделение команд и запросов» (Command Query Responsibility Segregation, CQRS)
Шаблон Управления Данными
Этот паттерн предлагает отделить изменение данных (Command) от чтения данных (Query). Шаблон CQRS имеет две формы: простую и расширенную.
В простой форме для чтения и записи используются отдельные модели ORM (Object-Relational Mapping), но общее хранилище данных.
В расширенной форме используются разные хранилища данных, оптимизированные для записи и чтения данных. Данные копируются из хранилища для записи в хранилище для чтения асинхронно. В результате хранилище для чтения отстает от хранилища для записи, но в конечном итоге является согласованным. Расширенный CQRS часто используется совместно с паттерном Event Sourcing
Шаблон «Поиск событий» (Event Sourcing)
Шаблон Управления Данными
В традиционных базах данных объект с текущим состоянием сохраняется напрямую. При использовании шаблона Event Sourcing вместо объектов сохраняются события, изменяющие их состояния. Итоговое состояние объекта можно получить путем повторной обработки серии событий, пришедших за определенное время. Различные службы могут воспроизводить события из хранилища событий, чтобы вычислить соответствующее состояние своих хранилищ данных. Для реализации хранилища событий обычно применяется шаблон CQRS.
Шаблон «Сага» (Saga)
Шаблон Управления Данными
Этот паттерн предназначен для управления распределенными транзакциями в микросервисной архитектуре, где применение традиционного протокола двухфазной фиксации транзакций (Two-phase commit protocol, 2PC) становится трудноосуществимым.
- Шаблон «API-шлюз» (API Gateway)
Паттерн коммуникации микросервисов
Обеспечивает единую точку входа для клиента. Общается с клиентом по REST , но с сервисами может общаться любым проотоколом.
- Gateway Routing. Шлюз используется как обратный Proxy, перенаправляющий запросы клиента на соответствующий сервис.
- Gateway Aggregation. Шлюз используется для разветвления клиентского запроса на несколько микросервисов и возвращения агрегированных ответов клиенту.
- Gateway Offloading. Шлюз решает сквозные задачи, которые являются общими для сервисов: аутентификация, авторизация, SSL, ведение журналов и так далее.
2. Шаблон «Бэкенды для фронтендов» (Backends for Frontends, BFF)
Паттерн коммуникации микросервисов
Расширяет шаблон API-gateway
Предполагает свой шлюз на каждый тип устройства (desktop / ois / android / …)
Зачем нужны паттерны обнаружения сервисов в микросервисной архитектуре?
Эта группа шаблонов описывает методы, которые могут использовать клиентские приложения для определения местонахождения нужных им сервисов. Это особенно важно в микросервисных приложениях, так как они работают в виртуализированных и контейнерных средах, где количество экземпляров сервисов и их расположение изменяются динамически.
Ключевым компонентом обнаружения микросервисов выступает реестр сервисов (Service Registry) — база данных с информацией о расположении сервисных экземпляров. Когда экземпляры запускаются и останавливаются, информация в реестре обновляется. Но взаимодействовать с реестром сервисов можно двумя путями, которые и легли в основу описанных ниже шаблонов.
Шаблон «Обнаружение сервисов на стороне клиента» (Client-Side Service Discovery)
Паттерны обнаружения сервисов
В этом случае сервисы и их клиенты напрямую взаимодействуют с реестром.
Шаблон «Обнаружение сервисов на стороне сервера» (Server-Side Service Discovery)
Паттерны обнаружения сервисов
В этом случае за регистрацию, обнаружение сервисов и маршрутизацию запросов отвечает инфраструктура развертывания.
ПРЕДПОЧТИТЕЛЕН.
