Создайте отдельные серверные службы, которые будут использоваться конкретными внешними приложениями или интерфейсами. Эта схема полезна в тех случаях, когда нужно избежать настройки одной серверной службы под несколько интерфейсов. Этот шаблон впервые описал Сэм Ньюмен (Sam Newman).
Контекст и проблема
Предположим, что изначально создавалось приложение с классическим веб-интерфейсом. Как обычно, параллельно разрабатывается серверная служба, которая предоставляет возможности, необходимые именно этому пользовательскому интерфейсу. По мере роста числа пользователей создается мобильное приложение, которое должно взаимодействовать с той же серверной службой. Теперь серверная служба становится универсальной и обслуживает потребности сразу двух интерфейсов: классического для настольных компьютеров и нового для мобильных устройств.
Но при этом возможности мобильных устройств существенно отличаются от возможностей браузеров на компьютерах. У них другие размеры экранов, производительность и ограничения по отображению информации. Это означает, что отличаются и требования к серверной службе для мобильного приложения и веб-интерфейса.
Такие отличия приводят к тому, что требования к серверной части становятся противоречивыми. Разработчику приходится часто и существенно изменять систему, чтобы поддерживать актуальность серверной службы как для веб-интерфейса, так и для мобильного приложения. При этом над интерфейсами часто работают разные команды разработчиков, и в результате серверная части становится узким местом в процессе разработки. Противоречивые требования к обновлениям и необходимость поддерживать работоспособность обоих интерфейсов вынуждают тратить слишком много усилий на этот единый ресурс.
По мере увеличения трудоемкости разработки серверной службы иногда создается даже отдельная группа разработчиков для обслуживания этой серверной службы и управления ею. Все эти факторы приводят к разрыву связей между разработчиками интерфейсной и серверной частей и полностью переносят на разработчиков серверной службы ответственность за выполнение несогласованных требований разработчиков интерфейсов. Но если разработчики одного из интерфейсов требуют внести изменения в серверную часть, эти изменения необходимо согласовать с другими командами разработки интерфейса, прежде чем реализовать их в серверной службе.
Решение
Создайте отдельную серверную часть для каждого пользовательского интерфейса. Точно настройте поведение и производительность каждой серверной части в соответствии с потребностями интерфейсной среды, не беспокоясь о влиянии других интерфейсных интерфейсов.
Поскольку каждая серверная часть работает только с одним интерфейсом, ее можно оптимизировать для этого интерфейса. В результате она станет менее крупной и менее громоздкой, а скорее всего и более быстрой, чем универсальная серверная часть, в которой пересекаются требования для всех интерфейсов. Каждая команда разработчиков интерфейса получает возможность автономно управлять требованиями к своей серверной части, и не зависит от проблем, связанных с разработкой единой серверной части. Это дает гибкость в выборе языков, последовательности выпусков, приоритетах рабочих нагрузок и интеграции функций для серверной части.
Дополнительные сведения см. в статье Pattern: Backends For Frontends (Схема отдельных серверных частей для каждого интерфейса).
Проблемы и рекомендации
- Оцените, сколько потребуется серверных служб.
- Если несколько разных интерфейсов (например, разные мобильные клиенты) будут создавать одинаковые запросы, оцените наиболее подходящий для них вариант: отдельная серверная часть для каждого интерфейса или единая серверная часть.
- Реализация этой схемы чаще всего приводит к дублированию кода в службах.
- Серверная служба, ориентированная на конкретный интерфейс, должна содержать только логику и поведение, имеющие отношение к этому клиенту. Общую бизнес-логику и другие глобальные компоненты следует реализовать в другой части приложения.
- Подумайте о том, как эта схема повлияет на распределение обязанностей в команде разработчиков.
- Оцените, сколько времени потребуется для ее реализации. Не приведет ли создание новой серверной службы к появлению технического долга, пока вы продолжаете поддерживать существующую универсальную серверную часть?
Когда следует использовать этот шаблон
Используйте этот шаблон в следующих случаях:
- если поддержка единой или универсальной серверной службы приводит к существенным издержкам на разработку;
- если вы хотите оптимизировать серверную часть под требования конкретных интерфейсов;
- если в универсальную серверную часть вносятся изменения для поддержки нескольких интерфейсов;
- Язык программирования лучше подходит для серверной части определенного пользовательского интерфейса, но не для всех пользовательских интерфейсов.
Эту схему не стоит применять в следующих случаях:
- если интерфейсы создают одинаковые или очень похожие запросы к серверной части;
- если существует только один интерфейс для взаимодействия с серверной частью.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон серверных компонентов для интерфейсов можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Наличие отдельных служб, которые являются эксклюзивными для определенного интерфейсного интерфейса, содержит сбои, поэтому доступность одного клиента может не повлиять на доступность доступа другого клиента. Кроме того, при обращении с различными клиентами можно определить приоритеты усилий по надежности на основе ожидаемых шаблонов доступа клиентов. - Критически важные потоки RE:02 - RE:07 Самосохранение |
| Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки. | Из-за разделения служб, введенного в этом шаблоне, безопасность и авторизация на уровне служб, поддерживающего один клиент, можно адаптировать к функциональным возможностям, необходимым для этого клиента, потенциально уменьшая область поверхности API и боковое перемещение между различными серверными службами, которые могут предоставлять различные возможности. - Сегментация SE:04 - РЕСУРСЫ SE:08 Для защиты |
| Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | Разделение серверной части позволяет оптимизировать способы, которые могут быть недоступны с общим уровнем служб. При обработке отдельных клиентов по-разному можно оптимизировать производительность для ограничений и функциональных возможностей конкретного клиента. - Планирование емкости PE:02 - Критически важные потоки PE:09 |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.