Проектирование архитектуры мультитенантных приложений в Windows Azure

Существует большая и динамичная экосистема провайдеров сервисов, которые упаковывают решения и размещают их на облачных платформах. По большей части, эти компании придерживаются концепции Software as a Service (SaaS) и используют мультитенантные архитектуры (multi-tenant architectures). Массу примеров из практики вы найдете по ссылке bit.ly/vIPcyc. Если поразмыслить, большинство популярных приложений в Web, например Facebook или Hotmail, являются мультитенантными приложениями. Этот подход имеет смысл с точки зрения бизнеса, потому что вычислительные ресурсы и хранилища можно использовать максимально полно за счет их разделения между множеством подписчиков. В конце концов, одна из основных причин применения облачных вычислений заключается в том, чтобы добиться максимальной эффективности, предоставляя возможность совместного использования большого пула вычислительных ресурсов и хранилищ.

Мы часто получаем по почте вопросы, связанные с наиболее эффективной реализацией и шаблонами мультитенантных архитектур на платформе Windows Azure. И это первая из двух статей, в которой мы ознакомим вас с некоторыми ключевыми концепциями и принципами, а также дадим ряд рекомендаций.

Концепция мультитенантного ПО довольно проста. Это единая всеобъемлющая система, которая поддерживает множество клиентских организаций (тенанты), где каждый тенант изолирован и работает параллельно, используя одно и то же аппаратно-программное обеспечение и абсолютно ничего не зная о других тенантах. При должной реализации данная концепция позволяет провайдерам сервисов предлагать обширную функциональность тенантам, в то же время чрезвычайно эффективно используя Windows Azure. Суть тенантов в безопасности, низкой стоимости и хорошей производительности.

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

• идентификацию и защиту;
• изоляцию и разделение (segregation) данных;
• анализ производительности и учет;
• адаптивное масштабирование при сохранении условий, согласованных в SLA.

Первые две части мы обсудим в этой статье, а остальные две — в следующей.

Идентификация

Идентификация занимает центральное место в мультитенантных архитектурах. У тенантов должна быть гарантия, что их конфиденциальные данные не будут доступны другим пользователям, кроме случаев, в которых целью является предоставление данных подписчикам. Пример — Microsoft SharePoint. У вас могут быть документы, видимые только конкретному тенанту, но могут быть и какие-то документы, общие для некоей рабочей группы (двух или более тенантов, которые могут охватывать несколько организаций). Вывод: идентификация играет центральную роль в доступе к данным.

В современном мире системы управления идентификациями должны быть взаимозаменяемыми, придерживаясь открытых стандартов (установленных Organization for the Advancement of Structured Information Standards [OASIS]), таких как WS-Trust и WS-Security. Вместе эти стандарты позволяют мультитенантным системам выполнять защищенный обмен сообщениями между тенантом и провайдером сервисов, чтобы распознавать их присутствие и выступать в роли посредников доверительных отношений между этими сущностями. Более того, мультитенантные архитектуры, как правило, поддерживают несколько провайдеров идентификации, например Google, Facebook, Yahoo! и Microsoft Live. В более сложных сценариях провайдеры сервисов будут поддерживать корпоративные средства идентификации, такие как Active Directory. Также важна поддержка единого входа (single sign-on, SSO).

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

По общему признанию, подходы на основе заявок (claims-based) к управлению идентификациями обеспечивают максимальные преимущества. Для новичков поясним, что при таких подходах разрозненные части идентификации объединяются в один абстрактный маркер, состоящий из заявок и эмитента (issuer) или полномочного органа (authority). Ценность таких подходов в том, что они базируются на открытых стандартах и обеспечивают высокую степень взаимодействия и совместимости. Управление идентификациями на основе заявок позволяет провайдерам сервисов отделять приложения от огромного объема низкоуровневого кода инфраструктуры управления идентификациями. Поддержка стандартов веб-сервисов (WS-Trust, WS-Federation, WS-Security), форматов маркеров (Security Assertion Markup Language [SAML], JSON Web Key [JWK], Simple Web Token [SWT]) и шифрования (X.509) — дело весьма нетривиальное. В конце концов, эти стандарты постоянно развиваются, поэтому крайне важно инкапсулировать и абстрагировать управление идентификациями.

