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

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

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

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

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

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

N-уровень

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

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

Веб-Очередь-Рабочий

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

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

Микрослужбы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрите проблемы и преимущества

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

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

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

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

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

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

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

• Десять принципов проектирования приложений для Azure
• Создание приложений в Microsoft Cloud
• Рекомендации по облачным приложениям
• Шаблоны облачного проектирования
• Тестирование производительности и антипаттерны для облачных приложений
• Проектирование мультитенантных решений в Azure
• Архитектура критически важных рабочих нагрузок в Azure
• Архитектура для стартапов