Экспорт (0) Печать
Развернуть все

Рекомендации по достижению максимальной масштабируемости и экономической эффективности решений с обменом сообщениями на основе очередей в Azure

Обновлено: Июль 2014 г.

Автор: Амит Шривастав (Amit Srivastava)

Редакторы: Брэд Кэлдер (Brad Calder), Сидни Хига (Sidney Higa), Кристиан Мартинес (Christian Martinez), Стив Маркс (Steve Marx), Курт Петерсон (Curt Peterson), Паоло Сальватори (Paolo Salvatori) и Трейс Янг (Trace Young)

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

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

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

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

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

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

  • Опрос (модель на основе опроса): прослушиватель производит мониторинг очереди, регулярно проверяя ее на наличие новых сообщений. Если очередь пуста, прослушиватель продолжает опрашивать ее, периодически переходя в режим сна.

  • Активация (модель на основе принудительной передачи): прослушиватель подписывается на событие, которое вызывается либо самим издателем, либо диспетчером службы очередей при поступлении сообщения в очередь. Прослушиватель, в свою очередь, может инициировать обработку сообщения. Таким образом, исключается необходимость в опросе очереди в ожидании новой работы.

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

noteПримечание
Операции вывода из очереди, поддерживаемые API службы очередей Azure, являются неблокируемыми. Это означает, что такие методы API, как GetMessage или GetMessages, будут завершаться немедленно, если в очереди нет сообщений. Очереди Azure Service Bus, напротив, предусматривают блокирующие операции получения, которые останавливают вызывающий поток до тех пор, пока в очереди не появится сообщение или не истечет заданное время ожидания.

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

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

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

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

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

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

Следующая блок-схема показывает логику, чаще всего применяемую при реализации прослушивателя очередей с механизмом опроса в приложениях Azure.

Рекомендации-по-решениям-для-обмена-сообщениями-Azure2
noteПримечание
В этой статье не будут рассматриваться более сложные шаблоны проектирования, например использующие центральный диспетчер очередей.

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

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

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

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

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

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

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

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

Расходы на хранение, связанные с очередью Azure, вычисляются следующим образом:

Объем очереди: 24 байта + Len(QueueName) * 2 +  For-Each Metadata(4 байта + Len(QueueName) * 2 байта + Len(Value) * 2 байта)

Объем сообщения: 12 байт + Len(Message)

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

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

  2. При получении сообщений из очереди объединяйте несколько сообщений в одну транзакцию в хранилище. Метод GetMessages в API службы очередей позволяет извлекать заданное число сообщений в рамках одной транзакции (см. примечание ниже).

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

  4. Сократите число прослушивателей очередей — при использовании модели на основе опросов создавайте только один прослушиватель на экземпляр роли, если очередь пуста. Чтобы сократить число прослушивателей каждого экземпляра роли до нуля, пользуйтесь механизмом уведомлений: это даст возможность создавать прослушиватели только тогда, когда в очередь поступают элементы.

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

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

  7. Сократите ожидаемые сбои, связанные с временем ожидания. При отправке запроса в службу можно задать собственное время ожидания, которое не будет превышать время ожидания SLA. В этом случае после истечения времени ожидания запроса ситуация классифицируется как ожидаемый таймаут и засчитывается как платная транзакция.

Большинство из вышеприведенных рекомендаций можно применить в базовой реализации, которая будет обрабатывать пакеты сообщений и инкапсулировать множество базовых операций по работе с очередями, большими двоичными объектами и потоками. Ниже в этой статье мы рассмотрим, как это сделать.

ImportantВажно!
При получении сообщений через метод GetMessages максимальный размер пакета (получаемого из очереди в составе одной операции вывода из очереди), поддерживаемый API службы очередей, составляет 32.

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

Если архитектор решений не применит соответствующие оптимизации, то архитектура системы выставления счетов, описанной выше, скорее всего, вызовет чрезмерные операционные расходы после развертывания и запуска решения на платформе Azure. Причины возможных чрезмерных расходов описаны в данном разделе.