Ответ на все эти вызовы — Windows Azure Active Directory Access Control Service (ACS), который радикально упрощает реализацию системы управления идентификациями на основе заявок. ACS избавляет вас от всей низкоуровневой инфраструктуры и исключает ее из кода провайдера сервисов, что позволяет сравнительно легко реализовать систему управления идентификациями на основе заявок. Мощь ACS заключается в том, что большая часть работы может быть выполнена через веб-портал. Кроме того, ACS значительно упрощает подготовку новых тенантов.

Это означает, что разработчику не нужно иметь дела со многими сложностями управления идентификациями внутри своего приложения. ACS решает трудные, отнимающие много времени задачи, в частности:

• перенаправление неаутентифицированных запросов выбранному провайдеру идентификации;
• проверку входного маркера, выданного провайдером идентификации;
• разбор входного маркера (чтение заявок);
• реализацию проверок авторизации;
• преобразование маркеров добавлением, удалением или изменением типов и значений заявок.

Мы рекомендуем для начала прочитать пару онлайновых учебников. Хороший учебник по аутентификации пользователей вы найдете по ссылке bit.ly/uyDLkt. Если вы работаете в Visual Studio 2012, вам будет очень полезна публикация Витторио Берточчи (Vittorio Bertocci) в четырех частях (bit.ly/12ZOwN9). Инструментарий Visual Studio продолжает совершенствоваться, освобождая разработчиков от редактирования конфигурационных файлов вручную. Соответствующий инструментарий и пакеты SDK можно скачать по ссылке bit.ly/NN9NVE.

На рис. 1 показан тенант с поддержкой нескольких провайдеров идентификации.

Рис. 1. Поддержка нескольких провайдеров идентификации

На рис. 2 показано, что происходит на самом деле при использовании ACS. Тенанты абсолютно ничего не знают о том, что ACS выполняет всю работу. Рабочий процесс, представленный на рис. 2, заканчивается тем, что ваше мультитенантное приложение получает маркер защиты, обычно в формате SAML 2.0. Маркер, получаемый вашим мультитенантным приложением, стандартизован независимо от провайдера идентификации, выбранного тенантом. ACS прозрачно посредничает в ходе преобразования специфичного для конкретного провайдера формата маркера в формат, указанный вами на портале ACS.

Рис. 2. Высокоуровневое представление портала Access Control Service

Identity Providers	Провайдеры идентификации
Windows Live Google Yahoo! Facebook AD FS 2.0 OpenID	Windows Live Google Yahoo! Facebook AD FS 2.0 OpenID
Windows Azure	Windows Azure
Access Control Service	Access Control Service
Security Token Service	Security Token Service
Management API	API управления
Tenant/Client	Тенант/клиент
Browser	Браузер
Multi-Tenant App, Services Provider or Relying Party	Мультитенантное приложение, провайдер сервисов или доверяющая сторона

JavaScript-код запрашивает у ACS список провайдеров идентификации, которых должно поддерживать ваше приложение, а затем генерирует ссылки входа для каждого из провайдеров. Все перенаправления, необходимые для получения вашим приложением стандартного маркера защиты, обрабатываются системой. Доверяющая сторона (relying party) — это просто ваше мультитенантное приложение, так как оно полагается на то, что эмитент предоставит информацию об идентификации.

Если вы прошли онлайновые учебные ресурсы, упомянутые ранее, то увидите экран, приведенный на рис. 3. Часть Getting Started портала ACS поделена на четыре раздела, что упрощает интеграцию системы управления идентификациями в облачное мультитенантное приложение. В разделе 1 вы можете выбрать из списка те провайдеры идентификации, которые вы хотите поддерживать. В данном случае мы выберем Google, Microsoft Live ID и Yahoo!. Приложив чуть больше усилий, вы могли бы также включить идентификации Facebook и Active Directory. Раздел 2 — то место, где осуществляется связывание. Здесь вы указываете URL, на который ACS возвращает маркер защиты; обычно это начальная страница приложения. ACS нужна конечная точка, в которую он будет передавать маркер в требуемом формате. В этом же разделе задается формат маркера.

Рис. 3. Портал Windows Azure ACS

