Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

Локально или удаленно, создавать или покупать

Размещаемые в облаке приложения позволяют ISV и поставщикам услуг размещения получить

экономическую эффективность от роста масштаба; и в условиях конкурентного рынка эта

прибыль будет пущена на уменьшение расходов потребителей. Однако переход к удаленным

и размещаемым сценариям означает, что предприятия должны согласиться с частичной

утратой контроля над приложениями, данными и уровнями обслуживания. Предприятия,

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

покупать их у сторонних производителей, должны взвесить все плюсы и минусы перехода к

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

покупки размещаемых приложений.

Локальное

Размещаемое

Сервис в облаке

Создание

Приложение,

разрабатываемое

самостоятельно и

выполняемое в собственном

дата-центре.

Приложение,

разрабатываемое

самостоятельно и

выполняемое на ресурсах

компании-поставщике услуг

размещения.

Размещаемая у поставщика

среда разработки и

выполнения.

Покупка

Коробочное приложение,

приобретаемое в готовом

виде и выполняемое в

собственном дата-центре.

Коробочное приложение,

приобретаемое в готовом

виде и выполняемое на

ресурсах компании-

поставщике услуг

размещения.

Размещаемое приложение,

приобретаемое и

размещаемое у поставщика.

Выгода, получаемая от повышения эффективности вследствие роста масштаба, должна быть

сбалансирована с уменьшением контроля, связанным с переходом от локальных к полностью

размещаемым приложениям. Принимая решение о переходе к решению в облаке, о подходе к

разработке приложения и о том, где размещать свое приложение, руководствуйтесь

следующими рекомендациями:

 Используйте локальное размещение, если должны иметь полный контроль над

приложением и данными и предъявляемые требования по безопасности препятствуют

использованию размещаемых сервисов, либо использование таких сервисов

запрещено национальными политиками. При локальном размещении приложения в

собственной инфраструктуре вы можете:

◦ Создавайте собственное приложение, если не можете найти подходящее

готовое или хотите полностью контролировать функциональные

возможности приложения.

◦ Используйте готовое коробочное приложение, если оно удовлетворяет всем

требованиям и приемлемо по цене.

 Размещайте приложение у поставщика услуг размещения, если предполагаете

оптимизировать свои операции, но желаете сохранить контроль над ПО. Например,

можно развертывать настроенный пакет Enterprise Resource Planning (ERP) у

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

энергопотреблением, оборудованием, сетью и операционной системой. Как правило,

поставщик услуг размещения будет обеспечивать очень специфические требования

вашей организации, такие как, например, настройка Virtual Private Network (VPN),

добавление специализированного оборудования и многое другое. При размещении

приложений во внешней компании-поставщике услуг размещения:

◦ Выбирайте одно из готовых коробочных приложений поставщика услуг

размещения, если оно отвечает вашим требованиям. Доступность готовых

коробочных приложений может определить выбор поставщика услуг

размещения.

◦ Создавайте собственное приложение, если не можете найти поставщика,

предлагающего подходящее готовое приложений. В этом случае

необходимо учесть стоимость и время разработки собственного

приложения.

 Используйте сервисы в облаке (размещенные у поставщика ПО), если покупаете SaaS-

приложение у поставщика услуг размещения или ISV; если можете обеспечить

спецификацию требуемого приложения; если не имеете ресурсов, времени или

навыков для создания приложения; или если существующее стандартное или

настроенное приложение необходимо немедленно. Другая причина использования

внутренних свойств стандартных блоков сервисов в облаке (таких как эластичность) –

создание самого приложения. Приобретая сервисы приложений у поставщика:

◦ Выбирайте готовое коробочное приложение, созданное поставщиком ПО,

если оно отвечает имеющимся краткосрочным и долгосрочным

требованиям. Это SaaS-подход.

◦ Выбирайте предоставляемую поставщиком платформу размещения для

выполнения собственного приложения, если не можете найти подходящего

готового приложения. При этом необходимо учесть стоимость и время

разработки собственного приложения. Это PaaS-подход.

Производительность

Размещаемые в облаке приложения должны быть масштабируемыми для обеспечения

поддержки увеличивающегося количества сервисов и увеличивающейся нагрузки для каждого

сервиса и тенанта. При проектировании сервисов руководствуйтесь следующими

рекомендациями для масштабирования приложений:

 По возможности создавайте сервисы и компоненты без сохранения состояния. Это

сократит использование памяти для сервиса и улучшит возможности горизонтального

масштабирования и балансировки нагрузки сервисов.

 Используйте асинхронные входящие и исходящие вызовы, что позволяет приложениям

