Паттерны микросервисов

1.

Паттерны микросервисов
Самарин Владислав

2.

Кто такой этот микросервис?
Микросервис — это архитектурный
паттерн, который предполагает
разделение системы на небольшие
независимые сервисы, каждый из
которых выполняет свою функцию.

3.

Преимущества использования патернов при проектировании
микросервисов
-
Уменьшение ошибок при проектировании микросервисов — без необходимости их
рефакторинга в дальнейшем.
Более быстрая и качественная миграция монолитов на микросервисную архитектуру.
Предотвращение ненужных вызовов и неэффективного использования ресурсов.
Отсутствие проблем с подключением новых сервисов, их интеграцией друг с другом и
базами данных.
Лучшая масштабируемость: добавление дополнительных сервисов не вызывает
затруднений в обслуживании зависимостей.
Повышение отказоустойчивости.
Минимизация угроз безопасности, в том числе сокрытие конечных точек микросервисов.
Сокращение работ по обслуживанию и отладке.

4.

Паттерны проектирования микросервисов
1) Паттерны декомпозиции на микросервисы
2) Паттерны рефакторинга для перехода на микросервисы
3) Паттерны управления данными в микросервисной архитектуре
4) Паттерны коммуникации микросервисов
5) Паттерны построения пользовательского интерфейса
6) Паттерны обнаружения сервисов в микросервисной архитектуре
7) Паттерны развертывания микросервисов
8) Паттерны повышения отказоустойчивости
9) Паттерны мониторинга микросервисов
10) Прочие паттерны проектирования микросервисов

5.

Паттерны декомпозиции (разделения) на микросервисы
«Разбиение по бизнес-возможностям» (Decompose By Business Capability)
Один из наиболее известных способов
разбиения на микросервисы — это
определение бизнес-возможностей
приложения и создание по одному
микросервису на каждую из них.
Бизнес-возможности представляют
собой функции, которые будут
доступны пользователям при работе с
приложением.

6.

Паттерны декомпозиции (разделения) на микросервисы
«Разбиение по поддоменам» (Decompose By Subdomain)
Он основан на концепциях предметноориентированного проектирования (DomainDriven Design, DDD).
DDD разбивает всю модель предметной области
(домен) на поддомены. У каждого поддомена
своя модель данных, область действия которой
принято называть ограниченным контекстом
(Bounded Context). Каждый микросервис будет
разрабатываться внутри этого ограниченного
контекста. Основная задача при использовании
DDD-подхода — подобрать поддомены и
границы между ними так, чтобы они были
максимально независимы друг от друга.

7.

Паттерны рефакторинга для перехода на микросервисы
«Душитель» (Strangler)
Этот шаблон означает миграцию монолитного
приложения на микросервисную архитектуру
путем постепенного переноса существующих
функций в микросервисы. Настраивается
маршрутизация запросов между устаревшим
монолитом и микросервисами. Когда очередная
функциональность переносится из монолита в
микросервисы, фасад перехватывает клиентский
запрос и направляет его к микросервисам. Новые
функции при этом реализуются исключительно в
микросервисах, минуя монолит. После переноса
всех функций монолитное приложение
полностью выводится из эксплуатации.

8.

Паттерны рефакторинга для перехода на микросервисы
«Уровень защиты от повреждений» (Anti-Corruption Layer)
Он предназначен для изолирования
различных подсистем путем размещения
между ними дополнительного уровня,
который может быть реализован как
компонент приложения или независимая
служба. Этот уровень связывает две
подсистемы, позволяя им оставаться
максимально независимыми друг от друга. Он
содержит всю логику, необходимую для
передачи данных в обе стороны: при
взаимодействии с каждой из подсистем
используется именно ее модель данных.

9.

Паттерны управления данными в микросервисной архитектуре
«База данных на сервис» (Database Per Service)
Этот паттерн проектирования
предполагает, что каждый
микросервис имеет свою собственную
базу данных. Это позволяет
микросервисам быть независимыми
друг от друга и упрощает их
масштабирование.

10.

Паттерны управления данными в микросервисной архитектуре
«API-композиция» (API Composition)
Этот шаблон является одним из
возможных вариантов получения
данных из нескольких сервисов после
применения к ним паттерна Database
Per Service. Он предлагает создать
отдельное API, которое будет
вызывать необходимые сервисы,
владеющие данными, и выполнять
соединение полученных от них
результатов в памяти.

11.

Паттерны управления данными в микросервисной архитектуре
«Разделение команд и запросов» (Command Query Responsibility Segregation,
CQRS)
Этот паттерн предлагает отделить изменение данных
(Command) от чтения данных (Query). Шаблон CQRS имеет две
формы: простую и расширенную.
В простой форме для чтения и записи используются отдельные
модели ORM (Object-Relational Mapping), но общее хранилище
данных.
В расширенной форме используются разные хранилища
данных, оптимизированные для записи и чтения данных.
Данные копируются из хранилища для записи в хранилище для
чтения асинхронно. В результате хранилище для чтения
отстает от хранилища для записи, но в конечном итоге является
согласованным.

