Поделиться через

Стили архитектуры

  • Статья

Стиль архитектуры — это семейство архитектур, обладающих общими характеристики. Например, часто используется n-уровневый стиль архитектуры. В последнее время все большую популярность приобретают архитектуры микрослужб. Для стилей архитектуры не требуется использовать определенные технологии, но некоторые технологии хорошо подходят для некоторых архитектур. Например, контейнеры естественным образом подходят для микрослужб.

Мы определили набор стилей архитектур, которые часто встречаются в облачных приложениях. В статье для каждого стиля содержится:

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

Краткий обзор стилей

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

n-уровневый

Логическая схема стиля архитектуры N-уровней.

N-уровневая архитектура — это стандартная архитектура для корпоративных приложений. Управление зависимостями осуществляется путем разделения приложения на слои, которые выполняют логические функции, такие как представление, бизнес-логику и доступ к данным. Слой может вызывать только те слои, которые расположены под ним. Но такая горизонтальная структура может быть недостатком. Из-за этого могут возникнуть трудности с внесением изменений в одной части приложения без затрагивания остальной его части. В результате частые обновления могут стать сложной задачей, замедляя добавление новых функций.

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

Интерфейс — очередь — рабочая роль

Логическая схема стиля архитектуры web-Queue-Worker.

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

Рабочая роль веб-очереди подходит для относительно простых доменов с некоторыми ресурсоемкими задачами. Как и n-уровневый стиль, эта архитектура довольно проста. Использование управляемых служб упрощает развертывание и операции. Но при использовании сложных доменов могут возникнуть трудности с управлением зависимостями. Внешний интерфейс и рабочая роль могут увеличиться и превратиться в монолитные компоненты, которые трудно обслуживать и обновлять. Как и в случае с n-уровневым стилем, это может уменьшить частоту обновлений и замедлить внедрение инноваций.

Микрослужбы

Логическая схема стиля архитектуры микрослужб.

Если в приложении используется более сложный домен, перейдите на архитектуру микрослужб. Приложение для микрослужб состоит из множества небольших независимых служб. Каждая служба реализует возможность единого бизнеса. Службы слабо связаны, а обмен данными осуществляется через контракты API.

Каждую службу может разработать небольшая сосредоточенная группа разработчиков. Отдельные службы можно развернуть без усиленной координации между командами, что способствует частым обновлениям. Архитектура микрослужб сложнее в разработке и управлении, чем n-уровневый стиль или рабочая роль веб-очереди. Для нее требуются современные средства разработки и культура разработки и операций DevOps. Но при правильном выполнении этот стиль может ускорить выпуски, внедрение инноваций и сделать архитектуру более устойчивой.

Управляемая событиями архитектура

Схема стиля архитектуры на основе событий.

В управляемых событиями архитектурах используется модель "публикация — подписка" (pub-sub), где производители публикуют события, а потребители подписываются на них. Производители не зависят от потребителей, а потребители не зависят друг от друга.

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

Большие данные и Большие вычисления

Логическая схема стиля архитектуры больших данных.

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

Стили архитектуры в качестве ограничений

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

Например, к ограничениям в микрослужбах относятся:

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

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

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

Выбор подходящего архитектурного стиля должен быть выполнен в идеале с консенсусом заинтересованных лиц с информированной рабочей нагрузкой. Сначала команда рабочей нагрузки должна определить характер проблемы, которая пытается решить. Затем они должны определять бизнес-драйверы и соответствующие характеристики архитектуры (также известные как нефункциональный требования), а затем определять приоритеты. Например, если им требуется более короткое время на рынок, они могут определять приоритеты обслуживания, возможности тестирования и надежности с помощью возможностей быстрого развертывания. Или если команда рабочей нагрузки имеет ограниченный бюджет, они могут определить приоритеты в реализации и простоте. Выбор и обслуживание архитектуры не является одноразовой деятельностью, но непрерывным подходом: архитектура должна быть постоянно измеряемой, проверенной и точно настроенной с течением времени. Как правило, в переключении архитектурного стиля есть значительные затраты, поэтому больше усилий можно оправдать для долгосрочной эффективности команды и устранения рисков.

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

Стиль архитектуры Управление зависимостями Тип домена
N-уровень Горизонтальные уровни, разделенные подсетью. Традиционный домен для бизнеса. Частота обновления не высокая.
Рабочая роль веб-очереди Интерфейсные и серверные задания, разделенные асинхронным обменом сообщениями. Относительно простой домен с ресурсоемкими задачами.
Микрослужбы Вертикально (функционально) разделенные службы, вызывающие друг друга через API-интерфейсы. Сложный домен. Частые обновления.
Архитектура на основе событий Производитель и потребитель. Независимое представление для каждой подсистемы. Системы Интернета вещей и реального времени.
Большие данные Разделение большого набора данных на мелкие блоки. Параллельная обработка для локальных наборов данных. Пакетная обработка и анализ данных в режиме реального времени. Прогнозная аналитика с использованием машинного обучения.
Большие вычислительные ресурсы Распределение данных в тысячах ядер. Домены с ресурсоемкими вычислениями, например моделированием.

Сложности и преимущества

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

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

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

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

  • Взаимодействие между службами. Так как приложение можно разбить на отдельные службы, есть риск, что обмен данными между службами приведет к неприемлемому уровню задержек или перегрузке сети (например, в архитектуре микрослужб).

  • Управляемость. Насколько тяжело управлять приложением, выполнять мониторинг, развертывать обновления и т. д.?