В разделе 3 вы выбираете заявки, которые провайдер идентификации должен включать в маркер защиты. Доверяющая сторона (мультитенантное приложение провайдера сервисов) будет использовать эти заявки как для уникальной идентификации тенанта, так и для принятия решений по авторизации, определяя привилегии тенанта в рамках сервиса. Доступные заявки зависят от конкретного провайдера идентификации; например, Google отличается в этом отношении от Windows Live. С помощью Google и Yahoo! заявки в маркере могут включать адрес электронной почты, имя пользователя, идентификатор имени (nameidentifier) и название провайдера. Однако в случае Microsoft Live ID вы получаете только идентификатор имени и название провайдера, но не адрес электронной почти или имя пользователя. Вам понадобится обрабатывать эти тонкости в своем приложении.

Раздел 4 позволяет интегрировать в сервис некоторые метаданные и код. Это делается в Visual Studio. Метаданные в конфигурационных файлах вашего приложения понадобятся для его связывания с ACS. Инструментарий Visual Studio 2012 предельно упрощает этот этап (достаточно указать нужное), тогда как в Visual Studio 2010 вам придется вручную редактировать раздел sytem.web файла web.config.

Недавно Microsoft выпустила Windows Azure Active Directory, что дает возможность задействовать преимущества Web SSO в ваших бизнес-приложениях (line-of-business, LOB) — на предприятии и в облаке. Если ваша цель — реализовать управление идентификациями в LOB-приложении, выполняемом как на предприятии, так и в облаке, то вам следует прочитать информацию по ссылке bit.ly/157yVPR. В этой документации демонстрируется, как включить существующее LOB-приложение в Windows Azure Active Directory и сделать его доступным администраторам других тенантов Windows Azure Active Directory для применения в своих организациях.

В ранее упомянутой публикации Берточчи в блоге приведен экран Identity and Access, который показан на рис. 4; его можно использовать для добавления конфигурационного кода в мультитенантное приложение. Visual Studio 2012 полностью исключает необходимость в ручном редактировании любых конфигурационных файлов. Как видите, мы выбрали три провайдера идентификации и определили область (realm) и URL возврата для мультитенантного приложения. Область — это просто URI, идентифицирующий приложение, в которое входит пользователь. Этот URI также позволяет сопоставлять заявки для приложения и адреса для приема ответов (reply-to addresses). Вы измените область и URL возврата, как только развернете свое приложение в информационном центре Microsoft. Наконец, вы добавите ключ управления (management key), полученный с портала ACS для цифровой подписи маркеров в целях безопасности.

Рис. 4. Диалоговое окно Identity and Access в Visual Studio 2012

Добавление кода в приложение

Мультитенантным приложениям нужно сохранять вошедшего пользователя в постоянном хранилище. Изначально это требуется для процесса подготовки (provisioning process), но может понадобиться и в том случае, если отслеживаются операции тенанта. В этой статье в качестве хранилища данных используется Windows Azure SQL Database, но вы могли бы легко сменить его на Windows Azure Tables, а также включить хранилища данных, размещенные на предприятии. В методе Page_Load в файле Default.aspx.cs мы можем читать маркер защиты и разбирать заявки:

protected void Page_Load(object sender, EventArgs e)
{
  // Получаем объект ClaimsIdentity. Считайте его маркером
  // и набором заявок для текущего вошедшего пользователя.
  ClaimsIdentity ci =
    Thread.CurrentPrincipal.Identity as ClaimsIdentity;
  // Создаем объект TenantTokenManager, разбирающий заявки
  TenantTokenManager tenantTokenManager = new TenantTokenManager(ci);
  // Сохраняем этого пользователя в постоянном хранилище
  tenantTokenManager.SaveTenantToDatabase();
}

Чтобы инкапсулировать эту логику, мы добавим в свой облачный проект класс TenantTokenManager, показанный на рис. 5.

Рис. 5. Класс TenantTokenManager

