Шаблон серверных элементов для интерфейсов

В этом шаблоне описывается, как отделить бэкэнд-службы от фронтенд-реализаций, чтобы адаптировать взаимодействия для различных клиентских интерфейсов. Этот шаблон полезен, если вы хотите избежать настройки серверной части, которая обслуживает несколько интерфейсов. Этот шаблон основан на паттерне Backend for Frontends Сэмом Ньюманом.

Контекст и проблема

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

На схеме есть два раздела: серверная служба и классический клиент и мобильный клиент. Две двусторонние стрелки указывают от серверной службы как на настольный клиент, так и на мобильный клиент.

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

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

Решение

Введите новый слой, который обрабатывает только требования, относящиеся к интерфейсу. Этот уровень, известный как служба серверной части для внешнего интерфейса (BFF), находится между интерфейсным клиентом и серверной службой. Если приложение поддерживает несколько интерфейсов, таких как веб-интерфейс и мобильное приложение, создайте службу BFF для каждого интерфейса.

Этот шаблон настраивает интерфейс клиента для определенного интерфейса без влияния на другие интерфейсы. Она также оптимизирует производительность в соответствии с потребностями интерфейсной среды. Так как каждая служба BFF меньше и менее сложна, чем общая серверная служба, она может упростить управление приложением.

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

Многие службы BFF традиционно зависят от REST API, но реализации GraphQL появляются в качестве альтернативы. При использовании GraphQL механизм запроса устраняет необходимость отдельного уровня BFF, так как позволяет клиентам запрашивать необходимые данные без использования предопределенных конечных точек.

На схеме показаны три раздела. Первый раздел состоит из классического клиента и мобильного клиента. Второй раздел состоит из службы BFF классического клиента и службы BFF мобильного клиента. В настольном клиенте есть сплошная стрелка, указывающая на службу BFF настольного клиента. Мобильный клиент имеет сплошную стрелку, которая указывает на службу BFF мобильного клиента. Каждая служба BFF имеет пунктирную стрелку, указывающую на раздел серверной службы.

Дополнительные сведения см. в статье Backends for Frontends pattern by Sam Newman.

Проблемы и рекомендации

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

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

• Если разные интерфейсы выполняют одни и те же запросы, оцените, можно ли объединить запросы в одну службу BFF. Совместное использование одной службы BFF между несколькими интерфейсами может привести к разным требованиям для каждого клиента, что может усложнить рост и поддержку службы BFF.

  Дублирование кода является вероятным результатом этого шаблона. Оцените компромисс между дублированием кода и более подходящим интерфейсом для каждого клиента.

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

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

• Оцените, требуется ли этот шаблон. Например, если в вашей организации используется GraphQL с резолверами, специфичными для интерфейса, службы BFF могут не добавлять ценность вашим приложениям.

  Другой сценарий — это приложение, которое объединяет шлюз API с микрослужбами. Этот подход может быть достаточно для некоторых сценариев, когда службы BFF обычно рекомендуются.

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

• Для обслуживания общей или общедоступной серверной службы требуются значительные затраты на разработку.

• Вы хотите оптимизировать серверную часть для требований определенных клиентских интерфейсов.

• Вы настраиваете серверную часть общего назначения для размещения нескольких интерфейсов.

• Язык программирования лучше подходит для серверной части определенного пользовательского интерфейса, но не для всех пользовательских интерфейсов.

Этот шаблон может быть не подходит, если:

• Интерфейсы выполняют те же или аналогичные запросы к серверной части.

• Только один интерфейс взаимодействует с серверной частью.

Проектирование рабочей нагрузки