продолжать выполнение одновременно с выполнением операций ввода/вывода.

 Изучите возможности платформы размещения, которые могут способствовать

улучшению производительности. Например, в Microsoft Azure используйте очереди для

управления запросами и рабочие процессы для обработки в фоновом режиме.

 Используйте пулы ресурсов для потоков, сетевых подключений и подключений к базе

данных.

 Обеспечьте оптимальные условия для одновременной работы, используя блокировки

только в случае крайней необходимости.

При масштабировании хранилища данных и приложений руководствуйтесь следующими

рекомендациями:

 При масштабировании секции данных разделяйте данные подписчиков на меньшие

секции, чтобы обеспечить требования по производительности. Применяйте такие

схемы, как Хэширование (для разукрупнения содержимого) и Временная (основанная

на времени или диапазоне данных, в рамках которых данные считаются

действительными).

 Реализуйте динамическое повторное секционирование для автоматического

повторного секционирования данных, когда база данных достигает заданного

максимального размера.

 Для масштабирования хранилища данных и приложений рассмотрите стандартные

шаблоны и специальные техники и реализации, предоставляемые платформой

размещения, такие как секционирование данных, балансировка нагрузки, обработка

отказов и географическое распределение.

Композиция сервисов

Корпоративным пользователям необходимо иметь доступ к разным хранилищам документов,

типам данных, источникам информации и приложениям, осуществляющим определенные

функции. Традиционно пользователи напрямую взаимодействовали с каждым хранилищем

или приложением, часто используя для этого специальные изолированные приложения.

Однако со временем корпорации постарались консолидировать системы, часто используя для

этого Веб-порталы или фасадные-приложения, подключающиеся к соответствующим

нижестоящим приложениям.

С появлением сервисов и SOA-приложений отделы ИТ получили возможность предоставлять

приложения и данные как сервисы, либо размещенные локально, или приобретенные как

SaaS. Портфели сервисов могут по-прежнему предоставлять сочетание традиционных

локальных приложений, размещенных локально сервисов и удаленных сервисов через

порталы, которые скрывают пользователя от реализаций и позволяют отделам ИТ быстро и

без труда переходить на различные сервисы. Однако дизайны и технологии S+S и SaaS

обеспечивают отделам ИТ и корпоративным потребителям возможность полной интеграции

сервисов. Интеграция сервисов поможет реализовать модель многие-к-одному, при которой

все приложения и сервисы доступны пользователю через архитектуру композиции,

предоставляющую их как одно приложение (рис. 2). Механизм интеграции сервисов

объединяет группы приложений в портфели и предоставляет их через насыщенный клиент,

который может взаимодействовать с любым сервисом или приложением.

Рис. 2

Механизм интеграции сервисов может объединить множество сервисов в единый

интерфейс

Корпоративным пользователям размещаемых в облаке сервисов обычно понадобится

создавать комбинированные системы, использующие предоставляемые поставщиками услуг

размещения сервисы, и предлагать их через локальные порталы и портфели. Эффективная

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

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

взаимодействие персонала и повышает осведомленность о невыполненных задачах и их

статусе. Бизнес-данные становятся более наглядными, что помогает пользователям принимать

осознанные бизнес-решения. Композиция унифицированного решения, использующего

размещаемые в облаке сервисы, обычно включает следующие три уровня:

 Слой источников входных данных. К источникам входных данных относятся

размещаемые в облаке сервисы, внутренние приложения, внутренние базы данных,

Веб-сервисы, неструктурированные файлы и пр. Внутренние ресурсы могут

предоставляться через портфели ИТ-сервисов.

 Слой композиции. Слой, в котором происходит агрегация необработанных данных и их

обработка для предоставления пользователю в новом унифицированном виде.

Основная функция этого слоя – преобразование данных в бизнес-данные и аналитику

процесса. Обычно слой включает следующее:

◦ Компоненты, управляющие доступом, данными, рабочим процессом и

правилами.

◦ Агенты сервисов, которые согласовывают схемы и обмениваются

сообщениями с приложениями, базами данных, Веб-сервисами и другими

ресурсами.

◦ Компоненты управления удостоверениями, которые аутентифицируют и

авторизуют пользователей и управляют учетными данными для

взаимодействия с Веб-сервисами.

◦ Компоненты агрегации данных, которые преобразуют данные

соответственно модели сущностей приложений.

 Ориентированный на работу с пользователем слой. Этот слой представляет

пользователю составные данные в централизованном интегрированном

ориентированном на задачу пользовательском интерфейсе.

При использовании размещаемых в облаке сервисов как части составного пользовательского

интерфейса для интеграции внешних и внутренних сервисов обычно требуется рабочий