Как отмечалось в определении сценария, бизнес-данные транзакции поступают через регулярные интервалы времени. Предположим, что решение занимается обработкой рабочей нагрузки всего 25 % времени в течение стандартного восьмичасового рабочего дня. Это приводит к тому, что в течение 6 часов (8 часов * 75 %) система простаивает из-за отсутствия транзакций. Более того, решение не будет получать никаких данных в течение 16 часов в нерабочие дни.

Все это время простоя — в общей сложности 22 часа — решение будет продолжать отправлять запросы на вывод данных из очереди, не зная, когда поступят новые данные. Во время этого временного окна каждый поток, выполняющий вывод из очереди, выполнит до 79 200 транзакций (22 часа * 60 мин * 60 транзакций/мин), если интервал опроса установлен в 1 секунду.

Как упоминалось выше, модель ценообразования на платформе Azure рассчитывается по отдельным «транзакциям в хранилище». Транзакция в хранилище — это запрос пользовательского приложения на добавление, считывание, обновление или удаление данных в хранилище. На момент написания данного технического документа транзакция в хранилище исчисляется по ставке 0,01 долл. США за 10 000 транзакций (без учета рекламных предложений и специальных соглашений).

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

Транзакции в хранилище, создаваемые одним потоком вывода из очереди в вышеописанном сценарии, добавят к месячному счету примерно 2,38 долл. США (79 200 / 10 000 * 0,01 долл. * 30 дней). Для сравнения: 200 потоков вывода из очереди (или по одному потоку на каждый из 200 экземпляров рабочей роли) повысят стоимость до 457,20 долл. США в месяц. Это расходы только на проверку очередей в ожидании работы, а не на выполнение самой вычислительной работы. Вышеприведенный пример является абстрактным, поскольку никто не станет реализовывать свою службу таким образом. Вот почему так важно использовать оптимизации, описанные выше.

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

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

В сложной распределенной системе при использовании такого подхода может возникнуть необходимость применения «шины сообщений» или «промежуточного слоя, ориентированного на сообщения», чтобы обеспечить надежную доставку уведомлений одному или нескольким слабосвязанным подписчикам. Azure Service Bus является естественным выбором при решении вопросов доставки сообщений между слабосвязанными распределенными службами приложения, работающими на платформе Azure и выполняющимися локально. Этот подход также прекрасно подходит для архитектуры «шина сообщений», которая позволяет обмениваться уведомлениями между процессами, участвующими в обмене данными на основе очередей.

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

Лучшие-решения-передачи-сообщений-Azure3

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

ImportantВажно!
Использование Azure Service Bus регулируется моделью ценообразования, которая учитывает объем операций по обмену сообщениями для отдельной сущности Service Bus, например очереди или раздела.

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

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

Если проблему задержек довольно просто решить с введением слоя обмена сообщениями публикации-подписки, то дополнительное сокращение затрат можно реализовать за счет применения динамического (эластичного) масштабирования, как описано в следующем разделе.

Хранилище Azure определяет цели масштабирования на общем уровне учетной записи и на уровне раздела. В Azure существует собственная, состоящая из одного раздела очередь, поэтому она может обрабатывать до 2 000 сообщений в секунду. Когда число сообщений превышает эту квоту, служба хранения выводит сообщение HTTP 503 — сервер занят. Это сообщение означает, что платформа регулирует очередь. Разработчики приложений должны выполнять планирование мощностей, чтобы соответствующее количество очередей могло выдерживать интенсивность запросов приложения. Если одна очередь не может справиться с частотой запросов, для обеспечения масштабируемости следует разработать архитектуру разделенной очереди с несколькими очередями.

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

Платформа Azure реализует для клиента возможность быстрого и простого масштабирования вверх и вниз. Возможность адаптации к меняющейся рабочей нагрузке и переменному трафику — одно из ключевых преимуществ облачной платформы. Это означает, что слово «масштабируемость» можно вычеркнуть из словаря дорогих ИТ-решений, теперь это готовая возможность, которая может быть программным образом включена по запросу в хорошо спроектированном облачном решении.

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

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

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

  • Масштабирование процессов (потоков) указывает на поддержание достаточной мощности в терминах потоков обработки для данного экземпляра роли за счет запуска и завершения потоков в зависимости от текущей рабочей нагрузки.