public class TenantTokenManager
{
  // Заявки, уникально идентифицирующие тенанты
  public System.Security.Claims.ClaimsIdentity SecurityToken { get; set; }
  public string IdentityProviderName                          { get; set; }
  public string IdentityProviderNameIdentifier                { get; set; }
  public string IdentityProviderEmail                         { get; set; }
  public string TenantId                                      { get; set; }
  public string TenantName                                    { get; set; }
  public TenantTokenManager(System.Security.Claims.ClaimsIdentity ci)
  {
    try
    {
      // Сохраняем копию маркера защиты - ClaimsIdentity
      this.SecurityToken = ci;
      // Получаем имя провайдера
      //(Yahoo, Google, Microsoft Live)
      IdentityProviderName = (from c in ci.Claims
        where c.Type ==
          "http://schemas.microsoft.com/accesscontrolservice/
        2010/07/claims/identityprovider"
        select c.Value).SingleOrDefault();
      // Получаем идентификатор имени (уникальный идентификатор
      // тенанта от провайдера идентификации)
      IdentityProviderNameIdentifier = (from c in ci.Claims
        where c.Type ==
	 "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
        select c.Value).SingleOrDefault();
      // Получаем адрес электронной почты (недоступен в Microsoft Live ID)
      IdentityProviderEmail = (from c in ci.Claims
        where c.Type ==
          "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
        select c.Value).SingleOrDefault();
      // Создаем уникальный TenantId на основе
      // идентификатора имени и названия провайдера
      TenantId =
IdentityProviderName + "-" + IdentityProviderNameIdentifier;
      // Получаем имя пользователя из маркера защиты
      // (недоступно в from Microsoft Live ID)
      TenantName = SecurityToken.Name ==
	null ? "Not Avail." : SecurityToken.Name;
    } catch (Exception ex) { throw ex; }
  }
  public void SaveTenantToDatabase() {
    IdentityDataStore.SaveTenantToDatabase(this);
  }
}

Класс TenantTokenManager инкапсулирует две важные функции. Он разбирает заявки из маркера защиты, формат которого в нашем случае — SAML, но он мог бы быть JWT или SWT. Заметьте, что для выборки индивидуальных заявок из маркера можно использовать простые LINQ-запросы. И обратите внимание на то, что в случае Microsoft Live ID нельзя получить ни имени пользователя, ни адреса электронной почты. Соответственно для этого провайдера LINQ-запрос возвращает вместо имени и адреса null-значения. Комментарии в коде поясняют, что означают те или иные заявки. Мы также добавили поддержку для сохранения данных в TenantTokenManager с помощью метода SaveToDatabase, поэтому тенанты можно подготавливать и отслеживать.

Следующий логический этап в приложении — принятие решений по авторизации на основе идентификации или членства идентификаций в ролях. Например, как показано на рис. 6, хранимая процедура возвращает записи только на основе TenantId. Это иллюстрирует, как можно приступить к изоляции и разделению данных.

Рис. 6. Хранимая процедура, которая возвращает записи на основе TenantId

CREATE PROCEDURE [dbo].[GetTenantData]
  @TenantId nvarchar(max)
AS
BEGIN
  SELECT
    [id],
    [TenantId],
    [TenantName],
    [ProviderName],
    [NameIdentifier],
    [Email],
    [SomeTenantData1],
    [SomeTenantData2]
  FROM TenantRecords
  WHERE TenantId = @TenantId
  return;
END

Изоляция и разделение данных

Когда дело доходит до объединения идентификации с данными в мультитенантной системе, приходится решать ряд существенных задач. Первым делом архитектор должен определить, как хранить конфиденциальные данные полностью изолированными от других тенантов. Очевидно, что никоим образом нельзя допускать компрометации таких вещей, как номера кредитных карт, личные номера в системе социального страхования, электронная почта и др. У каждого тенанта должна быть абсолютная гарантия того, что его данные недоступны посторонним. В то же время какие-то данные должны быть общими среди тенантов, например общие календари, фотоснимки или простые текстовые сообщения. Другая задача — подготовка аудиторских журналов (audit trails), на основании которых провайдеры сервисов могут отслеживать шаблоны использования и входа тенантов. Это позволяет организациям отслеживать изменения, вносимые пользователями уровня администраторов, чтобы упростить устранение неожиданного поведения приложения.

В любой мультитенантной системе возникает дополнительная техническая проблема: провайдер сервисов должен иметь возможность добиться максимальной экономичности, в то же время обеспечив тенантов эффективно работающими и гибкими сервисами и моделями данных. Эта проблема особенно трудна из-за многообразия типов данных. Учтите, что только Windows Azure поддерживает множество вариантов хранилищ, таких как таблицы, большие двоичные объекты (blobs), очереди, SQL Database, Hadoop и др. Эта проблема важна для провайдера сервисов, поскольку каждый тип хранилища отличается очень существенно. Архитекторам нужно сбалансировать стоимость, производительность, масштабируемость и в конечном счете потребности тенантов в данных.

