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

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

 Совместно используемые базы данных с разными схемами. Все пользователи

работают с одной базой данных, но имеют разные наборы предопределенных полей.

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

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

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

наполнению таблиц базы данных. Этот вариант наиболее полезен, если хранение

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

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

 Совместно используемые базы данных с совместно используемой схемой. Все

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

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

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

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

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

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

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

потребуются.

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

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

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

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

Недостатки

Отдельные базы

данных

Простота реализации.

Простота перевода приложения с локальной

к размещаемой среде.

Проще обеспечивать резервное

копирование, восстановление и мониторинг,

поскольку большинство существующих

инструментов работают на уровне базы

данных.

Высокая изоляция данных.

Общие таблицы модели

предметной области

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

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

Более высокие расходы на

оборудование.

Совместно

используемая база

данных с разными

схемами

Более низкое потребление памяти.

Большая плотность пользователей на

каждом отдельно взятом сервере.

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

же таблиц.

Необходимость в компоненте доступа к

данным, который перехватывает имена

таблиц.

Необходимость авторизации на уровне

пользователя для доступа к данным.

Меньшая изоляция.

Архивация и восстановление

представляют собой довольно

сложную задачу, требующую

специального решения.

Сложности с отслеживанием

действий пользователей.

Совместно

Более низкое потребление памяти (меньше

Меньшая изоляция; требуются

используемая база

данных с совместно

используемыми

схемами

объектов базы данных).

Большая плотность пользователей на

каждом отдельно взятом сервере.

дополнительные усилия для

обеспечения более высокой

изоляции.

Данные доступны всем

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

Архивация и восстановление

представляют собой довольно

сложную задачу, требующую

специального решения.

Сложности с отслеживанием

действий пользователей.

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

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

Однако, как правило, они поддерживают большее количество пользователей на каждый

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

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

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

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

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

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

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

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

собираются хранить очень большие объемы данных или имеют очень большое число

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

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

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

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

дополнительную плату для отдельных пользователей. В этом случае необходимо использовать

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

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

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

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

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

Безопасность данных

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

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

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

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

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

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

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

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

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

 Разрешения. Используйте списки управления доступом (ACL) для определения того,

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

данными.

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

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

стороне.

Шаблоны обеспечения безопасности данных

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

модели:

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

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

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

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

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

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

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

которые не имеют право делать этого. Каждый тенант (организация), работающий с

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

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

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

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

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

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

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