процесс или поэтапные процессы. Обычным решением является применение брокера

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

метаданных для управления перемещением и маршрутизацией сообщений. К типовым

операциям брокера интеграции относятся:

 Безопасность. Подсистема безопасности выполняет аутентификацию источника данных

или цифровой подписи, проводит дешифрацию данных и проверяет их на наличие

угроз безопасности, таких как вирусы. Для управления доступом операции по

обеспечению безопасности могут быть скоординированы с существующими

политиками безопасности.

 Валидация. Подсистема валидации сравнивает данные с соответствующими схемами и

отклоняет данные, не отвечающие им.

 Преобразование. Подсистема преобразования выполняет преобразование данных в

соответствующий формат.

 Рабочий процесс синхронизации. Подсистема синхронизации использует рабочие

процессы и правила для определения логических адресов и порядка передачи

сообщений в соответствующие места назначения. Она также может управлять

транзакциями бизнес-процесса для обеспечения согласованности данных.

 Маршрутизация. Подсистема маршрутизации, используя правила маршрутизации,

которые определяют физические адреса, передает сообщения с данными в заданные

места назначения. Возможно использование данных сообщения для определения

адресов на основании содержимого.

Интеграция сервисов

Размещаемые в облаке решения могут способствовать решению некоторых проблем,

присущих традиционному ПО, но при этом потребители этих сервисов сталкиваются с новыми

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

приложениям обратите внимание на следующие вопросы:

 Управление удостоверениями. Операции по добавлению, обновлению и удалению

пользователей должны быть перенесены на удаленные сервисы. Если внешний сервис

зависит от удостоверения пользователя, что очень вероятно для SaaS и S+S,

удаленными должны быть также процессы регистрации и отзыва прав доступа

пользователей. Кроме того, может потребоваться преобразование локального

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

сервис, для снижения миграции или дублирования удостоверений отдельных

пользователей на хосте удаленных сервисов. Политики учетных записей

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

записи, также должны быть совместимыми с политиками поставщика удаленных

сервисов. Невозможность использования SSO может привести к повышению расходов,

затрат на обслуживание и операционной неэффективности.

 Данные. Требования операций с данными, таких как Extract, Transform, Load (ETL) и

интеграция данных, должны быть проанализированы на предмет совместимости с

возможностями сервисов. Размещаемые сервисы могут не поддерживать шаблоны

хранения составных данных, что повлияет на дизайн сущностей данных и архитектуру

приложения. Кроме того, возможно, понадобится предпринять дополнительные меры

защиты данных, чтобы скомпенсировать недостаток физической безопасности, которая

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

конфиденциальные или личные данные локально и использовать сервисы в облаке

только для неконфиденциальных данных. Также необходимо спланировать процесс

передачи данных провайдеру сервиса и то, как они будут передаваться другому

провайдеру в случае возникновения такой необходимости.

 Операции. Локальные сервисы интеграции и клиентские приложения могут быть

несовместимыми с сервисами, предоставляемыми поставщиком сервисов, даже при

использовании стандартных протоколов. Необходимо обеспечить поставщику сервисов

возможность формировать соответствующие сведения отчетности и выработать

стратегию интеграции этих данных с собственными системами управления и

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

обслуживания (Service Level Agreements, SLA), чтобы обеспечить их выполнение в

условиях все возрастающей зависимости от поставщика сервисов. Предприятия также

должны быть готовы реализовать службу поддержки, которая будет выступать в роли

первой инстанции для пользователей, и определить процедуры решения проблем с

поставщиком сервисов.

 Безопасность. Политики конфиденциальности предприятия должны быть

совместимыми с политиками поставщика сервисов. Также должны быть обеспечены

правила для действий, которые могут выполняться пользователями, такие как

ограничения по размеру транзакции и другие бизнес-правила, даже если они не

относятся к возможностям удаленного сервиса. Это может усложнить инфраструктуру

интеграции сервисов. Также потребуются процедуры и политики для обеспечения

безопасности и целостности данных в случае сбоя сервиса или подключения. Для

аутентификации, шифрования и использования цифровых подписей необходимо будет

приобрести сертификаты у сертифицированных поставщиков и, возможно, реализовать

Инфраструктуру открытых ключей (Public Key Infrastructure, PKI). Кроме того, интеграция

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

обеспечения фильтрации данных приложений и валидации XML-схемы понадобится

обновление их оборудования и ПО.

 Возможность подключения. Некоторым типам приложений в облаке, таким как

сервисы оперативной обработки транзакций и сервисы реального времени (Передача

голоса по IP (voice over IP, VoIP) и Microsoft Office Communications Server), для

