sahsAGU Oct 3 2018 at 10:00

Книга «Руководство по архитектуре облачных приложений»

11 min

11K

Microsoft corporate blogMicrosoft Azure*Cloud computing*Cloud services*Professional literature*

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

Руководство организовано как последовательность шагов — выбор архитектуры → выбор технологий для вычисления и хранения данных → проектирование приложения Azure → выбор шаблонов → проверка архитектуры. Для каждого из них приведены рекомендации, которые помогут вам при разработке архитектуры приложения.

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

Выбор архитектуры — 1;
Выбор технологий для вычисления и хранения данных — 35;
Проектирование приложения Azure: принципы проектирования — 60;
Проектирование приложения Azure: показатели качества — 95;
Проектирование приложения Azure: шаблоны проектирования — 103;
Каталог шаблонов — 110;
Контрольные списки проверки архитектуры — 263;
Заключение — 291;
Эталонные архитектуры Azure — 292;

Выбор архитектуры

Первое решение, которое вам нужно принять при проектировании облачного приложения, — выбрать архитектуру. Выбор архитектуры зависит от сложности приложения, области применения, его типа (IaaS или PaaS) и задач, для решения которых оно предназначено. Также важно учитывать навыки команды разработчиков и менеджеров проекта, а также наличие у приложения готовой архитектуры.

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

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

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

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

Краткий обзор вариантов архитектуры

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

N-уровневая

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

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

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

Для решений PaaS подходит архитектура «веб-интерфейс — очередь — рабочая роль». При такой архитектуре приложение имеет веб-интерфейс, который обрабатывает HTTP-запросы, и серверную рабочую роль, отвечающую за операции, которые выполняются длительное время или требовательны к вычислительным ресурсам. Для взаимодействия между интерфейсом и серверной рабочей ролью используется очередь асинхронных сообщений.

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

Микрослужбы

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

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

CQRS

Архитектура CQRS (Command and Query Responsibility Segregation, распределение ответственности между командами и запросами) позволяет разделить операции чтения и записи между отдельными моделями. В результате части системы, отвечающие за изменение данных, изолируются от частей системы, которые отвечают за чтение данных. Более того, операции чтения могут выполняться в материализованном представлении, которое физически отделено от базы данных, в которую ведется запись. Это позволяет независимым образом масштабировать процессы чтения и записи и оптимизировать материализованное представление для выполнения запросов.

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

Архитектура на основе событий

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

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

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

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

Варианты архитектуры как ограничения

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

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

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

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

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

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

Анализ преимуществ и недостатков

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

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

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

N-уровневая архитектура

В N-уровневой архитектуре приложение делится на логические слои и физические уровни.

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

Уровни разделены физически и работают на разных компьютерах. Один уровень может обращаться к другому напрямую или с помощью асинхронных сообщений (очереди сообщений). Хотя каждый слой должен размещаться на собственном уровне, это не обязательно. На одном уровне можно разместить несколько слоев. Физическое разделение уровней делает решение не только более масштабируемым и отказоустойчивым, но и более медленным, так как для взаимодействия чаще используется сеть. Традиционное трехуровневое приложение состоит из уровня представления, промежуточного уровня и уровня баз данных. Промежуточный уровень является необязательным. Более сложные приложения могут состоять из более чем трех уровней. На схеме выше показано приложение с двумя промежуточными уровнями, отвечающими за различные функциональные области.

N-уровневое приложение может иметь закрытую архитектуру слоев или открытую архитектуру слоев.

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

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

Области применения архитектуры

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

N-уровневую архитектуру рекомендуется использовать в следующих случаях:

простые веб-приложения;
перенос локального приложения в Azure с минимальным рефакторингом;
согласованное развертывание локальных и облачных приложений.

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

Преимущества

Возможность переноса приложений между локальным развертыванием и облаком, а также между облачными платформами.
Меньшая потребность в обучении для большинства разработчиков.
Естественное продолжение традиционной модели приложений.
Поддержка гетерогенных сред (Windows/Linux).

Недостатки

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

N-уровневая архитектура на виртуальных машинах

В этом разделе приведены рекомендации по построению N-уровневой архитектуры при использовании виртуальных машин.

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

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

Состояние веб-уровня и бизнес-уровня не отслеживается. Любая виртуальная машина может обрабатывать любые запросы для этих уровней. Уровень данных должен состоять из реплицированной базы данных. Для Windows мы рекомендуем использовать SQL Server с группами доступности Always On для обеспечения высокой доступности. Для Linux следует выбрать базу данных, которая поддерживает репликацию, например Apache Cassandra.

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

Дополнительные особенности

N-уровневая архитектура не обязательно должна состоять из трех уровней. В более сложных приложениях, как правило, используется большее число уровней. В этом случае используйте маршрутизацию через слой 7, чтобы перенаправлять запросы на конкретный уровень.
Уровни ограничивают решение относительно масштабируемости, надежности и безопасности. Рекомендуется использовать различные уровни для служб с различными требованиями к этим характеристикам.
Применяйте автоматическое масштабирование, используя для этого масштабируемые наборы виртуальных машин.
Находите в архитектуре элементы, которые можно реализовать с помощью управляемых служб без серьезного рефакторинга. В частности обратите внимание на кэширование, обмен сообщениями, хранилище и базы данных.
Для повышения безопасности разместите приложение за сетью периметра. Сеть периметра включает виртуальные сетевые компоненты, обеспечивающие безопасность, например брандмауэры и инспекторы пакетов. Дополнительные сведения см. в разделе Эталонная архитектура сети периметра.
Для обеспечения высокой доступности поместите два или более виртуальных сетевых компонента в набор доступности и добавьте подсистему балансировки нагрузки для распределения интернет-запросов между ними. Дополнительные сведения см. в разделе Развертывание виртуальных сетевых компонентов для обеспечения высокой доступности.
Не разрешайте прямой доступ к виртуальным машинам, на которых выполняется код приложения, по протоколам RDP и SSH. Вместо этого операторы должны входить в узелбастион. Это размещенная в сети виртуальная машина, используемая администраторами для подключения к другим виртуальным машинам. На узле-бастионе настраиваются правила NSG, разрешающие доступ по протоколам RDP и SSH только от одобренных публичных IP-адресов.
Виртуальную сеть Azure можно расширить до локальной сети с помощью виртуальной частной сети (VPN) типа «сеть-сеть» или Azure ExpressRoute. Дополнительные сведения см. в разделе Эталонная архитектура гибридной сети.
Если ваша организация использует Active Directory для управления удостоверениями, вы можете расширить среду Active Directory на виртуальную сеть Azure. Дополнительные сведения см. в разделе Эталонная архитектура управления удостоверениями.
Если требуется более высокий уровень доступности, чем обеспечиваемый согласно соглашению об уровне обслуживания Azure для виртуальных машин, реплицируйте приложение между двумя регионами и настройте диспетчер трафика Azure на отработку отказов. Дополнительные сведения см. в разделах Запуск виртуальных машин Windows в нескольких регионах и Запуск виртуальных машин Linux в нескольких регионах.

Бесплатно скачать полную версию книги и изучить ее вы можете по ссылке ниже.

→ Скачать

Tags:

Hubs: