Одно из основополагающих правил построения приложений гласит: разработчики не должны тратить свое время на построение инфраструктуры. Даже не смотря на то, что каждое приложение требует некоторую поддержку в виде сервисов, люди, которые разрабатывают эти приложения должны фокусироваться только на создании значимом для своих пользователей функционале. Какая бы не требовалась инфраструктура, он должна предлагаться платформой, для которой приложение строится.

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

Первый выпуск Windows Server AppFabric содержит две части (сегодня доступна версия 1.1 со множеством нововведений. — Прим. пер.):

Сервис AppFabric Caching Services, который позволяет ускорить доступ к часто используемым данным приложений
Сервис AppFabric Hosting Services, который позволяет упросить запуск и управление сервисами созданными на базе WCF и особенно созданными на базе Windows Workflow Foundation

Windows Server AppFabric предлагает расширения для роли Application Server и эти расширения бесплатны для использования вместе или раздельно. В этом введении рассматриваются обе части AppFabric.

AppFabric Caching Services

Одним из способов улучшить производительность и масштабируемость множества приложений является ускорение их доступа к данным. Например, для ASP.NET приложений легко создать масштабирование бизнес-логики: просто разместите несколько копий логики на разных серверах, а затем распределите между ними нагрузку. Улучшение этого аспекта производительности приложений может быть легко достигнут с помощью большего числа серверов.

Но в случае если все эти сервера зависят от одного сервера БД, доступ к данным может быстро стать узким местом вашей архитектуры. Добавление новых серверов не поможет, когда странице ASP.NET придется ожидать необходимые ей данные. Одно из решений запускать сервер БД на более мощной машине. Это может сработать, но и тут существуют ограничения: вам придется масштабироваться заменяя сервер на все более и более мощные машины и такая замена может стать слишком дорогостоящей. Что нам на самом деле нужно, так это способ масштабирования, при котором часто запрашиваемые данные были доступны на нескольких серверах, что позволит нам избежать узкого места в виде одного сервера.

Эффективный способ достижения этого — это создание распределенного кэша, который распространяет данные среди нескольких компьютеров. Вместо того, чтобы отсылать каждый запрос на один сервер БД, приложение ASP.NET сможет получить необходимые данные от одной из соседних машин. Нагрузка будет распределенной и приложение начнет работать быстрее. Это именно тот функционал, который предлагает сервис AppFabric Caching Services.

Как работает AppFabric Caching Services

Основным компонентом сервиса AppFabric Caching Services является клиент кэша, например страница ASP.NET, которая обращается к кластеру кэша содержащего некоторое количество серверов кэша. Каждый сервер кэша запускает экземпляр сервиса AppFabric Caching Services и поддерживает доступ к некоторому набору закэшированных данных. Каждый клиент кэша может так же поддерживать свой локальный кэш данных, используя специальные компоненты поставляемые вместе с AppFabric Caching Services. На рисунке 1 представлена схема всех компонентов:

clip_image001

Рис.1. Схема организации AppFabric Caching Services

Когда клиент кэша впервые получает некий кусок данных, например информацию переданную пользователем в ASP.NET-приложение или значения прочитанные из БД, клиент может сохранить эту информацию с уникальным именем в кластере кэша AppFabric Caching Services (или как будет рассказано далее, приложения ASP.NET могут сохранять информацию прозрачно через объект Session, так что даже не потребуется переписывать код у имеющегося приложения). Для клиента все остальные сервера кэша в кластере выглядят как одно большое хранилище — клиент никогда не знает и ему не нужно знать на каком из физических серверов хранятся его закэшированные данные. По желанию, клиент может сохранять данные и у себя в локальном кэше.

Когда клиенту снова требуется получить доступ к тем же данным, он запрашивает их через указанное уникальное имя. Этот запрос проверяет локальный кэш (если такой есть). Если данные найдены, то клиент использует их из локального кэша. Если данных нет в локальном кэше, запрос отправляется в кластер кэша. Если данные есть в кластере, клиент использует их. Весь этот процесс прозрачен для клиента, он просто отправляет запрос и AppFabric Caching Services берет на себя все остальное. В случае, если данные не были найдены в кластере кэша, клиенту придется запрашивать данные в БД.

Сервис AppFabric Caching Services на этапе разработки носил кодовое имя "Velocity", имя которое точно определяет что этот сервер делает: он позволяет сделать повторяющиеся запросы к данным быстрее. Вместо того чтобы делать множество однотипных запросов к БД, этот сервис позволяет получить данные прямо из локальной или распределенной памяти. Для приложений, которые часто запрашивают одинаковые данные, а таких очень много, кэширование значительно улучшает производительность и масштабируемость.

Сервис AppFabric Caching Services спроектирован для использования с .NET-приложениями, так что кэшируемые данные могут быть сериализованы в объект .NET. Поместив однажды объект в кэш, клиент может затем обновить его или удалить из кэша. Сохраненные в кэше элементы так же могут быть удалены из кэша самим сервисом по причине истечения срока хранения или в связи с необходимостью разместить в кэше более актуальные данные. Данные в локальном кэше могут так же устаревать, кроме того для локальных данных может быть установлена синхронизация с такими же данными из распределенного кэша для внесения изменений и синхронного удаления.

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