эффективной работы необходимо наличие широкополосного Интернет-подключения

хорошего качества. В некоторых регионах и странах такое подключение может быть

недоступным. Кроме того, сервисы, требующие больших объемов передачи данных,

такие как сервисы архивации и доставки файлов, как правило, через сетевое

соединение будут выполняться медленнее, чем при локальной реализации, чтоб

может представлять проблему. Однако обмен сообщениями и другие подобные

сервисы не так зависят от полосы пропускания и не так сильно страдают от

периодической потери подключения.

 Соглашения об условиях обслуживания (SLA). Для всестороннего сотрудничества с

поставщиками и принятия решений относительно приобретения контрактов на

обслуживание потребуются определенные навыки и опыт. Возможно, при

использовании сервисов, размещенных у удаленного поставщика, придется

пересматривать SLA, чтобы убедиться в возможности их выполнения.

 Соблюдение правовых норм. Соблюдение правовых и корпоративных норм может

зависеть от производительности поставщика сервисов, либо существует вероятность

возникновения конфликтов между корпоративными и правовыми нормами, если

поставщик территориально находится в другом государстве или регионе. Также с

получением отчетов о соответствии правовым нормам от поставщика сервисов могут

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

запрещать выполнение в сценариях с размещением некоторых типов приложений,

таких как приложения для банковского обслуживания.

Управление сервисами

Поставщики сервисов в облаке сталкиваются с определенными сложностями при размещении

и предложении сервисов, которые выполняются в облаке, особенно в вопросах доставки и

поддержки сервисов. Некоторые ISV просто создают приложения и предоставляют их для

размещения, тогда как другие производители создают и размещают свои приложения

самостоятельно. Строя планы о создании размещаемых сервисов, необходимо учесть

несколько аспектов. Некоторые из них касаются только ISV, размещающих собственные

сервисы, тогда как другие относятся только к компаниями, предоставляющим услуги

размещения:

 Управление уровнем обслуживания. Разные корпоративные пользователи могут

требовать внесения некоторых изменений или дополнений в стандартные соглашения

об условиях обслуживания с поставщиками услуг размещения. Это может усложнить

задачу по выполнению всех требований всех потребителей. Решение с размещением в

облаке может использоваться потребителями как способ повышения доступности и

производительности, таким образом, ожидания от применения такого решения будут

выше, чем для локального приложения. Управление и удовлетворение этим

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

требуется управление зависимостями (такими как поставщики сетевых услуг и

электропитания) и выполнение разных требований потребителей, находящихся в

различных точках земного шара. При размещении сервисов для множества

предприятий, особенно если они находятся в разных часовых поясах или переживают

пиковые нагрузки в разное время в течение дня или недели, должны быть тщательно

спланированы обслуживание и периоды простоя сервисов.

 Управление пропускной способностью и непрерывностью. Поставщики сервисов не

будут обладать тем же пониманием возможных изменений требований по пропускной

способности, как специалисты заказчика, что может привести к неожиданным пикам

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

пропускной способности. Перспективное планирование затруднено, поскольку рост и

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

поставщик не будет проинформирован заранее или будет знать очень немного. При

реализации и настройке сервисов очень сложно обеспечить выполнение требований

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

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

поэтапного увеличения, но долгосрочное планирование намного сложнее реализовать,

не имея в своем распоряжении оценок потребителей.

 Поддержка пользователей. Персонал службы поддержки должен знать и принимать

во внимание требования и сценарии использования, чтобы предоставлять

оптимальную поддержку пользователям. В условиях использования каждого сервиса

большим количеством потребителей служба поддержки будет получать огромное

количество обращений, связанных со сбоями или проблемами, возникающими при

работе с сервисами. Персонал службы поддержки должен уметь определять стоимость

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

поддержка предоставляется как платная дополнительная услуга. Идеальным

вариантом является предоставление для размещаемого в облаке решения активной

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

работоспособности решения и проводит профилактику этой проблемы. Также могут

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

системы отслеживания проблем.

Шаблоны проектирования

Основные шаблоны проектирования организованы по категориям, таким как Доступность

данных, Передача данных, Преобразование данных, Интеграция и композиция,

Производительность и надежность и Взаимодействие с пользователем, и представлены в

следующей таблице. Рассмотрите возможности применения этих шаблонов при принятии

проектных решений для каждой из категорий.

Категория

Шаблоны

Доступность данных

Polling (Опрос). Один источник, как правило, через равные промежутки

времени опрашивает остальные о наличии изменений.

Push (Выталкивание). Источник, данные в котором были изменены,

передает изменения в приемник данных при каждом изменении данных или

через равные промежутки времени.

