Знакомство
Сергей Громов
Lead Business Analyst
IT-специалист, имеющий обширный опыт работы в различных областях.
В IT пришел 30 лет назад как программист на языке «Assembler» и преподаватель программирования в ВУЗе. Затем ушел разработчиком в коммерческие структуры. Освоил несколько языков программирования, но больше всего привлекало проектирование баз и хранилищ данных.
На этом поприще дорос до позиции лида разработки, а затем резко сменил направление и ушел с головой в аналитику. Уже 17 лет являюсь аналитиком, т.к. молодость разработчиком окончательно не отпускает, то предпочитаю системный анализ.
Сейчас занимаю позицию ведущего системного аналитика в Рексофт. Участвую в сложных проектах как аналитик и архитектор, активно развиваю экспертизу системного анализа, разрабатываю обучающие курсы для молодых аналитиков.
О микросервисах
Преимущества
 |
Технологическая неоднородность |
|
Надежность |
|
Масштабирование |
|
Простота развертывания |
|
Согласованность рабочих процессов в организации |
|
Повторное использование |
Недостатки
 |
Опыт разработчика |
|
Технологическая перегрузка |
|
Стоимость |
|
Отчетность |
|
Мониторинг и устранение неполадок |
|
Безопасность |
|
Тестирование |
|
Время ожидания |
|
Согласованность данных |
Паттерны проектирования микросервисов
Основная цель — предоставить проверенные временем решения для таких задач, как разработка микросервисной архитектуры, организация взаимодействия микросервисов друг с другом, клиентскими приложениями, базами данных, обеспечение их отказоустойчивости.
Паттерны декомпозиции на микросервисы
Шаблон «Разбиение по бизнес-возможностям» (Decompose By Business Capability)
Один из наиболее известных способов разбиения на микросервисы — это определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них.
Бизнес-возможности представляют собой функции, которые будут доступны пользователям при работе с приложением.
Шаблон «Разбиение по поддоменам» (Domain-Driven Design, DDD)
DDD разбивает всю модель предметной области (домен) на поддомены. У каждого поддомена своя модель данных, область действия которой принято называть ограниченным контекстом (Bounded Context). Каждый микросервис будет разрабатываться внутри этого ограниченного контекста.
Основная задача при использовании DDD-подхода — подобрать поддомены и границы между ними так, чтобы они были максимально независимы друг от друга.
Паттерны рефакторинга для перехода на микросервисы
Шаблон «Душитель» (Strangler)
Этот шаблон означает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы. Настраивается маршрутизация запросов между устаревшим монолитом и микросервисами.
Когда очередная функциональность переносится из монолита в микросервисы, фасад перехватывает клиентский запрос и направляет его к микросервисам.
Шаблон «Уровень защиты от повреждений» (Anti-Corruption Layer)
Шаблон позволяет изолировать разные подсистемы, поместив между ними уровень защиты от повреждений. Этот уровень преобразует обмен данными между двумя системами, за счет чего одна система не изменяется, а в другой сохраняется структура и технологический подход.
Паттерны управления данными в микросервисной архитектуре
Шаблон «API-композиция» (API Composition)
Этот шаблон является одним из возможных вариантов получения данных из нескольких сервисов после применения к ним паттерна Database Per Service.
Он предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти.
Паттерн можно рассматривать как вариант использования другого шаблона — API Gateway, о котором мы поговорим ниже.
Шаблон «Разделение команд и запросов» (Command Query Responsibility Segregation, CQRS)
Этот паттерн предлагает отделить изменение данных (Command) от чтения данных (Query). Шаблон CQRS имеет две формы: простую и расширенную.
В простой форме для чтения и записи используются отдельные модели ORM (Object-Relational Mapping), но общее хранилище данных.
Шаблон «Выполнение распределенных транзакций» (Saga)
Паттерн Saga предлагает надежное решение для работы с распределенными транзакциями, обеспечивая согласованность данных при сохранении автономии ваших сервисов.
При использовании паттерна каждая локальная транзакция обновляет данные в хранилище в рамках одного микросервиса и публикует событие или сообщение, которые, в свою очередь, запускают следующую локальную транзакцию и так далее. Если локальная транзакция завершается с ошибкой, выполняется серия компенсирующих транзакций, которые отменяют изменения предыдущих транзакций.
| ОРКЕСТРОВКА | ХОРЕОГРАФИЯ | |
| Централизованная координация, при которой отдельный компонент (оркестратор) сообщает микросервисам, какое действие необходимо выполнить далее. | Децентрализованная координация, при которой каждый микросервис прослушивает события / сообщения другого микросервиса и решает, следует предпринять действие или нет. | |
 |
 |
Паттерны коммуникации микросервисов
Шаблон «API-шлюз» (API Gateway)
Этот паттерн основан на применении шлюза, который находится между клиентским приложением и микросервисами, обеспечивая единую точку входа для клиента.
Выступая в качестве единой точки входа для всех клиентских запросов, API-шлюз упрощает доступ к вашим микросервисам, обеспечивая бесшовное взаимодействие между клиентами и сервисами.
Шаблон «Бэкенды для фронтендов» (Backends for Frontends, BFF)
Этот паттерн является вариантом реализации шаблона API Gateway. Он также обеспечивает дополнительный уровень между микросервисами и клиентами, но вместо одной точки входа вводит несколько шлюзов для каждого типа клиента: Web, Mobile, Desktop и так далее.
Паттерны построения пользовательского интерфейса
Шаблон «Client-Side UI Composition» и «Server-Side Page Fragment Composition»
Как реализовать экран или страницу пользовательского интерфейса, отображающую данные из нескольких служб.
Паттерны повышения отказоустойчивости
Шаблон «Защита от каскадных сбоев» (Circuit Breaker)
Шаблон Circuit Breaker отслеживает сбои и предотвращает достижение запросов до неработающего сервиса, давая ему время для восстановления и защищая всю систему от полного отказа.
Паттерны мониторинга микросервисов
Шаблон «Распределенная трассировка» (Distributed Tracing)
Паттерн Distributed Tracing разработан для решения проблемы отслеживания распределенных транзакций.
Он предлагает назначать каждому внешнему запросу уникальный идентификатор (TraceId), который будет передаваться всем сервисам, участвующим в обработке запроса, и фиксироваться в журналах.
Шаблон «Проверка здоровья» (Health Check)
Паттерн Health Check API представляет собой механизм мониторинга, позволяющий в режиме реального времени получать информацию о состоянии отдельных сервисов в приложении на базе микросервисов.
Прочие паттерны
Шаблон «Корректное восстановление после ошибок» (Retry)
Этот шаблон предусматривает автоматическое повторение неудачной операции, увеличивая вероятность успешного выполнения и минимизируя влияние временных сбоев.
Шаблон Retry позволяет вашим сервисам корректно восстанавливаться после таких проблем, повышая общую стабильность системы.
