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

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

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

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

приняты для каждого из них:

 Доступность

 Концептуальная целостность

 Возможность взаимодействия

 Удобство и простота обслуживания

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

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

 Надежность

 Возможность повторного использования

 Масштабируемость

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

 Обеспеченность технической поддержкой

 Тестируемость

 Взаимодействие с пользователем / удобство и простота использования

Доступность

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

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

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

инфраструктуры, злонамеренные атаки и нагрузка системы. Основные проблемы доступности:

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

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

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

механизмов балансировки сетевой нагрузки (Network Load Balancing) для Веб-серверов

распределите нагрузку и не допустите направление запросов на нефункционирующий

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

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

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

торнадо.

 Атаки типа отказ в обслуживании (Denial of Service, DoS), которые препятствуют доступу

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

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

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

из-за конфигурации сети и перегрузки системы запросами. Чтобы максимально

сократить негативное влияние атак типа DoS, сократите поверхность атаки, выявляйте

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

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

проверку данных. Устойчивость системы помогут повысить шаблоны Circuit Breaker

(Прерыватель) и Bulkhead (Перемычка).

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

ресурсов. Например, слишком ранний запрос и слишком долгое удержание ресурсов

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

параллельные запросы пользователей.

 Дефекты или ошибки приложения могут стать причиной общего сбоя системы.

Проектируйте соответствующую обработку исключений, чтобы сократить количество

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

 Частые обновления, такие как обновления безопасности или пользовательского

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

во время выполнения.

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

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

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

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

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

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

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

доступность.

Концептуальная целостность

Концептуальная целостность определяет согласованность и связность дизайна в целом. Сюда

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

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

заранее известно, что согласуется с общим дизайном. И, наоборот, система без

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

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

концептуальной целостности:

 Смешение разных функциональных областей. Выявите функциональные области и

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

сервисов и бизнес-слой.

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

эффективности применения методик Управления жизненным циклом приложения

(Application Lifecycle Management, ALM) и используйте испытанные и

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

 Недостаточный уровень сотрудничества и обмена информацией между разными

группами, принимающими участие в жизненном цикле приложения. Реализуйте

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

рабочего процесса, обмена сведениями и совместной работы.

 Недостаточное использование стандартов проектирования и написания кода.

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

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

следование рекомендациям.

 Требования поддержки существующих (устаревших) систем могут препятствовать как

реструктуризации, так и переходу на новые платформы или парадигмы. Продумайте

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

зависимостей. Например, реализация шаблона проектирования Gateway (Шлюз)

обеспечит интеграцию с устаревшими системами.

Возможность взаимодействия

Возможность взаимодействия – это способность системы или разных систем успешно работать

через взаимодействие и обмен данными с другими внешними системами, созданными и

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

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

интерфейсы и форматы данных – все это основные средства обеспечения возможности

взаимодействия. Еще одним важным аспектом при проектировании способной к

взаимодействию системы является стандартизация. Рассмотрим основные проблемы,

связанные с обеспечением возможности взаимодействия:

 Взаимодействие с внешними или устаревшими системами, использующими другие

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

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

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

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

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

данных.

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

Продумайте возможности изоляции систем через использование интерфейсов

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

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

помощью интерфейсов, использующих XML или стандартные типы. Проектируйте

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

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

 Недостаточное следование стандартам. Ознакомьтесь с формальными и реально

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

один из них, а не создавайте что-то новое и особое.

Удобство и простота обслуживания

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

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

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

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

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

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

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

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

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

 Слишком большая зависимость между компонентами и слоями и несоответствующее

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

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

на систему в целом. Правильно разделяйте системы на слои или функциональные

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

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

абстрактные классы и интерфейсы), а не конкретных классов, и максимально сократите

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

 Использование прямого взаимодействия является препятствием при изменении

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

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

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

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

обслуживать и тестировать.

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

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

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

платформы.

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

замену и создает ненужные зависимости от других компонентов. Проектируйте

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

упростить их замену и повторное использование.

 Объемный, трудно поддающийся управлению, хрупкий или слишком сложный код,

затрудненная реструктуризация из-за требований обратной совместимости.

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

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

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

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

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

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

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

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

 Существующий код не имеет комплекта автоматизированных регрессивных тестов.

Инвестируйте в автоматизацию тестов при разработке системы. Это окупится при

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

функциональности различных частей системы и их совместной работы.

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

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

структуру приложения.

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

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

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

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

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

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

 Недостаток хороших механизмов мониторинга, трассировки и диагностики. Создайте

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

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

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

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

выявляет изменения состояния и предоставляет эти изменения через стандартные

системы, такие как журналы событий (Event Logs), файлы трассировки или

инструментарий управления Windows (Windows Management Instrumentation, WMI).

Отслеживайте и собирайте достаточное количество сведений об ошибках и

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

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

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

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

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

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

среды, таких как изменение инфраструктуры или развертывания.

 Отсутствие инструментов поиска и устранения неисправностей. Рассмотрите

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

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

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

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

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