данных (по одной для каждого тенанта). Как альтернативный вариант от STS можно

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

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

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

 Безопасные таблицы базы данных (применяется к модели с отдельными базами

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

учетной записи тенанта доступ к таблице или другому объекту базы данных. В модели с

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

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

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

тенанту, ассоциированному с этой таблицей.

 Шифрование данных тенанта (применяется ко всем трем многотенантным моделям).

Защитите данные с помощью симметричного шифрования, и секретный ключ тенанта –

с помощью ассиметричного шифрования (с применением пары открытый/секретный

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

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

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

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

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

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

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

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

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

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

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

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

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

Хранение и расширяемость данных

Существует множество способов хранения размещаемых данных. Для реализации хранения

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

управления размещенными реляционными базами данных (hosted relational database

management systems, RDBMS) и нереляционное хранилище в облаке. Реляционные базы

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

транзакционных систем или приложений с интенсивным вводом/выводом. Также обычно

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

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

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

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

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

хранения данных, подключаемые к сети (network-attached storage, NAS). Сервисы данных часто

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

данных (включая и хранящиеся, и переданные данные).

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

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

хранения данных быстры, недороги и практически неограниченно масштабируемы. Могут

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

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

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

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

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

всегда могут гарантировать согласованность.

Хранилище Microsoft Azure (на момент написания данного документа находящееся на этапе

ранней предварительной версии

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

хранилища и доступных через REST API:

С 1 февраля 2010 года в промышленной эксплуатации (прим. научного редактора).

 Сервисы хранилища таблиц обеспечивают структурированное хранилище в форме

таблиц, но эти таблицы не имеют определенной схемы, вместо этого они включают

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

могут использоваться для работы с этими свойствами. Сервисы хранилища таблиц

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

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

которые можно найти в RDBMS, таких как объединения и внешние ключи.

 Сервисы хранилища больших бинарных объектов предлагают хранилище для

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

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

хранилища.

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

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

к учетной записи хранилища.

Основную сложность при использовании RDBMS представляет расширяемость схемы. Это

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

сборки приложения. Существует четыре подхода для расширения схем во время выполнения:

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

фиксированных именованных столбцов для каждой расширяемой сущности (каждой

таблицы). Количество фиксированных столбцов будет зависеть от природы сущности и

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

инкапсуляцию и абстракцию фиксированных именованных столбцов и таблиц

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

учтены следующие факторы:

◦ Фильтрация на основании расширяемых столбцов представляет проблему в

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

типов данных переменной длины, таких как varchar, для всех расширяемых

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

применением операторов <, > и =. Возможным решением является

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

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

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

полей определенного типа.

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

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

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

◦ Неправильная интерпретация базой данных значений null может привести к

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

расходованию пространства. Если один из тенантов расширяет только одно

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

в памяти будут разрастаться. В Microsoft SQL Server 2008 предлагается

модификатор для столбцов SPARSE (Разреженный), который помогает

несколько смягчить эту проблему.

 Собственные схемы. Этот шаблон используется в сочетании с многотенантной

моделью с разными схемами. Каждая схема принадлежит определенному тенанту и

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

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

следующие факторы:

◦ Этот подход требует инкапсуляции и абстракции слоя доступа к данным и

наличия обработчика запросов, хотя O/RM-инфраструктуры, такие как

Microsoft Entity Framework (EF) или инфраструктура с открытым исходным

кодом NHibernate, могут упростить реализацию. Больше сведений по

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

Дополнительные источники в конце этой главы.

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

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

плавающей точкой (не все столбцы строкового типа). Однако обновление

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

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

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

являются общими для всех тенантов).

◦ Фильтрация по расширенным столбцам при таком подходе более

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

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

данных.

 Таблица пар имя/значение. Этот шаблон позволяет потребителям расширять модель

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

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

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

подхода учитывайте следующие факторы:

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

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

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

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

◦ Работать приходится лишь с одной базой данных. Однако если рост числа

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

масштабироваться вертикально с секционированием тенантов для

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

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

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

 XML-столбцы. Этот шаблон позволяет потребителям расширять модель данных

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

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

учтите следующие факторы:

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

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

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

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

подходами.

◦ Тогда как применение XML-столбцов в базе данных обусловливает

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

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

◦ Для XML-столбцов можно определить индексы, но это вводит

дополнительную сложность и требует больше памяти для хранения.

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

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

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

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

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

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

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

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

регистрации (SSO) для локальных и всех внешних размещенных сервисов. Это сокращает

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

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

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

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

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

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

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

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

от механизма аутентификации.

Рис. 43

Модель удостоверений на основании утверждений на базе интегрированного сервиса

удостоверений

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

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

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

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

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

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

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

основанный на отраслевых стандартах, таких как WS-Trust и WS-Federation. Microsoft Geneva

Framework

и Geneva Server

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

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

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

Переименовано в Windows Identity Foundation или WIF (прим. научного редактора).

Переименовано в Active Directory Federation Services v2 или ADFS v2 (прим. научного

редактора).

 Если доступно подходящее хранилище удостоверений, используйте его для

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

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

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

доступного хранилища удостоверений, используйте такой сервис, как .NET Services

Access Control, интегрированный в Windows Live

, или решение от стороннего

производителя.

 Может возникнуть необходимость внесения изменений в утверждения,

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

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

системы преобразований для разных STS-механизмов пользователей. Уровень

преобразований обеспечит .NET Access Control Service, или его можно реализовать

самостоятельно с помощью Geneva Framework. Более подробная информация о Geneva

Framework представлена по адресу http://msdn.microsoft.com/en-

us/security/aa570351.aspx.

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

отличаться очень незначительно. Проблемы с совместимостью и возможностью

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

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

 Если решено создавать собственный STS, обеспечьте его защиту от атак. В этом сервисе

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

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

реализацию STS, которая способна обработать все предполагаемые объемы запросов.

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

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

Многотенантная архитектура

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

размещения, а также базы данных и системы баз данных (каждый тенант – это организация, в

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

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

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

настройку через конфигурацию. Существует четыре общих этапа перехода к эффективной

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

описываются в следующих разделах:

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

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

потребителей – предоставление им разных копий ПО. Более того, поскольку

В финальной версии .NET Access Control Services интерграция с Windows Live не

поддерживается (прим. научного редактора).

практически ничего не обеспечивает возможности настройки через конфигурацию,

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

кода расширения, собственных процессов и/или собственных расширений данных.

Хотя, технически, ПО поставляется как сервис (оно не выполняется локально у

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

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

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

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

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

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

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

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

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

идентичны. Разделение может быть либо виртуальным (виртуальные машины на

одном сервере), либо физическим (выполнение на разных компьютерах). Эта модель

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

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

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

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

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

 Многотенантная архитектура. UI может настраиваться для каждого тенанта в

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

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

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

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

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

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

 Масштабируемая архитектура. Такая архитектура поддерживает многотенантность и

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

Новые экземпляры ПО могут без труда добавляться в пул экземпляров для

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

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

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

появляется подсистема балансировки нагрузки тенантов (Tenant Load Balancer)

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

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

ресурсов размещающей стороны, таких как ЦП и хранилище. Это означает, что общая

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

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

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

настраиваемой через конфигурацию.