12.

Паттерны управления данными в микросервисной архитектуре
«Поиск событий» (Event Sourcing)
Этот паттерн предполагает, что все изменения в системе сохраняются в виде
событий. Это позволяет восстановить состояние системы в любой момент
времени, а также упростить логику обработки запросов.

13.

Паттерны управления данными в микросервисной архитектуре
«Сага» (Saga)
Позволяет координировать выполнение транзакций в распределённой системе.
Этот паттерн предполагает, что каждая транзакция состоит из нескольких шагов, каждый из которых выполняется
отдельным микросервисом. Если один из шагов завершается неудачно, то все предыдущие шаги отменяются, а
система возвращается в исходное состояние.
Для координации транзакций существует два основных способа:
- Хореография. Децентрализованная
координация, при которой каждый
микросервис прослушивает
события/сообщения другого микросервиса и
решает, следует предпринять действие или
нет.
- Оркестровка. Централизованная
координация, при которой отдельный
компонент (оркестратор) сообщает
микросервисам, какое действие необходимо

14.

Паттерны коммуникации микросервисов
«API-шлюз» (API Gateway)
Этот паттерн основан на применении шлюза,
который находится между клиентским
приложением и микросервисами, обеспечивая
единую точку входа для клиента.
Применение паттерна сокращает число вызовов,
обеспечивает независимость клиента от
протоколов, используемых в сервисах: REST,
AMQP, gRPC и так далее, обеспечивает
централизованное управление сквозной
функциональностью. Однако шлюз может стать
единой точкой отказа, требует тщательного
мониторинга и при отсутствии масштабирования
бывает узким местом системы.

15.

Паттерны коммуникации микросервисов
«Бэкенды для фронтендов» (Backends for Frontends, BFF)
Этот паттерн предполагает, что
каждый фронтенд (клиентское
приложение) имеет свой собственный
бэкенд (микросервис), который
отвечает за обработку запросов от
этого фронтенда.

16.

Паттерны построения пользовательского интерфейса
«Сборка пользовательского интерфейса на стороне клиента» (Client-Side UI
Composition)
Этот паттерн предполагает, что
пользовательский интерфейс (UI)
собирается на стороне клиента из
компонентов, предоставляемых
микросервисами.

17.

Паттерны построения пользовательского интерфейса
«Сборка фрагментов страниц на стороне сервера» (Server-Side Page Fragment
Composition)
При использовании этого шаблона
сборка фрагментов пользовательского
интерфейса происходит на сервере, а
клиентская часть получает уже
полностью собранную страницу,
благодаря чему достигается более
высокая скорость загрузки. Сборка
обычно выполняется отдельной
службой, которая находится между
браузером и серверами приложений:
Nginx, Varnish, CDN.

18.

Паттерны обнаружения сервисов в микросервисной архитектуре
«Обнаружение сервисов на стороне клиента» (Client-Side Service Discovery)
Сервисы и их клиенты напрямую взаимодействуют с реестром.
Последовательность шагов следующая:
1)
2)
3)
Экземпляр сервиса обращается к API реестра, чтобы
зарегистрировать свое сетевое местоположение. Он
также может предоставить URL-адрес для проверки
своей работоспособности (Health Check), который
будет использоваться для продления срока его
регистрации в реестре.
Клиент самостоятельно обращается к реестру сервисов,
чтобы получить список экземпляров сервисов. Для
улучшения производительности клиент может
кэшировать экземпляры сервиса.
Клиент использует алгоритм балансировки нагрузки,
циклический или случайный, чтобы выбрать
конкретный экземпляр сервиса и отправить ему запрос.

19.

Паттерны обнаружения сервисов в микросервисной архитектуре
«Обнаружение сервисов на стороне сервера» (Server-Side Service Discovery)
За регистрацию, обнаружение сервисов и маршрутизацию запросов отвечает инфраструктура развертывания. Последовательность шагов
следующая:
1)
2)
3)
4)
Регистратор, который обычно является частью платформы развертывания, прописывает все экземпляры сервисов в реестре
сервисов. По каждому экземпляру сохраняется DNS-имя и виртуальный IP-адрес (VIP).
Вместо того чтобы обращаться к реестру напрямую, клиент делает запрос по DNS-имени сервиса. Запрос поступает в
маршрутизатор, являющийся частью платформы развертывания.
Маршрутизатор обращается к реестру сервисов для получения сетевого расположения экземпляров нужного сервиса.
Маршрутизатор применяет балансировку нагрузки, чтобы выбрать конкретный экземпляр сервиса и отправить ему запрос.
Все современные платформы
развертывания, включая Docker,
Kubernetes и другие, как правило,
имеют встроенный реестр и
механизмы обнаружения сервисов.

20.

