Книга «Руководство по архитектуре облачных приложений» |
||
МЕНЮ Искусственный интеллект Поиск Регистрация на сайте Помощь проекту ТЕМЫ Новости ИИ Искусственный интеллект Разработка ИИГолосовой помощник Городские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Слежка за людьми Угроза ИИ ИИ теория Внедрение ИИКомпьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Распознавание лиц Распознавание образов Распознавание речи Техническое зрение Чат-боты Авторизация |
2018-10-03 10:39 В этом руководстве структурированы рекомендации по проектированию масштабируемых, отказоустойчивых и высокодоступных облачных приложений. Оно призвано помочь вам в принятии решений об архитектуре, независимо от того, какую облачную платформу вы используете. Руководство организовано как последовательность шагов — выбор архитектуры ? выбор технологий для вычисления и хранения данных ? проектирование приложения Azure ? выбор шаблонов ? проверка архитектуры. Для каждого из них приведены рекомендации, которые помогут вам при разработке архитектуры приложения.
Сегодня мы публикуем часть первой главы этой книги. Полную версию вы можете скачать бесплатно по ссылке. Оглавление
Выбор архитектуры Первое решение, которое вам нужно принять при проектировании облачного приложения, — выбрать архитектуру. Выбор архитектуры зависит от сложности приложения, области применения, его типа (IaaS или PaaS) и задач, для решения которых оно предназначено. Также важно учитывать навыки команды разработчиков и менеджеров проекта, а также наличие у приложения готовой архитектуры.
Краткий обзор вариантов архитектуры В этом разделе приведен краткий обзор выделенных нами вариантов архитектуры, а также даны общие рекомендации по их использованию. Более подробную информацию вы сможете найти в соответствующих разделах, доступных по ссылкам. N-уровневая N-уровневая архитектура чаще всего используется в корпоративных приложениях. Для управления зависимостями приложение делится на слои, каждый из которых отвечает за определенную логическую функцию, например за представление данных, бизнес-логику или доступ к данным. Слой может обращаться с вызовами к другим слоям, расположенным ниже. Однако такое деление на горизонтальные слои может стать причиной возникновения дополнительных трудностей. Например, может оказаться сложно внести изменения в одну часть приложения, не затронув другие его элементы. Поэтому часто обновлять такое приложение непросто, и разработчикам придется реже добавлять новые функции. Веб-интерфейс — очередь — рабочая роль Для решений PaaS подходит архитектура «веб-интерфейс — очередь — рабочая роль». При такой архитектуре приложение имеет веб-интерфейс, который обрабатывает HTTP-запросы, и серверную рабочую роль, отвечающую за операции, которые выполняются длительное время или требовательны к вычислительным ресурсам. Для взаимодействия между интерфейсом и серверной рабочей ролью используется очередь асинхронных сообщений. Микрослужбы Если приложение предназначено для решения более сложных задач, попробуйте реализовать его на базе архитектуры микрослужб. Такое приложение состоит из множества небольших независимых служб. Каждая служба отвечает за отдельную бизнес-функцию. Службы слабо связаны между собой и для взаимодействия используют контракты API. CQRS Архитектура CQRS (Command and Query Responsibility Segregation, распределение ответственности между командами и запросами) позволяет разделить операции чтения и записи между отдельными моделями. В результате части системы, отвечающие за изменение данных, изолируются от частей системы, которые отвечают за чтение данных. Более того, операции чтения могут выполняться в материализованном представлении, которое физически отделено от базы данных, в которую ведется запись. Это позволяет независимым образом масштабировать процессы чтения и записи и оптимизировать материализованное представление для выполнения запросов. Архитектура на основе событий Архитектура на основе событий использует модель публикации-подписки, в которой поставщики публикуют события, а потребители подписываются на них. Поставщики независимы от потребителей, а потребители независимы друг от друга. Большие данные, большие вычисления Большие данные и большие вычисления— это специальные варианты архитектуры, применяемые для решения особых задач. При использовании архитектуры больших данных крупные наборы данных делятся на фрагменты, которые затем обрабатываются параллельно для целей анализа и формирования отчетов. Большие вычисления также называют высокопроизводительными вычислениями (HPC). Эта технология позволяет распределять вычисления между множеством (тысячами) процессорных ядер. Эти архитектуры можно применять для имитационного моделирования, 3D-рендеринга и других подобных задач. Варианты архитектуры как ограничения Архитектура выступает в роли ограничения при проектирования решения, в частности она определяет, какие элементы можно использовать и какие связи между ними возможны. Ограничения задают «форму» архитектуры и позволяют сделать выбор из более узкого набора вариантов. Если ограничения выбранной архитектуры соблюдены, у решения появляются характерные для этой архитектуры свойства.
Следование этим ограничениям приводит к созданию системы, в которой службы можно развертывать независимо друг от друга, неисправности изолированы, возможны частые обновления, а в приложение легко добавляются новые технологии. Прежде чем выбрать архитектуру, убедитесь, что вы хорошо понимаете лежащие в ее основе принципы и связанные с этим ограничения. В противном случае вы можете получить решение, которое внешне соответствует выбранной модели архитектуры, но в нем полностью не раскрыт потенциал этой модели. Важно также руководствоваться здравым смыслом. Иногда разумнее отказаться от того или иного ограничения, чем стремиться к чистоте архитектуры. В следующей таблице показано, как осуществляется управление зависимостями в каждой их архитектур, и для решения каких задач больше всего подходит та или иная архитектура. Анализ преимуществ и недостатков Ограничения создают дополнительные трудности, поэтому важно понимать, чем приходится жертвовать при выборе того или иного варианта архитектуры, и уметь ответить на вопрос, перевешивают ли преимущества выбранного варианта его недостатки для конкретной задачи в конкретном контексте.
N-уровневая архитектура В N-уровневой архитектуре приложение делится на логические слои и физические уровни. Слои представляют собой механизм распределения ответственности и управления зависимостями. Каждый слой имеет собственную область ответственности. Слои более высокого уровня пользуются службами слоев более низкого уровня, но не наоборот. Уровни разделены физически и работают на разных компьютерах. Один уровень может обращаться к другому напрямую или с помощью асинхронных сообщений (очереди сообщений). Хотя каждый слой должен размещаться на собственном уровне, это не обязательно. На одном уровне можно разместить несколько слоев. Физическое разделение уровней делает решение не только более масштабируемым и отказоустойчивым, но и более медленным, так как для взаимодействия чаще используется сеть. Традиционное трехуровневое приложение состоит из уровня представления, промежуточного уровня и уровня баз данных. Промежуточный уровень является необязательным. Более сложные приложения могут состоять из более чем трех уровней. На схеме выше показано приложение с двумя промежуточными уровнями, отвечающими за различные функциональные области.N-уровневое приложение может иметь закрытую архитектуру слоев или открытую архитектуру слоев.
Закрытая архитектура слоев ограничивает зависимости между слоями. Однако ее использование может чрезмерно увеличить сетевой трафик, если тот или иной слой будет просто пересылать запросы на следующий слой. Области применения архитектуры N-уровневая архитектура обычно применяется в приложениях IaaS, где каждый уровень работает на отдельном наборе виртуальных машин. Однако N-уровневое приложение не обязательно должно быть чистым приложением IaaS. Зачастую бывает удобно использовать для некоторых компонентов решения управляемые службы, особенно для кэширования, обмена сообщениями и хранения данных.
N-уровневая архитектура распространена среди обычных локальных приложений, поэтому она хорошо подходит для переноса имеющихся приложений в Azure. Преимущества
Недостатки
Рекомендации
N-уровневая архитектура на виртуальных машинах В этом разделе приведены рекомендации по построению N-уровневой архитектуры при использовании виртуальных машин. В этом разделе приведены рекомендации по построению N-уровневой архитектуры при использовании виртуальных машин. Каждый уровень состоит из двух или более виртуальных машин, размещенных в наборе доступности или в масштабируемом наборе виртуальных машин. Использование нескольких виртуальных машин обеспечивает отказоустойчивость в случае сбоя одной из них. Для распределения запросов между виртуальными машинами одного уровня используются подсистемы балансировки нагрузки. Уровень можно масштабировать горизонтально, добавляя в пул новые виртуальные машины. Каждый уровень также помещается внутрь собственной подсети. Это означает, что их внутренние IPадреса относятся к одному и тому же диапазону. Это позволяет легко применять к отдельным уровням правила групп безопасности сети (NSG) и таблицы маршрутизации.Состояние веб-уровня и бизнес-уровня не отслеживается. Любая виртуальная машина может обрабатывать любые запросы для этих уровней. Уровень данных должен состоять из реплицированной базы данных. Для Windows мы рекомендуем использовать SQL Server с группами доступности Always On для обеспечения высокой доступности. Для Linux следует выбрать базу данных, которая поддерживает репликацию, например Apache Cassandra. Доступ к каждому из уровней ограничивается группами безопасности сети (NSG). Например, доступ к уровню баз данных разрешен только для бизнес-уровня Дополнительные особенности
Бесплатно скачать полную версию книги и изучить ее вы можете по ссылке ниже. ? Скачать Источник: habr.com Комментарии: |
|