Шаблоны проектирования микрослужб

Архитектура микрослужб распределяет ответственность между независимыми службами. Эта независимость изменяет способ обработки следующих распространенных архитектурных проблем:

  • Обслуживание согласованности данных без распределенных транзакций
  • Управление обменом данными между службами
  • Изоляция сбоев, чтобы предотвратить их каскадирование
  • Устаревшая интеграция системы во время миграции

Шаблоны проектирования, приведенные в этой статье, напрямую решают эти проблемы. Каждый шаблон предназначен для конкретной проблемы, которая может возникнуть при проектировании, сборке и эксплуатации микрослужб.

Схема, показывающая шаблоны проектирования микрослужб и их связи.

Поток схемы начинается с клиентского приложения. Стрелка указывает от клиентского приложения на поле, представляющее приложение микрослужб. Вторая стрелка указывает от клиентского приложения на паттерн Strangler Fig. Из шаблона Strangler Fig исходят две стрелки. Одна стрелка указывает на поле приложения микрослужб, а другая стрелка указывает на прямоугольник, помеченный устаревшей системой в нижней части схемы. Поле приложения микрослужб включает в себя шаблоны проектирования и микрослужбы. В разделе, помеченном шлюзОМ API, стрелка указывает из шаблона разгрузки шлюза в шаблоны маршрутизации шлюза и агрегирования шлюза. Стрелка указывает от шаблона маршрутизации шлюза на микросервис для настольного компьютера. Стрелка указывает от шаблона агрегации шлюза на микросервис для мобильных устройств. Эти микрослужбы находятся в разделе, озаглавленном "Backends for Frontends". Стрелки указывают от этих микросервисов к другому микросервису под блоком с меткой Сайдкар. Стрелка от этой микрослужбы направлена к удаленной службе за пределами области приложения микрослужб. Стрелка от микросервиса для мобильных устройств к разделу, который содержит две коробки с меткой "служба". Стрелки указывают от каждой службы на шину событий, расположенную между ними. В другом разделе стрелка, проходящая через антикоррупционный слой, указывает от микросервиса на устаревшую систему за пределами приложения микросервисов.

Распространенные шаблоны проектирования

  • Антикоррупционный слой реализует фасадный или адаптерный слой между подсистемами, которые не используют одинаковую семантику. Этот шаблон преобразует запросы между подсистемами и предотвращает зависимости от устаревших систем или других служб, имеющих несовместимые модели домена, от ограничения структуры новой службы.

  • Бэкэнды для фронтэндов создают отдельные бэкенд-сервисы для различных типов клиентов, таких как десктоп и мобильные устройства. При таком подходе отдельная серверная служба не должна обрабатывать конфликтующие требования различных типов клиентов. Этот шаблон помогает упростить каждую микрослужбу, разделив проблемы, связанные с клиентом.

  • Переборка изолирует критически важные ресурсы, такие как пулы подключений, память и ЦП для каждой рабочей нагрузки или службы. Эта изоляция предотвращает использование всех ресурсов для одной рабочей нагрузки или одной службы. Этот шаблон повышает устойчивость рабочей нагрузки, препятствуя одной службе вызывать каскадные сбои.

  • Хореография позволяет каждой службе решать, когда и как обрабатывать бизнес-операцию, а не в зависимости от центрального оркестратора. Этот шаблон уменьшает связь между службами и поддерживает частые обновления или изменения служб.

  • Разделение ответственности запросов команд (CQRS) отделяет операции чтения от операций записи в отдельные модели данных. Этот шаблон повышает производительность, масштабируемость и безопасность в микрослужбах, где операции чтения и записи имеют различные требования к производительности или масштабированию.

  • Маршрутизация шлюза использует шлюз API в качестве обратного прокси-сервера для маршрутизации клиентских запросов в разные службы на основе запроса. Такой подход дает клиентам одну конечную точку вместо многих.

    Агрегирование шлюза использует шлюз для объединения нескольких клиентских запросов в один запрос. Такой подход снижает избыточность общения между клиентами и службами.

    Разгрузка шлюза централизует межсервисную функциональность, такую как завершение безопасного сокетного соединения (SSL), проверка подлинности, и ограничение скорости, в рамках шлюза, чтобы отдельные службы не должны были реализовывать эти задачи отдельно.

    Дополнительные сведения см. в разделе шлюзов API для микрослужб.

  • Saga управляет согласованностью данных в микрослужбах с независимыми хранилищами данных. Сага — это последовательность локальных транзакций, в которых каждая служба выполняет свою операцию и запускает следующий шаг. Если шаг завершается ошибкой, сага выполняет компенсирующие транзакции, чтобы отменить предыдущие изменения. Этот шаблон заменяет распределенные транзакции, которые часто нецелесообразны в архитектуре микрослужб.

  • Sidecar развертывает вспомогательные компоненты приложения в виде отдельного контейнера или процесса для обеспечения изоляции и инкапсуляции. Используйте этот шаблон для подключения общих функций, таких как ведение журнала, мониторинг и конфигурация сети, к службе без внедрения в код службы.

  • Strangler Fig поддерживает добавочную миграцию из устаревшей системы, постепенно заменив определенные компоненты функций новыми службами. Потребители продолжают использовать тот же интерфейс, не зная, что миграция происходит, пока не будет полностью заменена устаревшая система.

Вспомогательные шаблоны

Взаимодействие между службами описывает шаблоны повторных попыток и разбиения цепи для устойчивых вызовов между службами.

Полный каталог шаблонов облачного проектирования в Центре архитектуры Azure см. в шаблонах проектирования облака.

Дальнейшие действия