Кэширование полезно при работе с разными типами данных. Например, кэширование весьма полезно при работе с неизменяемыми во времени данными, которые запрашиваются разными клиентами (информация о каталоге онлайн-поставщика). Другой хороший пример использования кэширования — это хранение изменяемых данных, которые однако потребляются только одним клиентом, например, информация о сессии ASP.NET. И снова, этот пример описывает случай когда проблемы управления одновременным доступом к кэшированным данным не возникает.

Но что насчет того, когда данные, которые постоянно изменяются должны одновременно потребляться большим числом клиентов? Кэширование может быть использовано и в этом случае, но с одной оговоркой: необходим контроль за одновременным доступом. Для того, чтобы адресовать эту проблему сервис AppFabric Caching Services поддерживает оба оптимистичный контроль одновременного доступа основанный на назначении номера версии и пессимистичный контроль одновременного доступа использующий явные блокировки.

Сценарий: использование кэширования в приложении ASP.NET

Приложения ASP.NET являются наиболее важными клиентами для сервиса AppFabric Caching Services. Как было сказано ранее, данные хранимые в объекте сессии ASP.NET самый очевидный кандидат для кэширования. На самом деле сервис предлагает встроенную поддержку для этого — разработчику необходимо только задать опции конфигурации и объект сессии будет прозрачно сохраняться в кластере кэша. Обратите внимание: это означает, что разработчики ASP.NET могут получить преимущества распределенного кэширования без модификации кода их приложения. Это позволяет использовать несколько копий веб-серверов с запущенными экземплярами приложения ASP.NET без использования SQL Server для хранения данных сессии. На рисунке 2 показано как этот механизм работает:

clip_image002

Рис.2. Схема работы ASP.NET-приложения с AppFabric Caching Services

Этот простой сценарий начинается с того, что пользователь отправляет некоторую информацию, которую ASP.NET сохраняет в пользовательский объект сессии (шаг 1). Веб-сервер, который обрабатывает запрос, сконфигурирован так, чтобы кэшировать объекты сессии в кластере AppFabric Caching Services и поэтому пользовательские данные записываются в один или более серверов кэша (шаг 2). Следующий запрос от пользователя основывается на данных, сохраненных на шаге 1, но этот запрос обрабатывается уже другим сервером (шаг 3). Код ASP.NET на этом сервере обращается к тому же объекту сессии, что на деле означает прозрачный доступ к кластеру кэша для доступа к данным (шаг 4). Это позволяет информации полученной на шаге 1 быть доступной для приложения. Обратите внимание, что нам не пришлось оперировать с БД для хранения информации, а так же нам не требуется чтобы запросы пользователя обрабатывал один и тот же сервер. Результат работы этой инфраструктуры — повышенная производительность и улучшенная масштабируемость ASP.NET-приложения.

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

Сервис AppFabric Caching Services сохраняет все данные в памяти — они не записываются на диск. По умолчанию, каждый кэшируемый объект хранится только на одной машине в кластере кэша. Для того, чтобы увеличить надежность, в случаях когда сервер становится недоступным, AppFabric Caching Services предлагает поддержку механизма высокой доступности. Этот механизм позволяет создавать дублируемые копии кэшированных данных на других машинах в кластере кэша. Если сервер кэша, который хранит первичную копию данных, становится недоступным, то данные будут получены из вторичного хранилища. Рисунок 3 демонстрирует всю идею:

clip_image003

Рис.3. Высокая доступность AppFabric Caching Services

В этом примере, механизм высокой доступности выключен, так что каждый элемент кэшируемых данных сохраняется в двух разных серверах кэша. Первичная копия, показанная на рисунке в виде залитой фигуры, принимает все изменения с данными. Эти изменения автоматически реплицируются на вторичную копию, представленную в виде пустой фигуры. Здесь, сервер кэша содержащий первичную копию данных X становится недоступным (запланированно или случайно, шаг 1). Когда клиент кэша запрашивает данные X (шаг 2) кластер кэша скрытно перенаправляет запрос к вторичной копии и возвращает значение (шаг 3).

Этот пример показывает чтение данных, но и запрос на обновление будет точно так же обработано, когда сервер кэша с первичными данными будет недоступным. Как только AppFabric Caching Services определяет, что сервер с первичными данными недоступен, существующий сервер со вторичными данными становится первичным плюс создается новая вторичная копия на одном из доступных серверов. Все это прозрачно для клиента, просто работает так как будто с серверами ничего не происходило.

Независимо от того используется или нет механизм высокой доступности, сервис AppFabric Caching Services позволяет ускорить доступ к часто запрашиваемым данным. Это очень полезный функционал расширяющий имеющую инфраструктуру Windows Server.

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

Начало, продолжение следует.

Введение в Windows Server AppFabric. Сервис Caching Services