Оцените, как использовать архитектурный шаблон Backend for Frontend в проектировании загрузки для учета целей и принципов, описанных в столпах Azure Well-Architected Framework. В следующей таблице приведены рекомендации по использованию этого шаблона для целей каждого компонента.

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и гарантировать, что она восстанавливается до полнофункционального состояния после сбоя.	При изоляции служб в определённом внешнем интерфейсе сдерживаются сбои. Доступность одного клиента не влияет на доступность доступа другого клиента. При обращении с различными клиентами можно определить приоритеты усилий по надежности на основе ожидаемых шаблонов доступа клиентов. - Критически важные потоки RE:02 - RE:07 Самосохранение
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки.	Разделение служб, введенное в этом шаблоне, позволяет настраивать безопасность и авторизацию на уровне служб для конкретных потребностей каждого клиента. Этот подход может уменьшить область поверхности API и ограничить боковое перемещение между внутренними серверами, которые могут предоставлять различные возможности. - Сегментация SE:04 - РЕСУРСЫ SE:08 Для защиты
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Разделение серверной части позволяет оптимизировать способы, которые могут быть недоступны с общим уровнем служб. При обработке отдельных клиентов по-разному можно оптимизировать производительность для ограничений и функциональных возможностей конкретного клиента. - Планирование емкости PE:02 - Критически важные потоки PE:09

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Пример

В этом примере демонстрируется вариант использования шаблона, в котором два разных клиентских приложения, мобильное приложение и классическое приложение взаимодействуют с управлением API Azure (шлюз плоскости данных). Этот шлюз служит слоем абстракции и управляет общими перекрестными проблемами, такими как:

• Авторизация. Гарантирует, что только проверенные личности с соответствующими маркерами доступа могут вызывать защищенные ресурсы, используя управление API с идентификатором Microsoft Entra ID.

• Контроль. Записывает и отправляет сведения о запросах и ответах в Azure Monitor в целях наблюдения.

• Кэширование запросов. Оптимизирует повторяющиеся запросы, обслуживая ответы из кэша с помощью встроенных функций управления API.

• Маршрутизация и агрегирование. Направляет входящие запросы соответствующим службам BFF.

Каждый клиент имеет выделенную службу BFF, выполняющуюся в качестве функции Azure, которая служит посредником между шлюзом и базовыми микрослужбами. Эти клиентские службы BFF обеспечивают специализированный интерфейс для разбиения на страницы и других функций. Мобильное приложение определяет эффективность пропускной способности и использует преимущества кэширования для повышения производительности. В отличие от этого, настольное приложение получает несколько страниц в одном запросе, что создаёт более погружающий пользовательский опыт.

Схема структурирована в четырех разделах, которые иллюстрируют поток запросов, проверки подлинности, мониторинга и обработки для конкретного клиента. Два клиентских устройства инициируют запросы: мобильное приложение, оптимизированное для эффективного взаимодействия с пропускной способностью, и веб-браузер, предоставляющий полностью функциональный интерфейс. Стрелки расширяются от обоих устройств к центральной точке входа, которая является шлюзом управления API, чтобы указать, что все запросы должны проходить через этот уровень. Во второй секции, заключенной в прямоугольник с пунктирной линией, архитектура делится на две горизонтальные группы. Левая группа представляет управление API, которое обрабатывает входящие запросы и определяет способ их обработки. Из этого шлюза плоскости данных выходят наружу две стрелки. Одна стрелка указывает вверх на идентификатор Microsoft Entra, который управляет авторизацией. Другая стрелка указывает вниз на Azure Monitor, которая отвечает за ведение журнала и наблюдаемость. Стрелка возвращается от шлюза к мобильному клиенту, что означает кэшированный ответ при повторении идентичного запроса, что снижает ненужную обработку. Группа справа внутри прямоугольника с пунктирной линией сосредотачивается на настройке ответов серверной части в зависимости от типа клиента, который отправляет запрос. Он включает два отдельных клиента архитектуры backend-for-frontend, оба размещены с использованием службы Azure Functions для бессерверных вычислений. Один из них предназначен для мобильного клиента, а другой — для классического клиента. Две стрелки простираются от шлюза к клиентам серверной части для внешних интерфейсов, иллюстрируют, что каждый входящий запрос перенаправляется на соответствующую службу в зависимости от типа клиента. Помимо этого слоя, дефисированные стрелки расширяют и подключают внутренние клиенты для внешнего интерфейса к различным микрослужбам, которые обрабатывают фактическую бизнес-логику. На изображении показан поток слева направо, где запросы клиентов перемещаются с мобильных и веб-клиентов на шлюз. Этот шлюз обрабатывает каждый запрос при делегировании проверки подлинности поставщику удостоверений и ведения журнала вниз в службу мониторинга. Оттуда он направляет запросы на соответствующий серверный клиент для внешнего интерфейса на основе того, исходит ли запрос от мобильного или классического клиента. Наконец, каждый клиент интерфейса для серверной части передает запрос в специализированные микрослужбы, которые выполняют необходимую бизнес-логику и возвращают требуемый ответ. Если кэшированный ответ доступен, шлюз перехватывает запрос и отправляет сохраненный ответ непосредственно в мобильный клиент, что предотвращает избыточность обработки.

