Статьи

Кэширование Windows Azure (предварительная версия) и облачные службы Ruby

Октябрь 12, 2018

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

Другая интересная особенность этого кэша заключается в том, что он поддерживает проводной протокол Memcache, поэтому к нему может обращаться любой клиент Memcache. Вы можете узнать больше о новой функции кэширования в Windows Azure Caching (Preview) .

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

Примечание . На момент написания этой статьи биты, необходимые для включения кэширования, были доступны только в Windows Azure SDK для .NET . Поэтому вам нужно будет установить его, чтобы успешно использовать кэширование из облачной службы Windows Azure.

Кэширование предварительного просмотра битов

Первое, что вам нужно, это Windows Azure SDK для .NET . В настоящее время это (2/2/2012) единственный Windows Azure SDK, который содержит биты, необходимые для включения кэширования в облачной службе. Вы можете узнать, установлены ли эти биты, проверив каталог для кэширования в C: \ Program Files \ Microsoft SDKs \ Windows Azure.NET SDK \ 2012-06 \ bin \ plugins .

Эти файлы используются как в локальном эмуляторе Windows Azure, так и при упаковке и развертывании приложения в Windows Azure.

Совмещенный против посвященный

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

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

Пример совместного размещения

В ServiceDefinition выполните следующие шаги:

  1. Импортируйте модуль кэширования:

    <Imports>      
	<Import moduleName="Caching"/>
</Imports>

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

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

    <LocalStorage cleanOnRoleRecycle="false" name="Microsoft.WindowsAzure.Plugins.Caching.FileStore" sizeInMB="1000"/>

    Эта запись идет внутри записи LocalResources.

  3. Добавьте конечную точку, которую клиент будет использовать для доступа к кешу по протоколу Memcache. Так как мы собираемся использовать кеш из нашего приложения, а не выставлять его в Интернете, это должен быть InternalEndpoint:

    <InternalEndpoint name="memcache_default" protocol="tcp">
       <FixedPort port="11211"/>
</InternalEndpoint>

    Эта запись входит в раздел EndPoints.

<Setting name="Microsoft.WindowsAzure.Plugins.Caching.NamedCaches" value="" />
<Setting name="Microsoft.WindowsAzure.Plugins.Caching.Loglevel" value="" />
<Setting name="Microsoft.WindowsAzure.Plugins.Caching.CacheSizePercentage" value="30" />
<Setting name="Microsoft.WindowsAzure.Plugins.Caching.ConfigStoreConnectionString" value="" />

Они определяют параметры конфигурации для кэша:

  • NamedCache позволяет вам создавать несколько кэшей, которые имеют отдельные конфигурации, такие как время жизни, политики удаления и т. Д. Для получения дополнительной информации см. Раздел « Именованные кэши» в разделе « Обзор кэширования Windows Azure (предварительный просмотр)» .

  • Уровень логирования используется для указания уровня информации, регистрируемой в целях диагностики. Сведения о настройке уровня журнала см. В разделе « Устранение неполадок и диагностика для кэширования Windows Azure (предварительный просмотр)» .

  • CacheSizePercentage — это процент памяти в роли, который должен быть выделен для кэша. Дополнительные сведения см. В разделе Вопросы планирования емкости для кэширования Windows Azure (предварительный просмотр) .

  • ConfigStoreConnectionString указывает учетную запись хранения. При использовании эмулятора используется файл ServiceConfiguration.local.cscfg , поэтому для этого файла должно быть установлено значение «UseDevelopmentStorage = true» . При развертывании в Windows Azure это должно указывать на действительную учетную запись хранения, поэтому значение будет выглядеть примерно так: «DefaultEndpointsProtocol = https; AccountName = YOURSTORAGEACCOUNT; AccountKey = YOURSTORAGEACCOUNTKEY» .

Вот и все. Вы готовы использовать кеширование из вашего приложения. Для своих тестов я использовал драгоценный камень Далли со следующим кодом:

require 'sinatra'
require 'dalli'

set :server, :thin
set :port, ENV['PORT']
set :bind, ENV['ADDRESS']

dc = Dalli::Client.new('localhost:11211')
dc.set('message', 'Hello World!')

get '/' do
  dc.get('message')
end

Шим против не-шим

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

В вашей роли может быть загружена оболочка, которая обрабатывает этот перевод до того, как запрос достигнет шлюза, что повышает производительность по сравнению с использованием только одного шлюза. Оболочка распространяется как Windows Azure Caching Memcache Shim , которая представляет собой пакет NuGet. Насколько я знаю, вы можете использовать пакеты NuGet только в проекте Visual Studio.

Вы можете прочитать больше об этом в теме Memcache Wrapper для Windows Azure Caching (Preview) , и Саймон Дэвис опубликовал пример проекта использования этой оболочки с облачным сервисом Node.js. Вы можете найти этот проект NodeCacheExample на GitHub.

Резюме

Несмотря на то, что вышесказанное в значительной степени является хаком, чтобы заставить предварительный просмотр кэширования работать с облачным сервисом Ruby, я подозреваю, что после того, как он выйдет из предварительного просмотра, его будет немного легче включить для приложений, не являющихся .NET. Кроме того, вышеприведенные адреса используются только в кеше; Я продолжу исследовать, как реализовать выделенное решение для кэширования, и опубликую свои выводы в блоге.

Полный пример решения с использованием совмещенного кэша см. В ветке совмещенного кэша проекта RubyRole.

 

34
Share: