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

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

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

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

Существует два основных типа масштабирования: вертикальное (большой блок) и

горизонтальное (больше блоков).

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

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

оперативная память и сетевые интерфейсные платы (network interface cards, NIC). Такой

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

экономически выгодным лишь до определенного момента. Однако всегда сохраняется

вероятность сбоя, что является риском. Кроме того, введение дополнительного оборудования

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

последних 10% расчетной производительности путем наращивания мощностей одного

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

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

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

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

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

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

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

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

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

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

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

размещаться на нескольких Веб-серверах с балансировкой нагрузки, образующих Веб-ферму.

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

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

внешнем уровне с балансировкой нагрузки. Если приложение имеет ограничения по

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

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

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

инфраструктуры.

Вопросы вертикального масштабирования

Вертикальное масштабирование через повышение мощности процессора и увеличение

объема памяти может быть экономически эффективным решением. Также при таком подходе

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

масштабированием в связи с применением Веб-ферм и кластеризации. Прежде всего, следует

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

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

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

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

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

перспективы ее роста.

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

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

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

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

серверы. Для обеспечения эффективного горизонтального масштабирования приложения при

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

 Узкие места идентификации и горизонтального масштабирования. Часто узким

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

направлении ресурсы. Например, имеется единственный экземпляр SQL Server, с

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

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

экземплярами SQL Server, обеспечит возможность горизонтального

масштабирования решения. Если существует вероятность того, что узким местом

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

проектировании, это избавит от многих проблем в будущем.

 Слабо связанный и многослойный дизайн. Слабо связанный многослойный дизайн

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

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

детализированными интерфейсами. Многослойный дизайн будет иметь

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

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

Например, бизнес-логику проще перенести в ферму серверов приложений

среднего уровня с балансировкой нагрузки.

Компромиссы и последствия их принятия

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

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

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

с последующим горизонтальным масштабированием с применением Веб-серверов или

серверов приложений не является наилучшим подходом. Например, можно установить 8-

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

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

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

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

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

возможности балансировки нагрузки и обработки отказов не бесконечны, и количество

серверов, которые могут быть охвачены этими процессами, ограничено. Также влияние

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

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

об общей стоимости всей системы.

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

всеми остальными ограничениями. Например, использование четырех 2-процессорных Веб-

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

цены и производительности по сравнению с использованием двух 4-процессорных серверов.

Однако должны быть учтены и другие ограничения, такие как какое максимальное число

серверов, которые можно разместить в конкретной инфраструктуре балансировки нагрузки, а

также энергопотребление или предоставляемая площадь в дата-центре.

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

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

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

ресурсов и рентабельность инвестиций.

Компоненты без сохранения состояния