Publish/Subscribe. Смешанный подход, сочетающий в себе черты опроса и

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

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

приемник данных.

Передача данных

Asynchronous Data Transfer (Асинхронная передача данных).

Основанный на сообщениях метод, при котором отправитель и получатель

обмениваются данными, не ожидая ответа.

Synchronous Data Transfer (Синхронная передача данных).

Интерфейсный метод, при котором отправитель и получатель обмениваются

данными в режиме реального времени.

Преобразование

данных

Shared Database (Совместно используемая база данных). Все

интегрируемые приложения выполняют чтение данных напрямую из одной и

той же базы данных.

Maintain Data Copies (Хранение копий данных). Сохраняет копии базы

данных приложения, чтобы другие приложения могли читать данные (и,

возможно, обновлять их).

File Transfer (Передача файлов). Доступность данных обеспечивается

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

для того чтобы другие приложения могли загружать данные из файлов.

Интеграция и

композиция

Broker (Посредник). Скрывает детали реализации вызова удаленного

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

компонента.

Composition (Композиция). Объединяет множество сервисов, приложений

или документов в интегрированный интерфейс, обеспечивая при этом

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

источника данных.

Portal Integration (Интеграция в портал). Создает приложение портала,

которое отображает в унифицированном UI данные, извлекаемые из

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

задачи на основании данных, отображаемых в портале.

Производительность

и надежность

Server Clustering. Организовывает инфраструктуру приложения таким

образом, что используемые серверы представляются пользователям и

приложениям как виртуальные унифицированные вычислительные ресурсы,

что позволяет улучшить доступность и масштабируемость либо и то, и

другое.

Load-Balanced Cluster. Устанавливает сервис или приложение на множество

серверов, конфигурированных для разделения рабочей нагрузки. Хосты с

балансировкой нагрузки параллельно отвечают на запросы разных клиентов,

даже на множество запросов одного клиента.

Failover Cluster. Устанавливает приложение или сервис на множество

серверов, конфигурированных так, чтобы замещать друг друга в случае

отказа. Каждому серверу в кластере поставлен в соответствие, по крайней

мере, один сервер этого кластера, который является резервным для него.

Взаимодействие с

пользователем

Universal Web (Универсальный Веб). Обеспечивается максимальная

доступность и, в то же время, простота развертывания с возможностью

работы в Веб-браузерах без каких-либо специальных расширений.

Experience First (Опыт прежде всего). Повышает качество взаимодействия

с пользователем путем использования оптимизированных возможностей

компьютера и устройства.

Дополнительные источники

Электронная версия списка используемых источников доступна по адресу

http://www.microsoft.com/architectureguide.

Больше информации о Microsoft Azure можно найти в материале «Azure Services Platform» по

адресу http://www.microsoft.com/azure/default.mspx.

Более подробно система управления удостоверениями Microsoft «Geneva» рассматривается в

статье «Geneva Simplifies User Access to Applications and Services» (Geneva упрощает доступ

пользователей к приложениям и сервисам) по адресу http://msdn.microsoft.com/en-

us/security/aa570351.aspx.

Архитектуре S + S посвящены следующие источники Developer Center

сайта MSDN:

 «Multi-Tenant Data Architecture» (Многотенантная архитектура данных) по адресу

http://msdn.microsoft.com/en-us/architecture/aa479086.aspx.

 «Software + Services (S+S)» по адресу http://msdn.microsoft.com/en-

us/architecture/aa699384.aspx.

 Веб-трансляция Жанпаоло Карраро (Gianpaolo Carraro) «Software + Services for

Architects» (S + S для архитекторов) по адресу http://www.microsoft.com/feeds/msdn/en-

us/architecture/media/SaaS/ssForArchitects.asx.

Архитектуре S + S посвящены следующие материалы Architecture Journal

сайта MSDN:

 «A Planet Ruled by Software Architectures» (Планетой правят архитектуры ПО) по адресу

http://msdn.microsoft.com/en-us/architecture/bb906059.aspx.

 «Head in the Cloud, Feet on the Ground» (Витаем в облаках, но крепко стоим на ногах) по

адресу http://msdn.microsoft.com/en-us/library/dd129910.aspx

 «Enterprise Mash Ups» (Корпоративные составные приложения) по адресу

http://msdn.microsoft.com/en-us/architecture/bb906060.aspx.

 «Implications of Software + Services Consumption for Enterprise IT» (Сложности с

использованием S + S для корпоративных ИТ) по адресу http://msdn.microsoft.com/en-

us/architecture/bb906061.aspx.

Центр разработчиков (прим. переводчика).

Журнал по архитектуре (прим. переводчика).