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

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

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

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

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

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

N-уровень

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

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

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

Web-Queue-Worker — это архитектура, состоящая из веб-интерфейса, очереди сообщений и серверной рабочей роли. Веб-фронтенд обрабатывает HTTP-запросы и взаимодействие с пользователем, в то время как воркер выполняет ресурсоемкие задачи, длительные рабочие процессы или пакетные операции. Взаимодействие между интерфейсом и рабочей ролью осуществляется через асинхронную очередь сообщений.

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

Микрослужбы

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

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

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

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

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

Большие данные

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

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

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

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

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

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

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

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

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

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

• Независимое развертывание служб.
• Локализовать неисправности.
• Отправка более частых обновлений.
• Упрощение внедрения новых технологий в приложение.

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

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

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

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

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

При выборе стиля архитектуры рассмотрите следующие типы проблем:

• Сложность: Сложность архитектуры должна соответствовать домену. Если это слишком упрощенно, это может привести к большому шару грязи, где зависимости не хорошо управляемы и структура разбивается.

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

• Взаимодействие между службами: Разложение приложения на отдельные службы может увеличить затраты на обмен данными. В архитектурах микрослужб эта нагрузка часто приводит к проблемам задержки или перегрузке сети.

• Управляемость: Управление приложением включает такие задачи, как мониторинг, развертывание обновлений и поддержание работоспособности операций.

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

• Принципы проектирования Azure приложений

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

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