Применение компонентов без сохранения состояния (не сохраняющие промежуточного

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

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

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

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

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

Секционирование данных и базы данных

Если приложение работает с очень большой базой данных и есть опасения, что операции

ввода/вывода станут узким местом системы, заранее предусмотрите секционирование базы

данных. Секционирование базы данных на более поздних этапах проектирования обычно

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

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

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

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

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

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

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

последствия. Например, некоторые операции эффективнее выполнять с данными,

сконцентрированными на одном накопителе.

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

многом определяются типом данных. Рассмотрим значимые факторы:

 Статические справочные данные только для чтения. Для этого типа данных в целях

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

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

соответствующих местоположениях. Это имеет минимальное влияние на дизайн и

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

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

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

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

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

тиражирование требует применения механизмов обеспечения синхронизации

системы.

 Динамические (часто изменяющиеся) легко секционируемые данные. Это

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

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

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

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

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

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

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

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

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

запросы могут поступать на другой Веб-сервер или сервер приложений, все эти

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

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

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

правило, тиражировать данные этого типа нежелательно из-за сложности их

синхронизации. Классическое решение для таких данных – вертикальное

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

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

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

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

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

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

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

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

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

такие как кому принадлежат данные, географическое распределение

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

 Данные с отложенной синхронизацией. Некоторые используемые в приложениях

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

Отличный пример – такие данные онлайн-магазинов, как «С товаром Х часто

покупают Y и Z». Эти данные извлекаются из основных данных, но не требуют

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

обеспечивающих перевод данных из основных в секционируемые (динамические)

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

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

Более подробно схемы перемещения и тиражирования данных рассматриваются в статье

«Data Movement Patterns» (Шаблоны передачи данных) по адресу

http://msdn.microsoft.com/en-us/library/ms998449.aspx.

Вопросы безопасности сетевой инфраструктуры

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

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

ограничения по применяемым портам, поддерживаемые протоколы и т.д. Предлагаем

рекомендации по повышению безопасности сети:

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

экраны и их политики. Межсетевые экраны должны использоваться для отделения

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

данных. Межсетевые экраны разрешают взаимодействие только через

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

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

опций связи. К ним относится аутентификация, например аутентификация Windows,

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

за межсетевым экраном.

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

внутренним ресурсам с Веб-серверов пограничной сети или из насыщенных

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

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

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

протоколов.

 Обменивайтесь информацией с группой разработки и группой обслуживания сети и

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

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

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

 Обратите внимание и убедитесь в наличии таких средств защиты, как межсетевые

экраны, фильтры пакетов и аппаратные системы, которые приложение

предполагает получить от сети.

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

повлияет на безопасность.

Вопросы управляемости

Решения, принимаемые при развертывании приложения, оказывают влияние на возможности

управления и мониторинга приложения. Примите во внимание следующие рекомендации:

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

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

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

 Храните данные так, чтобы они были доступны средствам архивации и

восстановления.

 Компоненты, использующие существующее ПО или оборудование (такое как

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

компьютера), должны физически располагаться на том же компьютере.

 Развертывание некоторых библиотек и адаптеров невозможно без дополнительных

капиталовложений, плата также может взиматься за каждый ЦП, поэтому

централизация этих ресурсов позволит сократить затраты.

 Сервис, компонент или приложение могут принадлежать отдельному

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

 Средства мониторинга, такие как System Center Operations Manager, должны иметь

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

на варианты развертывания.

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

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

Производительность и надежность и Безопасность, и представлены в следующей таблице.

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

каждой из категорий.

Категория

Шаблоны

Развертывание

Layered Application (Многослойное приложение). Архитектурный

шаблон, обеспечивающий организацию системы по слоям.

Three-Layered Services Application (Трехслойное сервисное

приложение). Архитектурный шаблон, в котором слои проектируются так,

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

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

приложениями.

Tiered Distribution (Многоуровневое распределение). Архитектурный

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

границы.

Three-Tiered Distribution (Трехуровневое распределение).

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

физическим уровням.

Deployment Plan (План развертывания). Описывает процессы

сопоставления логических слоев и физических уровней с учетом

ограничений, налагаемых инфраструктурой.

Управляемость

Adapter (Адаптер). Объект, поддерживающий общий интерфейс и

транслирующий операции между общим интерфейсом и объектами,

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

интерфейсы.

Provider (Поставщик). Компоненты, которые предоставляют API,

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

подключения любой специальной реализации. Многие приложения,

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

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

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

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

надежность

Server Clustering (Кластеризация сервера). Шаблон развертывания, при

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

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

ресурс.

Load-balanced Cluster (Кластер с балансировкой нагрузки). Шаблон

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

что могут разделять рабочую нагрузку. Балансировка нагрузки

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

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

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

Failover Cluster (Отказоустойчивый кластер). Шаблон развертывания,

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

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

размещаемого на нем ПО.

Безопасность

Brokered Authentication (Аутентификация через посредника).

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

аутентификации при доступе к сервисам или системам.

Direct Authentication (Прямая аутентификация). Аутентификация

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

Impersonation and Delegation (Олицетворение и делегирование).

Процесс временного присвоения другого удостоверения для обеспечения

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

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

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

пользователя.

Trusted Subsystem (Доверенная подсистема). Для получения доступа к

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

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

данные, а не учетные данные пользователя.

Более подробно шаблоны Layered Application, Three-Layered Services Application, Tiered

Distribution, Three-Tiered Distribution и Deployment Plan рассматриваются в статье «Deployment

Patterns» (Шаблоны развертывания) по адресу http://msdn.microsoft.com/en-

us/library/ms998478.aspx.

Более подробно шаблон Adapter рассматривается в главе 4, «Структурные шаблоны», книги

Эрика Гамма, Ричарда Хельма, Ральфа Джонсона и Джона Влиссидса «Приемы объектно-

ориентированного проектирования. Паттерны проектирования». Питер, 2006.

Более подробно шаблон Provider рассматривается в материале «Provider Model Design Pattern

and Specification, Part 1» (Шаблон проектирования модели провайдеров и спецификация, Часть

1) по адресу http://msdn.microsoft.com/en-us/library/ms972319.aspx.

Более подробно шаблоны Server Clustering, Load-Balanced Cluster и Failover Cluster

рассматриваются в статье «Performance and Reliability Patterns» (Шаблоны развертывания для

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

us/library/ms998503.aspx.

Более подробно шаблоны Brokered Authentication, Direct Authentication, Impersonation and

Delegation и Trusted Subsystem рассматриваются в статье «Web Service Security» (Безопасность

Веб-сервисов) по адресу http://msdn.microsoft.com/en-us/library/aa480545.aspx.

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

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

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

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

 Более подробно методики авторизации рассматриваются в статье «Designing

Application-Managed Authorization» по адресу http://msdn.microsoft.com/en-

us/library/ms954586.aspx.

 Сценарии развертывания и связанные с ними вопросы рассматриваются в статье

«Deploying .NET Framework-based Applications» (Развертывание .NET-приложений)

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

 Больше сведений о шаблонах проектирования можно найти в статье «Enterprise

Solution Patterns Using Microsoft .NET» по адресу http://msdn.microsoft.com/en-

us/library/ms998469.aspx.

Архетипы приложений

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

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

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

приложение, насыщенный клиент, сервисы и RIA. В остальных главах каждый из типов

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

размещаемые сервисы и сервисы в облаке, а также приложения SharePoint и Microsoft Office.

Раздел включает следующие главы:

 Глава 20 «Выбор типа приложения»

 Глава 21 «Проектирование Веб-приложений»

 Глава 22 «Проектирование насыщенных клиентских приложений»

 Глава 23 «Проектирование насыщенных Интернет-приложений»

 Глава 24 «Проектирование мобильных приложений»

 Глава 25 «Проектирование сервисных приложений»

 Глава 26 «Проектирование размещаемых сервисов и сервисов в облаке»

 Глава 27 «Проектирование офисных бизнес-приложений»

 Глава 28 «Проектирование LOB-приложений SharePoint»

Выбор типа приложения

Обзор

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

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

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

сможете правильно определить тип приложения соответственно своему сценарию и

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

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

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

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

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

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

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

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

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

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

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

недостатков.

Обзор архетипов приложений

Рассмотрим основные базовые типы приложений:

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

клиент или насыщенное клиентское приложение. Насыщенные клиентские

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

подключения или без подключения вообще. Веб-приложения или тонкие клиентские

приложения поддерживают только сценарии с подключением. Ограничением при

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

предполагается выполнять.

 Насыщенные клиентские приложения. Приложения этого типа обычно

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

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