или выходные данные модулей и вызовы других систем и сервисов.

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

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

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

показателях задержки или пропускной способности. Задержка – это время, необходимое для

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

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

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

производительности. Повышение производительности приложения часто приводит к

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

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

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

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

 Увеличение времени ответа клиента, снижение пропускной способности и

повышенное использование ресурсов сервера. Обеспечьте соответствующую структуру

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

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

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

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

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

асинхронного взаимодействия.

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

увеличению промахов кэша (невозможность найти необходимые данные в кэше) и

повышению количества обращений к хранилищу данных. Убедитесь в эффективности и

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

 Повышенный объем обработки на сервере базы данных, что приводит к снижению

пропускной способности. Убедитесь, что выбраны эффективные типы транзакций,

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

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

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

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

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

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

денежных затрат.

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

повышению нагрузки и на клиент, и на сервер. Правильный выбор соответствующего

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

взаимодействие между уровнями. Старайтесь сократить число транзакций через

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

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

Надежность

Надежность – это способность системы сохранять работоспособность в течение некоторого

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

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

проблемы надежности:

 Система дает сбой или не отвечает. Определите возможности для выявления сбоев и

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

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

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

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

 Неустойчивый вывод. Реализуйте инструментарий, такой как счетчики событий и

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

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

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

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

другим системам и сервисам.

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

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

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

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

Реализуйте системы передачи данных с промежуточным хранением или системы

связи посредством сообщений с кэшированием, обеспечивающие возможность

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

восстановлении подключения. Использование Windows Message Queuing или BizTalk

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

запросов.

Возможность повторного использования

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

использованию в других приложениях и сценариях для добавления новой функциональности с

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

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

времени, затрачиваемого на реализацию. Выявление общих атрибутов в различных

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

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

возможностью повторного использования:

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

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

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

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

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

сквозной функциональностью, такой как проверка, протоколирование и

аутентификация, и реализуйте эти функции как отдельные компоненты.

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

Разнообразить поведение метода помогут параметры.

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

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

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

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

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

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

которыми могут работать разные платформы.

Масштабируемость

Масштабируемость – это способность системы справляться с увеличением нагрузки без

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

Существует два метода улучшения масштабируемости: вертикальное масштабирование (scale

up) и горизонтальное масштабирование (scale out). Для обеспечения вертикального

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

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

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

Рассмотрим основные проблемы масштабируемости:

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

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

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

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

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

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

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

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

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

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

привязки к конкретному серверу.

 Пользователи ощущают задержку при обращениях к системе и увеличение

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

обработку всплесков трафика и нагрузки. Реализуйте код для использования

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

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

текущей системе.

 Система не может обработать очередь задач, сформированную в период повышенной

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

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

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

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

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

Безопасность – это способность системы предотвращать злонамеренные или случайные

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

данных. Повышение безопасности ведет также к повышению надежности системы за счет

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

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

изменение данных. Безопасность системы определяют такие факторы, как

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

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

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

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

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

проводите аутентификацию и авторизацию пользователей, пересекающих эти

границы.

 Нанесение ущерба злонамеренным вводом, таким как внедрение SQL-кода или

межсайтовая атака внедрением сценариев. Защититься от таких атак поможет

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

ограничения, отклонения и очистки. Выполняйте кодирование всех выходных данных,

отображаемых пользователю.

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

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

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

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

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

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

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

операций приложения.

 Разглашение сведений и утрата конфиденциальных данных. При проектировании всех

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

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

 Перебои в обслуживании из-за атак отказа в обслуживании (DoS). Сократите время

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

предотвращения подобных атак.

Обеспеченность технической поддержкой

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

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

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

 Недостаток диагностических сведений. Примите решение о том, как будет

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

программное обеспечение системного мониторинга, такое как Microsoft System Center.

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

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

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

подробные операционные и функциональные отчеты. Предусмотрите сбор данных

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

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

обслуживания и отладки.

 Отсутствие трассировки. С помощью обычных компонентов обеспечьте поддержку

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

программирования (Aspect Oriented Programming, AOP) или внедрения зависимостей.

Включите трассировку в Веб-приложениях для выявления ошибок.

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

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

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

инструментированию управления. Реализуйте инструментарий, такой как счетчики

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

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

событий, файлы трассировки или Инструментарий управления Windows (WMI).

Отслеживайте и собирайте достаточное количество сведений об ошибках и

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

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

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

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

Тестируемость

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

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

критерию. Тестируемость означает, что сбои в системе могут быть своевременно и эффективно

изолированы. Рассмотрим основные проблемы, связанные с тестируемостью:

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

связей в логике работы, вероятно, из-за невозможности автоматизированного или

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

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

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

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

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

 Отсутствие планирования тестов. Начинайте тестирование в цикле разработки как

можно раньше. Используйте при тестировании фиктивные объекты и создавайте

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

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

тестов. Продумайте возможности автоматизации тестов взаимодействия с

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

требований.

 Несогласованность входных данных и результатов; несоответствие результатов

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