Динамическое масштабирование в решении обработки сообщений на основе очередей должно предусматривать сочетание следующих общих рекомендаций.

  1. Мониторинг ключевых показателей эффективности, включая загрузку ЦП, размер очереди, время ответа и задержку при обработке сообщений.

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

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

  4. Секционирование и параллельная обработка тонкогранулированных рабочих нагрузок с помощью библиотеки Task Parallel Library в .NET Framework 4.

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

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

noteПримечание
Максимальное число малых экземпляров COMPUTE Azure (или эквивалентное число экземпляров другого размера в пересчете на число ядер) по умолчанию в обычной подписке ограничивается 20. Все запросы на увеличение этой квоты следует направлять группе поддержки Azure. Дополнительные сведения см. в ответах на часто задаваемые вопросы по платформе Azure.

С появлением средства автоматического масштабирования Azure Auto Scaling платформа может масштабироваться в соответствии с увеличением или уменьшением количества экземпляров на основе глубины очередей сообщений. Это очень естественный вариант для динамического масштабирования. Дополнительным преимуществом является то, что платформа Azure ведет мониторинг и масштабирует задачи для приложения.

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

ImportantВажно!
В настоящее время цель масштабируемости для одной очереди Azure ограничена до 2 000 транзакций/сек. Если приложение пытается превысить этот лимит, например выполняя операции с очередью из нескольких экземпляров ролей, обрабатывающих тысячи потоков вывода из очереди, то служба хранилища может выдать ответ HTTP 503 "Сервер занят". В таком случае приложение должно реализовать механизм повтора с алгоритмом экспоненциальной отсрочки. Но если ошибка HTTP 503 возникает регулярно, рекомендуется использовать несколько очередей и реализовать стратегию на основе секционирования, которая будет выполнять масштабирование по нескольким очередям.

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

Лучшие-решения-передачи-сообщений-Azure4

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

Чтобы реализовать возможность динамического масштабирования, попробуйте воспользоваться блоком автомасштабирования приложений библиотеки Microsoft Enterprise Library, которая обеспечивает автоматическое масштабирование в решениях Azure. Блок автомасштабирования приложений содержит всю функциональность, необходимую для определения и мониторинга автомасштабирования в приложении Azure.

noteПримечание
В качестве альтернативы ручного динамического масштабирования рекомендуется воспользоваться функцией встроенного автоматического масштабирования в Azure.

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

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

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

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

Архитектура решения основана на распределенном шаблоне разработки map-reduce и состоит из основанного на многоэкземплярной рабочей роли облачного слоя, использующего хранилище очередей Azure для диспетчеризации работы. Пакеты транзакций передаются экземпляру рабочей роли Process Initiator, разбиваются на более мелкие элементы и помещаются в коллекцию очередей Azure для распределения нагрузки.

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

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

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

AzureGuidance_MaxScale

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

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

Архитектор решений должен выполнить следующее.

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

  • Рекомендовать для секционированной архитектуры очередей выполнить масштабирование свыше 2 000 сообщений/сек.

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

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

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

  • Оценить автоматическое масштабирование Azure, чтобы определить, соответствует ли оно потребностям приложения в динамическом масштабировании.

  • Оценить соотношение «затраты-выгода» в сокращении задержек за счет создания зависимости от Azure Service Bus для диспетчеризации уведомлений с принудительной отправкой в реальном времени.

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

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

  • Оценить автоматическое масштабирование Azure, чтобы определить, соответствует ли оно потребностям приложения в динамическом масштабировании.

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

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

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

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

  • Реализовать надежную политику повторов, способную обрабатывать разнообразные временные ошибки при публикации и получении данных из очередей Azure.

  • Использовать возможность односторонней обработки событий, реализуемую Azure Service Bus для поддержки принудительно отправляемых уведомлений, чтобы сократить задержки и увеличить производительность решения обмена сообщениями на основе очередей.

  • Изучить такие новые возможности .NET Framework 4, как TPL, PLINQ и шаблон Observer, чтобы добиться максимальной степени параллелизма, улучшить параметры параллелизма и упросить разработку многопоточных служб.

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

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

Показ:
© 2014 Microsoft