Давайте кратко рассмотрим четыре распространенных типа хранилищ в Windows Azure. Большие двоичные объекты (blobs) (далее просто двоичные объекты) используются для хранения неструктурированных двоичных и текстовых данных. Как правило, это изображения, аудио или другие объекты мультимедиа, хотя иногда в таком виде хранится исполняемый двоичный код. Очереди служат для хранения сообщений, которые могут быть доступны тенанту. Они обеспечивают надежный обмен сообщениями с масштабируемыми экземплярами мультитенантного приложения. Таблицы предлагают средства NoSQL приложениям, требующим хранения огромных объемов неструктурированных данных. Наконец, SQL Database обеспечивает приложениям, которым это нужно, полнофункциональную реляционную базу данных как сервис — Database as a Service (DBaaS).

Двоичные объекты Они относительно просты в понимании по сравнению с Windows Azure Tables или SQL Database. Подробнее о них вы можете прочитать по ссылке bit.ly/VGHszH. Учетная запись Windows Azure может иметь много контейнеров двоичных объектов (blob containers). А такой контейнер может содержать много двоичных объектов. У многих провайдеров сервисов более одной учетной записи. При типичном подходе указывают имя контейнера для каждого тенанта. Это позволяет определять права доступа, измерять производительность и количественно оценивать использование сервиса двоичных объектов. Недавно Microsoft переработала сетевую топологию, чтобы резко увеличить пропускную способность между вычислительными ресурсами и ресурсами хранилищ для поддержки узлов хранения данных, взаимодействующих по сети на скоростях до 10 Гбит/с. Подробнее об этом см. по ссылке bit.ly/PrxhAW.

Соглашение по именованию для больших двоичных объектов может вынудить вас поддерживать карту сопоставлений имен контейнеров с идентификаторами TenantId. Вы можете использовать адреса электронной почты, потому что они уникальны, но Windows Live ID не предоставляет соответствующую заявку в маркере защиты. В случае Google и Yahoo! нужно удалять знаки «@» и «.», так как контейнеры двоичных объектов могут содержать только буквы, числа и различные виды тире.

Код на рис. 7 демонстрирует подход к подготовке контейнеров двоичных объектов. Этот код мог бы быть частью процесса регистрации и подготовки для тенанта. Заметьте: в качестве имени контейнера используется TenantId. Конечно, на практике у вас будет какая-то таблица поиска (lookup table), которая предоставляет имена контейнеров по идентификаторам TenantId. В коде на рис. 7 мы предпочли, чтобы у провайдера сервисов была отдельная учетная запись Windows Azure (AccountTenantImages) для хранения изображений, принадлежащих тенантам. Обратите внимание на выражение «blobClient.GetContainerReference(tm.TenantId)» — именно в нем подготавливается контейнер двоичных объектов для нового тенанта.

Рис. 7. Подготовка контейнера двоичных объектов для тенанта

// Получаем объект ClaimsIdentity. Считайте его маркером
// и набором заявок для текущего вошедшего пользователя.
ClaimsIdentity ci =
  Thread.CurrentPrincipal.Identity as ClaimsIdentity;
// Разбираем заявку
TokenManager tm = new TokenManager(ci);
// Получаем учетную запись хранилища из строки подключения
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
  Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting(
  "AccountTenantImages"));
// Создаем клиент двоичных объектов
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
// Извлекаем ссылку на контейнер
CloudBlobContainer container = blobClient.GetContainerReference(tm.TenantId);
// Создаем контейнер, если его еще нет
container.CreateIfNotExists();

Другой важный момент — двоичные объекты поддерживают пользовательские метаданные, а значит, каждый такой объект может поддерживать одну или более пар «имя-значение». Однако хранилище двоичных объектов не позволяет запрашивать у двоичных объектов их метаданные на глобальном уровне. Найти информацию в метаданных можно двумя способами. Первый — извлечь все двоичные объекты из контейнера, а затем перебрать их в поисках пар «имя-значение». Более масштабируемый подход — хранить метаданные в хранилище таблиц вместе с URL двоичных объектов. Это позволяет запрашивать хранилище таблиц для поиска нужного двоичного объекта, а затем извлекать этот объект из хранилища и запрашивать метаданные непосредственно от этого объекта.

Очереди Поскольку очереди обычно применяются как механизмы, обеспечивающие надежный асинхронный обмен сообщениями внутри мультитенантных приложений, тенанты, как правило, отделяются от них. Прояснив этот момент, отметим, что учетная запись имеет много очередей, а очереди — много сообщений. Потенциально архитектор облака мог бы предоставлять отдельную очередь для каждого тенанта. Но это решение должно базироваться на специфических требованиях мультитенантного приложения. И учитывайте, что такой подход не дает хорошей масштабируемости и может создать массу сложностей в управлении, когда количество тенантов перевалит за 100.