Поток A для первого запроса страницы от клиента мобильного приложения

1. Мобильный клиент GET отправляет запрос на страницу 1, включая токен OAuth 2.0 в заголовке авторизации.

2. Запрос достигает шлюза управления API, который перехватывает его и:

   1. Проверяет состояние авторизации. Управление API реализует многоуровневую защиту, поэтому проверяет действительность маркера доступа.

   2. Транслирует активность запроса в виде логов в Azure Monitor. Сведения о запросе записываются для аудита и мониторинга.

3. Политики применяются, а затем управление API направляет запрос в службу azure function mobile BFF.

4. Затем служба мобильного BFF функции Azure взаимодействует с необходимыми микросервисами, чтобы получить единичную страницу и обработать запрошенные данные, обеспечивая лёгкий пользовательский опыт.

5. Ответ возвращается клиенту.

Поток B для первого кэшированного запроса страницы от мобильного клиента

1. Мобильный клиент снова отправляет тот же GET запрос на страницу 1 , включая маркер OAuth 2.0 в заголовке авторизации.

2. Шлюз управления API распознает, что этот запрос был выполнен до и:

   1. Политики применяются. Затем шлюз определяет кэшированный ответ, соответствующий параметрам запроса.

   2. Возвращает кэшированный ответ немедленно. Этот быстрый ответ устраняет необходимость пересылать запрос в мобильную службу BFF функций Azure.

Flow C для первого запроса от настольного клиента

1. Настольный клиент отправляет GET запрос в первый раз, включая токен OAuth 2.0 в заголовке авторизации.

2. Запрос достигает шлюза управления API, где обрабатываются перекрестные проблемы.

   1. Авторизация: Проверка токена всегда требуется.

   2. Передача активности запроса: Сведения о запросе записываются для наблюдаемости.

3. После применения всех политик управление API направляет запрос на службу BFF рабочего стола функций Azure, которая обрабатывает обработку приложения с большим объемом данных. Настольная служба BFF агрегирует несколько запросов, используя базовые вызовы микрослужб, прежде чем ответить клиенту многостраничным ответом.

Дизайн

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

• Управление API служит прокси-сервером между клиентами и службами BFF, которые устанавливают периметр. Управление API настроено с помощью политик для проверки веб-токенов JSON и отклоняет запросы, которые не имеют маркера или содержат недопустимые утверждения для целевой службы BFF. Он также передает все журналы действий в Azure Monitor.

• Azure Monitor работает в качестве централизованного решения для мониторинга. Он объединяет все журналы действий для обеспечения комплексной комплексной наблюдаемости.

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

Дальнейшие шаги

• Паттерн "Backends for Frontends" по Сэму Ньюману
• Проверка подлинности и авторизация api в Управление API
• Интеграция управления API с Application Insights

Связанные ресурсы

• Схема агрегирования на шлюзе
• Схема разгрузки шлюза
• Схема маршрутизации шлюза
• эталонная архитектура бессерверных веб-приложений