Паттерны развертывания микросервисов
«Экземпляр сервиса на хост» (Service Instance Per Host)
Этот паттерн предполагает, что
каждый хост (сервер) запускает один
экземпляр каждого микросервиса. Это
позволяет микросервисам быть
независимыми друг от друга и
упрощает их масштабирование.

21.

Паттерны развертывания микросервисов
«Сине-зеленое развертывание» (Blue-Green Deployment)
Паттерн позволяет выполнить
развертывание новых версий сервисов
максимально незаметно для
пользователей, сократив время простоя
до минимума. Это достигается за счет
запуска двух идентичных
производственных сред — условно
синего и зеленого цвета. Предположим,
что синий — это существующий
активный экземпляр, а зеленый — это
новая версия приложения, развернутая
параллельно с ним.

22.

Паттерны повышения отказоустойчивости
«Автоматический выключатель» (Circuit Breaker)
Микросервис будет запрашивать
другой микросервис через Proxyсервер. Он подсчитывает количество
недавних сбоев и на основе него
определяет, разрешать ли
выполнение последующих вызовов
или немедленно возвращать
исключение.

23.

Паттерны повышения отказоустойчивости
«Переборка» (Bulkhead)
Шаблон позволяет разделить ресурсы,
чтобы гарантировать, что ресурсы,
используемые для вызова одного
сервиса, не влияют на ресурсы,
используемые для вызова другого
сервиса.

24.

Паттерны мониторинга микросервисов
«Агрегация логов» (Log Aggregation)
Паттерн Log Aggregation предлагает
использовать централизованную
службу ведения логов, которая будет
собирать логи от каждого экземпляра
сервиса. Это предоставит
пользователям единую точку для
поиска, анализа логов и настройки
предупреждений, которые будут
запускаться при появлении в них
определенных сообщений.

25.

Паттерны мониторинга микросервисов
«Распределенная трассировка» (Distributed Tracing)
Этот паттерн предлагает назначать
каждому внешнему запросу
уникальный идентификатор (TraceId),
который будет передаваться всем
сервисам, участвующим в обработке
запроса, и фиксироваться в журналах.
Это позволит разработчикам видеть,
как обрабатывается отдельный
запрос, путем поиска в
агрегированных журналах его
внешнего идентификатора.

26.

Паттерны мониторинга микросервисов
«Проверки здоровья» (Health Check)
Этот паттерн предлагает определить для
каждого сервиса конечную точку, которую
можно использовать для проверки
работоспособности, например /health. Этот
API должен проверять статус хоста,
подключение к другим сервисам,
инфраструктуре и любую иную бизнеслогику. Клиент — служба мониторинга,
реестр служб или балансировщик нагрузки —
будет периодически обращаться к конечной
точке для проверки работоспособности
экземпляра сервиса.

27.

Прочие паттерны проектирования
«Посредник» («Посол», Ambassador)
Паттерн Ambassador предлагает
помещать клиентские фреймворки и
библиотеки для решения
периферийных задач внутрь
вспомогательного сервиса,
выступающего в роли Proxy между
клиентским приложением или
основным сервисом и прочими
частями системы.

28.

Прочие паттерны проектирования
«Коляска» («Прицеп», Sidecar)
Паттерн Sidecar предлагает помещать
периферийные задачи, связанные с
мониторингом, безопасностью,
отказоустойчивостью и так далее, в отдельный
компонент и развертывать его внутри
собственного процесса или контейнера. Так
обеспечивается однородный интерфейс для
сервисов основного приложения, которые могут
быть написаны на разных языках.
Sidecar не обязательно является частью
приложения, но связан с ним: для каждого
экземпляра приложения рядом развертывается
экземпляр Sidecar. Sidecar имеет тот же
жизненный цикл, что и основное приложение.

29.

Прочие паттерны проектирования
«Тестирование контрактов, ориентированных на потребителя» (ConsumerDriven Contract Testing)
Паттерн Consumer-Driven Contract
Testing увеличивает автономность
команд и позволяет своевременно
обнаруживать изменения в сервисах,
написанных другими командами. Но
его применение может потребовать
дополнительной работы по
интеграции тестов, так как команды
могут пользоваться различными
инструментами тестирования.

30.

Прочие паттерны проектирования
«Внешняя конфигурация» (External Configuration)
Этот паттерн предлагает хранить все
конфигурации во внешнем хранилище. В
качестве такого хранилища может
выступать облачная служба хранения,
база данных или другая система.
В результате применения шаблона
процесс сборки будет отделен от среды
выполнения, а риски безопасности
будут сведены к минимуму, так как
конфигурации для производственной
среды перестанут являться частью
кодовой базы.

31.

Источники
https://dzen.ru/a/YKJ99EP6Y0aFqFC1
https://vc.ru/u/1969656-dmitriy/725850-12-shablonov-mikroservisov-kotorye-ya-hotelby-znat-do-sobesedovaniya-po-sistemnomu-dizaynu
https://habr.com/ru/companies/serverspace/articles/692916/