Таблицы В Windows Azure Tables доступно много вариантов изоляции и разделения данных. Например, провайдер сервисов мог бы предоставлять по одной учетной записи хранилища на каждого тенанта. Поскольку каждая такая учетная запись появляется в вашем счете за пользование Windows Azure как строчный элемент, этот подход может оказаться полезным, если вы хотите выяснить точные расходы на каждого тенанта. Другой вариант — объединение нескольких тенантов под одной учетной записью хранилища. Этот подход позволяет группировать тенантов по географическому региону, по законодательным требованиям и потенциально по требованиям к репликации. Однако вам все равно понадобится создание уровней в схеме разбиения на разделы, чтобы тенанты под одной учетной записью не получали доступа к данным других тенантов (если только речь не идет о стратегиях совместного использования данных). Один из подходов к хостингу нескольких тенантов под одной учетной записью — включение TenantId в имя таблицы и присваивание каждому тенанту отдельной копии таблиц.

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

Код на рис. 8 демонстрирует, как несколько тенантов могли бы делить одну таблицу. Этот же код иллюстрирует, как тенант мог бы извлечь адрес электронной почты и телефонный номер, используя Windows Azure Tables. Заметьте, что PartionKey, по сути, является TenantId, который может быть производным от удостоверений входа (login credentials) — либо напрямую, либо через другую таблицу поиска.

Рис. 8. Разделение данных в Windows Azure Tables с применением PartionKey и RowKey

// Получаем объект ClaimsIdentity. Считайте его маркером
// и набором заявок для текущего вошедшего пользователя.
ClaimsIdentity ci =
  Thread.CurrentPrincipal.Identity as ClaimsIdentity;
// Разбираем заявку
TokenManager tm = new TokenManager(ci);
// Извлекаем учетную запись хранилища из строки подключения
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
  Microsoft.WindowsAzure.CloudConfigurationManager.GetSetting(
  "AccountTenantTables"));
// Создаем объект клиента облачной таблицы
CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
// Создаем объект таблицы с адресами электронной почты
CloudTable emailAddressTable =
  tableClient.GetTableReference("EmailAddressTable");
// Настраиваем фильтр для ключа раздела
string pkFilter = TableQuery.GenerateFilterCondition("PartitionKey",
   QueryComparisons.Equal, tm.TenantId);
// Настраиваем фильтр для ключа записи
string rkFilter = TableQuery.GenerateFilterCondition("RowKey",
  QueryComparisons.Equal, tm.IdentityProviderName);
// Комбинируем фильтры ключей раздела и записи
string combinedFilter = TableQuery.CombineFilters(rkFilter,
  TableOperators.And, pkFilter);
// Конструируем запрос
TableQuery<EmailAddressEntity> query =
  new TableQuery<EmailAddressEntity>().Where(combinedFilter);
// Выполняем запрос
EmailAddressEntity emailAddressEntity =
  emailAddressTable.ExecuteQuery(query).First();
// Извлекаем искомые данные и что-то делаем
// с emailAddress и phoneNumber
string emailAddress = emailAddressEntity.EMailAddress;
string phoneNumber = emailAddressEntity.PhoneNumber;

Заключение

Проектирование архитектуры мультитенантных приложений требует хорошего понимания вопросов идентификации, а также изоляции и разделения данных. Благодаря ACS провайдеры сервисов могут избавиться от необходимости написания большого объема низкоуровневого инфраструктурного кода, связанного с управлением идентификациями. В мультитенантном приложении можно поддерживать множество провайдеров идентификации и избежать затуманивания его кодовой базы инфраструктурным кодом с помощью некоторых из представленных здесь методов. Более того, отказоустойчивое управление идентификациями упрощает работу, необходимую для изоляции или совместного использования данных, принадлежащих тенантам.

В следующей статье мы рассмотрим остальные фундаментальные основы мультитенантных архитектур — измерения, анализ производительности и масштабирование. А тем временем мы советуем тем, кто заинтересован в более подробной информации, прочитать книгу «Developing Multi-Tenant Applications for the Cloud, 3rd Edition», доступную по ссылке bit.ly/asHI9I.