MICROSERVICES Flashcards
Что такое микросервис?
Микросервис - это архитектурный подход для разработки приложений, который предполагает создание небольших, независимых и автономных сервисов, взаимодействующих между собой через сетевые протоколы.
Каждый сервис отвечает за решение конкретной задачи или предоставление определенной функциональности.
Основные преимущества микросервисной архитектуры включают:
- Улучшенную масштабируемость: каждый сервис может масштабироваться независимо от других сервисов, что позволяет более эффективно управлять ресурсами.
- Упрощенную разработку: каждый сервис является самостоятельным и может быть разработан и развернут независимо от других сервисов, что упрощает процесс разработки и деплоя.
- Более высокую отказоустойчивость: если один из сервисов выходит из строя, это не влияет на работу остальных сервисов, что уменьшает риски для приложения в целом.
- Улучшенную гибкость: микросервисная архитектура позволяет легко добавлять или удалять сервисы, а также менять функциональность сервисов в зависимости от изменяющихся требований.
Шаблон «Разбиение по бизнес-возможностям» (Decompose By Business Capability)
Паттерн декомпозиции на микросервисы.
Предполагает определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них. Бизнес-возможности представляют собой функции, которые будут доступны пользователям при работе с приложением.
- Управление созданием заказов -> Order Creation Service
- Управление доставкой заказов -> Order Delivery Service
- Управление платежами -> Payment Service
- Управление клиентами -> Client Service
- Управление уведомлениями -> Notification Service
При разбиении по бизнес-возможностям могут появиться так называемые «божественные классы» (God Classes) — сущности, которые будут общими для нескольких микросервисов. Как правило, их очень сложно разделить.
Шаблон «Разбиение по поддоменам» (Decompose By Subdomain)
Паттерн декомпозиции на микросервисы
Шаблон “Разбиение по поддоменам” (Decompose By Subdomain) - это подход к проектированию архитектуры системы, при котором система разбивается на набор автономных компонентов, каждый из которых отвечает за реализацию конкретного поддомена бизнеса.
Поддомен бизнеса - это часть бизнес-домена, которая содержит некоторые специфические процессы и правила, уникальные для данной области бизнеса.
Чтобы избежать появления God Classes, можно использовать шаблон разбиение по поддоменам. Он основан на концепциях предметно-ориентированного проектирования (Domain-Driven Design, DDD).
DDD позволяет разбивать всю модель предметной области (то есть домен) на поддомены. То есть у каждого поддомена существует своя модель данных, а область действия этих данных называют ограниченным контекстом – Bounded Context. Таким образом, каждый микросервис разрабатывается внутри этого ограниченного контекста. Главная задача при таком подходе — подобрать поддомены, а также границы между ними таким образом, чтобы они были максимально независимыми друг от друга.
Профит – появляется возможность уменьшить количество микросервисов, если сравнивать с той же декомпозицией на основании бизнес-возможностей.
Шаблон «Душитель» (Strangler)
Паттерн рефакторинга для перехода на микросервисы
Проблема: **необходимость перевести на микросервисную архитектуру уже существующие монолитные приложения. **
Разложение монолита на микросервисы требует времени и не может быть выполнено за одну итерацию. Поэтому и был разработан паттерн Strangler, названный по аналогии с лианой, которая постепенно душит обвиваемое ею дерево.
Этот шаблон означает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы.
Паттерн Strangler выступает за создание надстройки фасада поверх вашего легаси и нового приложения.
Настраивается маршрутизация запросов между устаревшим монолитом и микросервисами.
Когда очередная функциональность переносится из монолита в микросервисы, фасад перехватывает клиентский запрос и направляет его к микросервисам. Новые функции при этом реализуются исключительно в микросервисах, минуя монолит.
После переноса всех функций монолитное приложение полностью выводится из эксплуатации.
Шаги реализации шаблона “Душитель” (Strangler) в микросервисной архитектуре могут выглядеть следующим образом:
1. Идентификация функциональных зон (functional zones) в монолите: определение существующих функциональных областей, которые могут быть разделены на отдельные микросервисы.
2. Создание новых микросервисов: создание новых микросервисов для замены функциональных зон в монолите.
3. Настройка маршрутизации: настройка маршрутизации запросов между монолитом и микросервисами. Возможно использование API Gateway, сервиса маршрутизации или других инструментов, которые позволят направлять запросы на правильные микросервисы в зависимости от типа запроса или других параметров.
4. Постепенное перенос функциональности: постепенный перенос функциональности из монолита в микросервисы. Это может происходить постепенно или сразу для нескольких функциональных зон.
5. Удаление устаревшей функциональности: после переноса всех функций монолита в микросервисы можно удалить устаревший код из монолита.
6. Мониторинг и тестирование: важно следить за работоспособностью и производительностью новых микросервисов, а также за корректной работой маршрутизации запросов. Тестирование и мониторинг могут помочь выявить и исправить проблемы.
Шаблон «Уровень защиты от повреждений» (Anti-Corruption Layer)
Паттерны рефакторинга для перехода на микросервисы
Он предназначен для изолирования различных подсистем путем размещения между ними дополнительного уровня, который может быть реализован как компонент приложения или независимая служба. Этот уровень связывает две подсистемы, позволяя им оставаться максимально независимыми друг от друга. Он содержит всю логику, необходимую для передачи данных в обе стороны: при взаимодействии с каждой из подсистем используется именно ее модель данных.
Название паттерна
Шаблон “Уровень защиты от повреждений” (Anti-Corruption Layer) в микросервисной архитектуре.
Какую проблему решает
В микросервисной архитектуре при интеграции между собой различных сервисов может возникать проблема несовместимости интерфейсов.
Когда компании имеют множество различных сервисов, например, на разных технологических платформах, может возникнуть проблема обмена информацией между ними. Каждый сервис может использовать свой собственный формат данных, структуру и схему данных, что затрудняет обмен информацией между сервисами. Это приводит к проблемам совместимости, ошибкам обработки данных, низкой производительности и другим проблемам.
Краткое описание функциональности
Шаблон “Уровень защиты от повреждений” представляет собой слой абстракции между двумя взаимодействующими системами. Он преобразует данные из формата одной системы в формат другой и обеспечивает прозрачность взаимодействия. Это позволяет сделать связи между сервисами менее зависимыми и уменьшить вероятность возникновения ошибок при интеграции.
Сущности, которые участвуют в паттерне
- Клиентский сервис - сервис, который отправляет запросы и получает ответы от других сервисов
- Целевой сервис - сервис, на который отправляются запросы
- Уровень защиты от повреждений - слой абстракции между клиентским и целевым сервисом, который переводит запросы и ответы из одного формата в другой
Шаги реализации шаблона “Уровень защиты от повреждений”:
1. Определение формата данных и протоколов взаимодействия внешней и внутренней систем
2. Создание класса, реализующего уровень защиты от повреждений, который содержит логику преобразования данных и обеспечивает совместимость форматов данных и протоколов взаимодействия
3. Интеграция уровня защиты от повреждений между внешней и внутренней системами, которая выполняется посредством настройки правил маршрутизации запросов на уровне API Gateway или через отдельный сервис маршрутизации
4. Тестирование и отладка работы уровня защиты от повреждений для обеспечения корректности преобразования данных и совместимости форматов взаимодействия.
Шаблон «База данных на сервис» (Database Per Service)
Основная рекомендация при переходе на микросервисы — предоставить каждому сервису собственное хранилище данных, чтобы не было сильных зависимостей на уровне данных. При этом имеется в виду именно логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же физическую базу данных, но в ней они должны взаимодействовать с отдельной схемой, коллекцией или таблицей.
Основанный на этих принципах паттерн Database Per Service повышает автономность микросервисов и уменьшает связь между командами, разрабатывающими отдельные сервисы.
Название паттерна
Шаблон “База данных на сервис” (Database Per Service).
Какую проблему решает
Шаблон “База данных на сервис” решает проблему масштабируемости и независимости микросервисов друг от друга. При разработке приложений на микросервисной архитектуре возникает необходимость хранения данных для каждого микросервиса. Использование общей базы данных может привести к проблемам масштабирования, так как все микросервисы будут зависеть от одной базы данных, что приведет к увеличению количества запросов и нагрузки на базу данных. Кроме того, разные микросервисы могут использовать разные технологии баз данных, что также может создать проблемы.
Краткое описание функциональности
Шаблон “База данных на сервис” предполагает создание отдельной базы данных для каждого микросервиса. Каждая база данных будет содержать только те данные, которые нужны для работы конкретного микросервиса. Таким образом, каждый микросервис будет иметь свою собственную базу данных, что обеспечит независимость микросервисов друг от друга и упростит их масштабирование.
В шаблоне “База данных на сервис” участвуют следующие сущности:
Микросервисы - приложения, которые разрабатываются на микросервисной архитектуре и требуют хранения данных.
Базы данных - отдельные базы данных, которые создаются для каждого микросервиса.
Пошаговая краткая реализация
Шаг 1. Определите необходимые микросервисы и их функциональность.
Шаг 2. Для каждого микросервиса создайте отдельную базу данных с необходимой схемой данных.
Шаг 3. Настройте микросервисы для работы с их собственными базами данных.
Шаг 4. Реализуйте механизмы синхронизации данных между разными базами данных, если это необходимо.
Шаг 5. Обеспечьте безопасность доступа к БД для каждого МС
Шаблон «API-композиция» (API Composition)
Шаблон Управления Данными
Этот шаблон является одним из возможных вариантов получения данных из нескольких сервисов после применения к ним паттерна Database Per Service. Он предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти. Паттерн можно рассматривать как вариант использования другого шаблона — API Gateway, о котором мы поговорим ниже.
Название паттерна: API-композиция
Какую проблему решает:
Шаблон API-композиция решает проблему повышения эффективности взаимодействия микросервисов в микросервисной архитектуре. Этот шаблон позволяет объединять несколько API-запросов в один, чтобы уменьшить количество обращений к сервисам и сократить время отклика.
Краткое описание функциональности:
Шаблон API-композиция позволяет создавать новый API-метод, который объединяет несколько запросов к различным микросервисам в единую операцию. Это может быть полезно, когда клиенту нужны данные из нескольких микросервисов для выполнения своих задач. Композитный метод позволяет клиенту получить все необходимые данные за один запрос, что уменьшает нагрузку на сервер и улучшает производительность.
Сущности, которые участвуют в паттерне:
- Клиент: использует композитный API-метод для получения данных из нескольких микросервисов.
- Композитный сервис: получает запрос от клиента и выполняет несколько запросов к различным микросервисам, чтобы собрать все необходимые данные и отправить их клиенту.
Пошаговая краткая реализация:
1. Определить, какие данные клиенту необходимо получить из различных микросервисов.
2. Создать композитный сервис, который будет выполнять необходимые запросы к микросервисам.
3. Определить формат запросов и ответов для каждого микросервиса, которые будут использоваться в композитном сервисе.
4. Создать новый API-метод в композитном сервисе, который будет объединять несколько запросов к микросервисам в единую операцию.
5. Настроить систему авторизации и аутентификации для композитного сервиса и микросервисов, чтобы обеспечить безопасность данных.
6. Тестирование и отладка композитного API-метода, чтобы убедиться в его работоспособности и эффективности.
Шаблон «Разделение команд и запросов» (Command Query Responsibility Segregation, CQRS)
Шаблон Управления Данными
Этот паттерн предлагает отделить изменение данных (Command) от чтения данных (Query). Шаблон CQRS имеет две формы: простую и расширенную.
В простой форме для чтения и записи используются отдельные модели ORM (Object-Relational Mapping), но общее хранилище данных.
В расширенной форме используются разные хранилища данных, оптимизированные для записи и чтения данных. Данные копируются из хранилища для записи в хранилище для чтения асинхронно. В результате хранилище для чтения отстает от хранилища для записи, но в конечном итоге является согласованным. Расширенный CQRS часто используется совместно с паттерном Event Sourcing
Название паттерна
Шаблон «Разделение команд и запросов» (Command Query Responsibility Segregation, CQRS) в микросервисной архитектуре.
Какую проблему решает
Шаблон CQRS помогает решить проблему неэффективности и неоптимальности при использовании традиционной модели CRUD (Create, Read, Update, Delete) для работы с данными в микросервисной архитектуре.
Краткое описание функциональности
CQRS предполагает разделение модели данных на две части: часть, которая отвечает только за команды (изменение данных), и часть, которая отвечает только за запросы (получение данных). Это позволяет создать более гибкую архитектуру, которая может лучше соответствовать конкретным потребностям бизнеса. Паттерн CQRS может быть реализован в виде отдельного сервиса или как часть каждого сервиса.
В паттерне CQRS участвуют следующие сущности:
- Команды - операции, которые изменяют данные в системе;
- Запросы - операции, которые запрашивают данные из системы;
- Модель команд - часть модели данных, которая содержит только команды;
- Модель запросов - часть модели данных, которая содержит только запросы;
- Компонент команд - сервис, который обрабатывает команды;
- Компонент запросов - сервис, который обрабатывает запросы.
Пошаговая краткая реализация :
Шаг 1: Определение команд и запросов
Первым шагом в реализации шаблона CQRS является определение команд и запросов, которые будут использоваться в системе. Команды используются для изменения состояния системы, а запросы для получения данных из системы.
Шаг 2: Создание отдельных сервисов для команд и запросов
Создайте два отдельных сервиса - один для команд, другой для запросов. Каждый сервис будет обрабатывать только определенный тип запросов.
Шаг 3: Разделение моделей данных
Создайте отдельные модели данных для каждого сервиса. Модель данных для сервиса команд будет содержать только те поля, которые необходимы для изменения состояния системы, а модель данных для сервиса запросов будет содержать только те поля, которые необходимы для получения данных из системы.
Шаг 4: Использование разных баз данных
Для хранения данных каждого сервиса используйте отдельную базу данных. База данных для сервиса команд будет содержать только данные, необходимые для изменения состояния системы, а база данных для сервиса запросов будет содержать только данные, необходимые для получения данных из системы.
Шаг 5: Реализация API для каждого сервиса
Реализуйте API для каждого сервиса. API для сервиса команд будет принимать запросы на изменение состояния системы, а API для сервиса запросов будет принимать запросы на получение данных из системы.
Шаг 6: Реализация механизма синхронизации данных
Реализуйте механизм синхронизации данных между базами данных сервисов команд и запросов. Этот механизм может быть реализован с помощью событийной модели, при которой сервис команд генерирует событие при изменении состояния системы, а сервис запросов подписывается на эти события и обновляет свою базу данных соответствующим образом.
Шаг 7: Тестирование системы
Протестируйте систему, убедившись в том, что сервисы команд и запросов работают корректно, и данные в обоих базах данных синхронизированы.
Шаг 8: Масштабирование системы
При необходимости можно масштабировать систему, добавив дополнительные экземпляры сервисов команд и запросов и использовав балансировку нагрузки для распределения запросов между ними.
Шаблон «Поиск событий» (Event Sourcing)
Шаблон Управления Данными
В традиционных базах данных объект с текущим состоянием сохраняется напрямую. При использовании шаблона Event Sourcing вместо объектов сохраняются события, изменяющие их состояния. Итоговое состояние объекта можно получить путем повторной обработки серии событий, пришедших за определенное время. Различные службы могут воспроизводить события из хранилища событий, чтобы вычислить соответствующее состояние своих хранилищ данных. Для реализации хранилища событий обычно применяется шаблон CQRS.
Название паттерна:
Поиск событий (Event Sourcing).
Какую проблему решает:
Шаблон “Поиск событий” решает проблему хранения изменений состояний объектов в приложении. Вместо хранения только текущего состояния объектов, как это делается в традиционных системах, данный шаблон хранит историю всех изменений, которые произошли с объектом. Это позволяет в будущем восстановить состояние объекта на любой момент времени и понять, как оно достигалось.
Краткое описание функциональности:
Шаблон “Поиск событий” заключается в том, что все изменения состояний объектов записываются в виде событий, которые сохраняются в постоянное хранилище (например, базу данных). Для каждого объекта создается свой поток событий, который содержит все события, связанные с этим объектом.
Когда требуется восстановить состояние объекта на определенный момент времени, происходит воспроизведение всех событий из потока до нужного момента. При этом происходит изменение состояния объекта в соответствии с каждым событием.
Сущности, которые участвуют в паттерне:
* Объекты, состояние которых нужно отслеживать
* События, которые описывают изменения состояний объектов
* Потоки событий для каждого объекта
* Постоянное хранилище, в котором сохраняются события
Пошаговая краткая реализация:
1. Определить объекты, состояние которых нужно отслеживать.
2. Определить события, которые будут описывать изменения состояний объектов.
3. Создать поток событий для каждого объекта.
4. Создать постоянное хранилище (например, базу данных), в котором будут сохраняться события.
5. Написать код для добавления новых событий в потоки событий при изменении состояний объектов.
6. Написать код для воспроизведения событий из потоков и изменения состояний объектов в соответствии с этими событиями при запросе на восстановление состояния на определенный момент времени.
Шаблон «Сага» (Saga)
Шаблон Управления Данными
Сага — это механизм, обеспечивающий согласованность данных в микросервисах без применения распределенных транзакций.Этот паттерн предназначен для управления распределенными транзакциями в микросервисной архитектуре, где применение традиционного протокола двухфазной фиксации транзакций (Two-phase commit protocol, 2PC) становится трудноосуществимым.
При использовании паттерна каждая локальная транзакция обновляет данные в хранилище в рамках одного микросервиса и публикует событие или сообщение, которые, в свою очередь, запускают следующую локальную транзакцию и так далее. Если локальная транзакция завершается с ошибкой, выполняется серия компенсирующих транзакций, которые отменяют изменения предыдущих транзакций.
Для каждой системной команды, которой надо обновлять данные в нескольких сервисах, создается некоторая сага. Сага представляет из себя некоторый «чек-лист», состоящий из последовательных локальных ACID-транзакций, каждая из которых обновляет данные в одном сервисе. Для обработки сбоев применяется компенсирующая транзакция. Такие транзакции выполняются в случае сбоя на всех сервисах, на которых локальные транзакции выполнились успешно.
Типов транзакций в саге четыре:
1. Компенсирующая сага: этот тип саги используется, когда необходимо отменить изменения, внесенные локальной транзакцией, в случае, если последующие транзакции завершатся неудачей. Компенсирующая сага позволяет обеспечить консистентность данных в системе, даже если возникнут ошибки.
2. Компенсируемая сага: это транзакция, которую необходимо компенсировать (отменить) в случае, если последующие транзакции завершаются неудачей. Это позволяет обеспечить целостность данных в системе и избежать ошибок, которые могут возникнуть при повторной попытке выполнения транзакции.
3. Поворотная сага: это транзакция, которая определяет успешность всей саги. Если поворотная сага выполняется успешно, то сага гарантированно дойдет до конца. Если поворотная сага не выполнится успешно, то сага будет прервана и начнется процесс отката изменений.
4. Повторяемая сага: это транзакция, которая идет после поворотной саги и гарантированно завершается успехом. Это позволяет обеспечить целостность данных и гарантировать, что изменения будут успешно применены.
Для координации транзакций существует два основных способа:
* Хореография. Децентрализованная координация, при которой каждый микросервис прослушивает события/сообщения другого микросервиса и решает, следует предпринять действие или нет.
* Оркестровка. Централизованная координация, при которой отдельный компонент (оркестратор) сообщает микросервисам, какое действие необходимо выполнить далее.
Название паттерна
Шаблон “Сага” (Saga)
Какую проблему решает
Шаблон “Сага” решает проблему поддержки целостности данных при выполнении транзакций, которые включают несколько микросервисов. Он позволяет обеспечить координацию между сервисами и восстановление системы в случае сбоя.
Краткое описание функциональности
Шаблон “Сага” представляет собой набор транзакций, которые выполняются последовательно и атомарно. Каждая транзакция включает в себя обращения к одному или нескольким микросервисам и может привести к изменению данных в нескольких сервисах. При выполнении транзакции каждый сервис выполняет свою часть работы и сообщает о своем состоянии в центральный узел, который координирует весь процесс. Если какой-то сервис не может выполнить свою часть работы, сага откатывает все предыдущие изменения.
Сущности, которые участвуют в паттерне
* Сервисы, которые взаимодействуют друг с другом для выполнения транзакции.
* Центральный узел (Coordination Service), который координирует выполнение транзакции и обеспечивает ее целостность.
* Сага лог (Saga Log), который используется для хранения состояния транзакции.
Пошаговая краткая реализация
Шаг 1: Определить границы саги и транзакций, которые должны быть выполнены для достижения цели.
Шаг 2: Создать Saga Log и определить формат сообщений, которые будут записываться в него.
Шаг 3: Реализовать координационный сервис, который будет управлять выполнением транзакций и обновлять Saga Log.
Шаг 4: Создать обработчики для каждого сервиса, который будет участвовать в транзакции. Обработчики должны выполнять соответствующие действия и отправлять сообщения о выполнении своей части работы в координационный сервис.
Шаг 5: Реализовать механизм отката транзакций в случае сбоя. При возникновении ошибки координационный сервис должен откатить все изменения, сделанные в рамках текущей транзакции.
Шаблон «API-шлюз» (API Gateway)
Паттерн коммуникации микросервисов
Этот паттерн основан на применении шлюза, который находится между клиентским приложением и микросервисами, обеспечивая единую точку входа для клиента.
Обеспечивает единую точку входа для клиента. Общается с клиентом по REST , но с сервисами может общаться любым протоколом.
- Gateway Routing. Шлюз используется как обратный Proxy, перенаправляющий запросы клиента на соответствующий сервис.
- Gateway Aggregation. Шлюз используется для разветвления клиентского запроса на несколько микросервисов и возвращения агрегированных ответов клиенту.
- Gateway Offloading. Шлюз решает сквозные задачи, которые являются общими для сервисов: аутентификация, авторизация, SSL, ведение журналов и так далее.
Название паттерна
Шаблон “API-шлюз” (API Gateway).
Какую проблему решает
Шаблон “API-шлюз” решает проблему управления входящим трафиком в микросервисной архитектуре. Когда клиенты обращаются к различным микросервисам напрямую, управление трафиком может стать сложной задачей. Шаблон “API-шлюз” позволяет упростить эту задачу, предоставляя единый точку входа для клиентов, через которую они могут получать доступ к микросервисам.
Краткое описание функциональности
Шаблон “API-шлюз” представляет собой слой между клиентом и микросервисами, который обрабатывает все запросы, поступающие от клиентов. Он выполняет следующие функции:
* Проксирование запросов от клиентов к микросервисам.
* Маршрутизация запросов к соответствующим микросервисам на основе пути запроса или других метаданных запроса.
* Аутентификация и авторизация клиентов.
* Ограничение скорости запросов от клиентов.
* Кеширование запросов для уменьшения нагрузки на микросервисы.
* Обработка ошибок и исключений.
* Логирование запросов и ответов.
В шаблоне “API-шлюз” участвуют следующие сущности:
* Клиенты, которые отправляют запросы к API-шлюзу.
* API-шлюз, который обрабатывает запросы от клиентов и маршрутизирует их к соответствующим микросервисам.
* Микросервисы, которые обрабатывают запросы от API-шлюза и возвращают ответы клиентам.
Реализация шаблона “API-шлюз” может быть выполнена следующим образом:
- Определите точку входа для клиентов. Это может быть URL-адрес или доменное имя, которое клиенты будут использовать для отправки запросов к API-шлюзу.
- Настройте API-шлюз для проксирования запросов от клиентов к соответствующим микросервисам. Для этого вы можете использовать инструменты, такие как NGINX или Apache.
- Настройте маршрутизацию запросов. Маршрутизация может осуществляться на основе пути запроса или других метаданных запроса, таких как заголовки.
- Реализуйте аутентификацию и авторизацию клиентов. Вы можете использовать стандарты аутентификации, такие как OAuth или OpenID Connect.
- Настройте ограничение скорости запросов от клиентов. Это может быть выполнено на уровне API-шлюза, чтобы предотвратить перегрузку микросервисов.
- Настройте кеширование запросов. Кеширование может уменьшить нагрузку на микросервисы, повторно используя ответы на запросы, которые были выполнены ранее.
- Реализуйте обработку ошибок и исключений. Это может включать в себя логирование ошибок и исключений, а также возвращение клиенту соответствующего кода ошибки.
- Настройте логирование запросов и ответов. Это может помочь в диагностике проблем, а также в управлении и мониторинге API-шлюза и микросервисов.
Шаблон «Бэкенды для фронтендов» (Backends for Frontends, BFF)
Паттерн коммуникации микросервисов
Этот паттерн является вариантом реализации(расширения) шаблона API Gateway. Он также обеспечивает дополнительный уровень между микросервисами и клиентами, но вместо одной точки входа вводит несколько шлюзов для каждого типа клиента: Web, Mobile, Desktop и так далее.
Название паттерна: Backends for Frontends (BFF).
Какую проблему решает: BFF решает проблему различных требований к API, которые могут возникать у различных клиентов, таких как веб-приложения, мобильные приложения, настольные приложения и т.д.
Краткое описание функциональности: BFF предоставляет дополнительный уровень между микросервисами и клиентами, который позволяет каждому типу клиента использовать свой собственный API Gateway для доступа к микросервисам. Это позволяет оптимизировать API для каждого типа клиента, улучшить производительность и обеспечить более гибкую архитектуру.
Сущности, которые участвуют в паттерне:
- Клиенты (Web, Mobile, Desktop и т.д.)
- API Gateway для каждого типа клиента
- Backends for Frontends (BFF)
- Микросервисы
Пошаговая краткая реализация:
- Определить требования каждого типа клиента к API.
- Создать отдельные API Gateway для каждого типа клиента, которые будут использовать BFF для доступа к микросервисам.
- Разработать BFF для каждого типа клиента, который будет оптимизировать API для этого типа клиента и обеспечивать доступ к соответствующим микросервисам.
- Разработать микросервисы, которые будут использоваться BFF для доступа к данным и бизнес-логике.
- Настроить связь между BFF и API Gateway для каждого типа клиента.
- Протестировать и оптимизировать архитектуру.
Зачем нужны паттерны обнаружения сервисов в микросервисной архитектуре?
Эта группа шаблонов описывает методы, которые могут использовать клиентские приложения для определения местонахождения нужных им сервисов. Это особенно важно в микросервисных приложениях, так как они работают в виртуализированных и контейнерных средах, где количество экземпляров сервисов и их расположение изменяются динамически.
Ключевым компонентом обнаружения микросервисов выступает реестр сервисов (Service Registry) — база данных с информацией о расположении сервисных экземпляров. Когда экземпляры запускаются и останавливаются, информация в реестре обновляется. Но взаимодействовать с реестром сервисов можно двумя путями, которые и легли в основу описанных ниже шаблонов.
Паттерны обнаружения сервисов в микросервисной архитектуре нужны для облегчения процесса поиска и доступа к микросервисам в распределенной системе. Они позволяют автоматически определять доступные сервисы и их адреса, что упрощает развертывание, масштабирование и управление микросервисами. Без этих паттернов разработчики должны были бы ручным образом настраивать соединения между сервисами, что может быть трудоемким и неэффективным в больших и сложных системах.
Шаблон «Обнаружение сервисов на стороне клиента» (Client-Side Service Discovery)
Паттерны обнаружения сервисов
В этом случае сервисы и их клиенты напрямую взаимодействуют с реестром.
Последовательность шагов следующая:
- Экземпляр сервиса обращается к API реестра, чтобы зарегистрировать свое сетевое местоположение. Он также может предоставить URL-адрес для проверки своей работоспособности (Health Check), который будет использоваться для продления срока его регистрации в реестре.
- Клиент самостоятельно обращается к реестру сервисов, чтобы получить список экземпляров сервисов. Для улучшения производительности клиент может кэшировать экземпляры сервиса.
- Клиент использует алгоритм балансировки нагрузки, циклический или случайный, чтобы выбрать конкретный экземпляр сервиса и отправить ему запрос.
Ключевое преимущество обнаружения сервисов на стороне клиента — его независимость от используемой платформы развертывания. Например, если часть ваших сервисов развернута на K8s, а остальные работают в устаревшей среде, то обнаружение на уровне приложения будет лучшим вариантом, так как серверное решение на базе Kubernetes не будет совместимо со всеми сервисами.
Название паттерна:
Шаблон «Обнаружение сервисов на стороне клиента» (Client-Side Service Discovery).
Какую проблему решает:
Данный паттерн решает проблему поиска и доступа к микросервисам в распределенной системе, облегчая процесс развертывания, масштабирования и управления микросервисами.
Краткое описание функциональности:
Паттерн «Обнаружение сервисов на стороне клиента» заключается в том, что клиентский компонент самостоятельно обнаруживает доступные сервисы и их адреса, не прибегая к централизованному сервису обнаружения. Для этого клиентский компонент использует информацию о доступных сервисах, которая хранится в некотором централизованном хранилище (например, в конфигурационном файле или в базе данных). При необходимости клиентский компонент может обновлять информацию о доступных сервисах, например, при добавлении или удалении сервисов из системы.
Сущности, которые участвуют в паттерне:
- Клиентский компонент – компонент, который использует сервисы в распределенной системе.
- Централизованное хранилище – хранилище информации о доступных сервисах в системе.
Пошаговая краткая реализация:
Шаг 1. Создание централизованного хранилища информации о доступных сервисах (например, конфигурационный файл или база данных).
Шаг 2. Настройка клиентского компонента на использование паттерна «Обнаружение сервисов на стороне клиента».
Шаг 3. Реализация функционала обновления информации о доступных сервисах в централизованном хранилище (например, при добавлении или удалении сервисов из системы).
Шаг 4. Реализация функционала обнаружения доступных сервисов клиентским компонентом на основе информации из централизованного хранилища.
Шаг 5. Тестирование и отладка реализованного функционала.
Шаблон «Обнаружение сервисов на стороне сервера» (Server-Side Service Discovery)
Паттерны обнаружения сервисов
В этом случае за регистрацию, обнаружение сервисов и маршрутизацию запросов отвечает инфраструктура развертывания.
ПРЕДПОЧТИТЕЛЕН.
Последовательность шагов следующая:
- Регистратор, который обычно является частью платформы развертывания, прописывает все экземпляры сервисов в реестре сервисов. По каждому экземпляру сохраняется DNS-имя и виртуальный IP-адрес (VIP).
- Вместо того чтобы обращаться к реестру напрямую, клиент делает запрос по DNS-имени сервиса. Запрос поступает в маршрутизатор, являющийся частью платформы развертывания.
- Маршрутизатор обращается к реестру сервисов для получения сетевого расположения экземпляров нужного сервиса.
- Маршрутизатор применяет балансировку нагрузки, чтобы выбрать конкретный экземпляр сервиса и отправить ему запрос.
Все современные платформы развертывания, включая Docker, Kubernetes и другие, как правило, имеют встроенный реестр и механизмы обнаружения сервисов.
Основное преимущество паттерна состоит в том, что всеми аспектами обнаружения сервисов занимается сама платформа. Дополнительный код на стороне клиента или сервисов не требуется. Благодаря этому достигается независимость от используемых в приложении языков программирования и фреймворков.
Название паттерна
“Обнаружение сервисов на стороне сервера” (Server-Side Service Discovery).
Какую проблему решает
В микросервисной архитектуре каждый сервис может иметь свою собственную базу данных, свою схему данных, а также может запускаться и останавливаться динамически. Это приводит к необходимости динамического обнаружения сервисов другими сервисами. Шаблон “Обнаружение сервисов на стороне сервера” решает эту проблему, предоставляя механизм обнаружения сервисов на стороне сервера.
Краткое описание функциональности
- Реестр сервисов: это централизованный реестр, который содержит информацию о доступных сервисах и их местоположении.
- Сервер обнаружения сервисов: это компонент, который отвечает за обработку запросов на обнаружение сервисов от клиентских сервисов и предоставляет информацию о доступных сервисах из реестра сервисов.
В шаблоне “Обнаружение сервисов на стороне сервера” участвуют следующие сущности:
* Клиентский сервис: это сервис, который хочет найти другие сервисы для выполнения своей функциональности.
* Сервер обнаружения сервисов: это компонент, который отвечает за обработку запросов на обнаружение сервисов от клиентских сервисов и предоставляет информацию о доступных сервисах из реестра сервисов.
* Реестр сервисов: это централизованный реестр, который содержит информацию о доступных сервисах и их местоположении.
Реализация шаблона “Обнаружение сервисов на стороне сервера” может быть выполнена в следующих шагах:
Шаг 1: Создать реестр сервисов, который будет хранить информацию о доступных сервисах и их местоположении.
Шаг 2: Каждый сервис должен зарегистрироваться в реестре сервисов при запуске, предоставив информацию о себе, например, имя, адрес и порт, по которому можно получить доступ к сервису. Реестр сервисов должен сохранить эту информацию.
Шаг 3: Клиентский сервис отправляет запрос на сервер обнаружения сервисов, указав имя требуемого сервиса.
Шаг 4: Сервер обнаружения сервисов проверяет реестр сервисов и возвращает клиентскому сервису информацию о местоположении требуемого сервиса, например, его адрес и порт.
Шаг 5: Клиентский сервис использует полученную информацию для установки соединения с требуемым сервисом и выполнения своей функциональности.
