Построение гибридных приложений в облаке на платформе Windows Azure patterns & practices


Critical необходимо обрабатывать немедленно, сообщения с приоритетом Important



Pdf просмотр
страница26/33
Дата28.11.2016
Размер8.44 Mb.
Просмотров6336
Скачиваний0
1   ...   22   23   24   25   26   27   28   29   ...   33
Critical необходимо обрабатывать немедленно, сообщения с приоритетом Important должны быть обработаны как можно быстрее (в идеале — в ближайшие 10 минут), сообщения, помеченные как
Information, не срочные, но если они не будут обработаны в течение следующих 20 минут, содержащиеся в них данные станут иррелевантными и могут быть проигнорированы.
Рисунок 3
Приоритезация сообщений при помощи топиков и подписок шины интеграции
Получатель
Приложение- отправитель
Получатель
Топик шины
интеграции
Подписки шины интеграции
Динамический пул получателей. Новые получатели запускаются, если подписка содержит сообщения, ожидающие обработки.
Отправитель присваивает сообщению приоритет
(Critical, Important,
Information) перед отправкой его в тему
Фиксированный набор важных сообщений, которые могут быть обработаны в течение десяти минут
Приемник с низким приоритетом для обра- ботки информационных сообщений
Свойства подписки:
DefaultMessageTimeToLive: 20 минут
EnableDeadLetteringOnMessageExpiration:
False
Сообщения, отфильтрованные по проритету
Сообщение
Приоритет: Critical.
Данные сообщения
Приоритет:
Important. Данные сообщения
Приоритет:
Important. Данные сообщения
Приоритет:
Information. Данные сообщения
Приоритет:
Information. Данные сообщения
Получатель
Получатель
Получатель
Получатель
Получатель
Получатель
Получатель

311

Отправители сообщений ожидают ответ на это сообщение от получателя. Число отправителей может существенно различаться с течением времени.
В разделе «Рекомендации по использованию очередей шины интеграции» в
«
Приложении В.
Реализация подхода "коммуникации без границ"» описывается процедура помещения сообщения в очередь отправителем, получения ответа из другой очереди и сопоставления ответа с оригинальным сообщением с помощью свойства CorrelationId сообщения. Отправитель указывает очередь, в которую нужно поместить ответ, в свойстве ReplyTo сообщения, а получатель заполняет свойство CorrelationId сообщения-ответа копией значения свойства
MessageId оригинального сообщения-запроса.
Такой подход очень прост, он подходит для относительно небольшой статичной группы отправителей, но не обеспечивает достаточную масштабируемость и необходимую скорость реакции на быстрое изменение количества отправителей. Это обусловлено тем, что каждому отправителю требуется собственная очередь шины интеграции.На создание этих очередей требуется время и определенные финансовые затраты.В идеале, если очередь больше не нужна, ее необходимо удалить. Топики и подписки шины интеграции предоставляют лучшие варианты этого подхода в динамичной среде.
Подписки шины интеграции поддерживают понятие корреляция подписки. Этот механизм позволяет приложениям подключиться к топику и создать подписку, которая фильтрует сообщения по свойству CorrelationId. Подписки шины интеграции предоставляют фильтр
CorrelationFilter специально для этих целей. Для реализации корреляции подписки необходимо выполнить следующие операции:
◦ Отправитель создает сообщение и присваивает уникальное значение свойству
MessageId.
◦ Отправитель подключается к подписке шины интеграции, из которой он рассчитывает получить ответ, и добавляет фильтр CorrelationFilter для этой подписки, указав значение свойства MessageId сообщения-оригинала. Все отправители используют один и тот же топик, но фильтр гарантирует, что каждому отправителю придет ответ только на то сообщение, которое послал именно он.
Примечание
Для одной подписки можно установить более одного фильтра. Сообщение передается подписчику, когда выражение фильтра соответствует свойствам сообщения. Однако, если совпадают несколько выражений, то одно и то же сообщение появится несколько раз (один раз для каждого совпадения).
◦ Отправитель помещает сообщение в топик шины интеграции, на который подписаны один или несколько получателей.
◦ Получатель принимает сообщение, основываясь на любом фильтре, который применяется к подписке, а затем обрабатывает это сообщение.
◦ Получатель создает сообщение-ответ и заполняет свойство CorrelationId копией значения свойства MessageId оригинального сообщения.
◦ Получатель помещает ответное сообщение в топик шины интеграции, который является общим для всех приложений-отправителей.
◦ Когда в топике появляется сообщение, значение свойства CorrelationId которого совпадает со значением свойства MessageId сообщения-оригинала, фильтр

312
CorrelationFilter соответствующей подписки обеспечивает его доставку надлежащему получателю.
Мнение Маркуса
Фильтр CorrelationFilter был разработан специально для этого сценария, это чрезвычайно эффективный механизм фильтрации сообщений. С фильтром SqlFilter ситуация иная, он обеспечивает более высокую гибкость, однако подлежит лексикографическому анализу в момент создания и обуславливает более высокие затраты на выполнение.
На рисунке 4 показана структура данного решения.
Рисунок 4
Использование корреляции подписки для доставки сообщений-ответов отправителю

Ваша система непрерывно обрабатывает большой объем сообщений. В целях поддержки производительности ранее было принято решение реализовать механизм горизонтального масштабирования с помощью очередей шины интеграции, но вы обнаружили, что необходим более строгий контроль над тем, какие получатели какие сообщения обрабатывают, кроме того вам нужно направлять сообщения получателям, работающим на определенных серверах.
Получатель
Топик шины
интеграции
Подписки шины интеграции
Отправители указывают значение для свойства
MessageId сообщения
Сообщение
Получатель
Отправитель
А
Отправитель
Б
MessageId: 99.
Данные сообщения
MessageId: 342.
Данные сообщения
MessageId: 502.
Данные сообщения
CorrelationId: 98.
Данные сообщения
CorrelationId: 341.
Данные сообщения
Ответ
Топик шины
интеграции
Отправители фильтруют ответы по свойству CorrelationID
Ответ на сообщение
341, посланное ранее отправителем Б
Ответ на сообщение 98, посланное ранее отправителем А
Получатели копируют значение свойства
MessageId оригинального сообщения в свойство
CorrelationId сообщения- ответа
Отправители подключаются к подписке и добавляют фильтр
CorrelationFilter, свойство
CorrelationId которого совпадает со свойством MessageId оригинального сообщения

313
Как описано в разделе «Рекомендации по использованию очередей шины интеграции» в
«
Приложении В. Реализация подхода "коммуникации без границ"»
, очереди шины интеграции позволят вам реализовать простой механизм балансировки нагрузки в процессе обработки сообщений, когда несколько получателей могут прослушивать одну и ту же очередь.
Результат — циклический алгоритм распределения сообщений.Но при этом вам не удастся реализовать более строгий контроль над получателями и обрабатываемыми ими сообщениями, поскольку циклический алгоритм такой сценарий не предусматривает. Например, вашей системе может потребоваться, чтобы все сообщения, свойству Warehouse которых присвоено значение А, обрабатывались получателем, работающим на ближайшем к хранилищу А сервере, при этом сообщения с меткой Б обрабатывались получателем, работающим на сервере, расположенном как можно ближе к хранилищу Б и так далее.
Топики и подписки шины интеграции предоставляют полезный механизм для секционирования нагрузки, связанной с обработкой сообщений, с учетом одного или нескольких свойств каждого сообщения. Вы можете создать набор взаимоисключающих фильтров, которые охватывают разные диапазоны значений в свойствах сообщений и направляют каждый диапазон своей подписке. Различные получатели, прослушивающие эти подписки, могут работать на конкретных локальных серверах, но они также могут быть реализованы как рабочая роль в облаке. Кроме того, у каждой подписки может быть несколько получателей. В этом случае получатели будут конкурировать за сообщения от подписки, а для очереди будет реализован циклический алгоритм с целью балансировки нагрузки.
На рисунке 5 показан пример структуры системы хранения данных. Все получатели созданы при помощи инструментов из пакета Windows Azure SDK и имеют прямое подключение к различным подпискам шины интеграции. Обмен данными с хранилищем Б более интенсивный, чем с хранилищем А, поэтому сообщения, отправляемые хранилищу Б, обрабатываются несколькими получателями, которые работают на оборудовании, расположенном ближе к хранилищу Б.
Рисунок 5
Горизонтальное масштабирование при помощи топиков и подписок шины интеграции
Подписки шины интеграции
Топик шины интеграции
Сообщение
Warehouse: А.
Данные сообщения
Warehouse: Б.
Данные сообщения
Warehouse: Б.
Данные сообщения
Получатель
Отправитель
Присваивает свойству Warehouse значение А или Б
Warehouse = Б
Оба получателя, относящиеся к хранилищу Б, расположены на одном узле. Получатели конкурируют за сообщения из одной и той же подписки, распределяя нагрузку.
Локальная инфраструктура для хранилища A
Локальная инфраструктура для хранилища Б
Получатель
Получатель

314
Мнение Маркуса
Если вы создали приложение-отправитель с помощью метода Send объекта
MessageSender для отправки сообщений в очередь шины интеграции, вам не придется изменять эту часть кода, поскольку можно использовать тот же метод, чтобы помещать сообщения в топик. Все, что нужно сделать,— создать для сообщений соответствующие свойства, которые требуются фильтру подписки, и задать этим свойствам значения, прежде чем отправить сообщения в топик. Чтобы получать сообщения из подписки шины интеграции, используйте объект
SubscriptionClient.

Сообщения, полученные от подписки, возможно, придется отправить к месту назначения для дополнительной обработки, в зависимости от определяемых в системе критериев. Этот механизм переадресации должен быть прозрачным для отправителя, поскольку критерии переадресации и конечный пункт назначения могут измениться. Кроме того, приложение- получатель не должно зависеть от каких-либо изменений, касающихся этих критериев и конечного пункта назначения.
Рассмотрим пример системы обработки заказов: веб-приложение посылает информацию о заказах приложению-получателю через топик шины интеграции. Приложение-получатель отвечает за организацию упаковки и отправки заказа. Все заказы могут быть подвергнуты дополнительной проверке и аудиту, в зависимости от суммы счета. Такой анализ выполняется независимым набором процессов, составляющих логику аудита, которая определяется политикой обработки заказов, принятой в организации.
Например, если сумма заказа меньше 100, данные просто заносятся в журнал, если сумма попадает в диапазон от 100 до 499, заказ регистрируется, а подробная информация о нем выводится на печать для последующей проверки аудитором. Если сумма равна 500 и более, заказ регистрируется, а данные о нем отправляются по электронной почте непосредственно аудитору для немедленного анализа. Аудитор может принять решение об отмене заказа, если клиент не соответствует определенным требованиям. Однако эти пороговые значения могут меняться, и бизнес-логика приложения-получателя должна быть изолирована от этих изменений.
Такой изоляции можно достичь с помощью правила для действия фильтра. Правило фильтра может изменять, добавлять или удалять свойства сообщения, когда сообщение извлекается из подписки шины интеграции. Правила фильтра применяются прозрачно, когда сообщение извлекается приложением-получателем. Приложение-получатель может создать копию сообщения в целях выполнения собственной обработки, а также переслать полученное сообщение в другой топик, который направляет сообщение в соответствующий пункт назначения с учетом обновленного набора свойств.
На рисунке 6 показана возможная структура для примера обработки заказов. Отправитель указывает общую стоимость по заказу в свойстве TotalCost сообщения-оригинала, вместе с другими свойствами (не показаны на рисунке), которые используются для пересылки сообщений приложению-получателю («выполняющий переадресацию получатель»). Когда приложение-получатель принимает сообщение, фильтр применяет правило, которое автоматически добавляет свойство PriceRange каждому сообщению. Свойство PriceRange может принимать значения Low, Medium или High в соответствии со стоимостью заказа. Сумма меньше 100 соответствует значению Low, сумма в диапазоне от 100 до 499 соответствует значению Medium, а сумма от 500 и выше — значению High. Приложение-получатель

315 выполняет все необходимые операции по обработке. В то же время, оно отправляет копию полученного сообщения с добавленным свойством PriceRange в топик шины интеграции, на который подписаны различные получатели-аудиторы. Подписки получателей-аудиторов фильтруют сообщения по свойству PriceRange и направляют их получателю, который выполняет необходимые операции, как описано ранее.
Рисунок 6
Поиск прямого маршрута для сообщений с помощью правил для действия фильтра
В следующем фрагменте кода показано, как добавлять правила для действий фильтра, используемых в этом примере для подписки, которую прослушивает приложение-приемник, выполняющее переадресацию. Обратите внимание, что эти правила для действий фильтра также удаляют свойство TotalCost из сообщения, поскольку оно не является необходимым для пересылки сообщений приложению-аудитору, поиск прямого маршрута выполняется только с учетом свойства PriceRange. При этом полная информация о заказе получателю-аудитору по- прежнему доступна в теле сообщения.
C#
// Define action rule filters var ruleLowPrice = new RuleDescription()
{
Action = new SqlRuleAction(
Подписки шины интеграции
Топик шины
интеграции
Подписки шины
интеграции
Топик шины
интеграции
Сообщение
PriceRange: Low.
Данные сообщения
PriceRange: Medium.
Данные сообщения
PriceRange: High.
Данные сообщения
Выполняющий переадресацию получатель отправляет сообщение с добавленным в него свойством
PriceRange и удаленным свойством
TotalCost, а затем обрабатывает копию этого сообщения
Сообщения, отфильтрованные по свойству PriceRange
Свойство
PriceRange, добавленное применяемым правилом фильтра, принимает значение
Medium
Подписка для одного получателя, выполняющего переадресацию, другие опущены, чтобы не затруднять понимание
Отправитель добавляет свойство
TotalCost в сообщение
PriceRange:
Medium. Данные о заказах
TotalCost: 250.
Данные сообщения
Веб- приложение
Orders
Выполняющий переадресацию получатель
Получатель- аудитор (Low)
Получатель- аудитор
(Medium)
Получатель- аудитор (High)

316
"set PriceRange='Low';remove TotalCost"),
Filter = new SqlFilter("TotalCost < 100"),
Name = "LowPrice"
}; var ruleMediumPrice = new RuleDescription()
{
Action = new SqlRuleAction(
"set PriceRange='Medium';remove TotalCost"),
Filter = new SqlFilter(
"TotalCost >= 100 AND TotalCost < 500"),
Name = "MediumPrice"
}; var ruleHighPrice = new RuleDescription()
{
Action = new SqlRuleAction(
"set PriceRange='High';remove TotalCost"),
Filter = new SqlFilter("TotalCost >= 500"),
Name = "HighPrice"
};
... var subscriptionClient = messagingFactory.CreateSubscriptionClient(...);
// Добавление правил к подписке subscriptionClient.AddRule(ruleLowPrice); subscriptionClient.AddRule(ruleMediumPrice); subscriptionClient.AddRule(ruleHighPrice);

Ограничения, которые необходимо учитывать при использовании топиков и подписок
шины интеграции для маршрутизации сообщений
Топики и подписки шины интеграции позволяют реализовать только простой механизм маршрутизации.
Из соображений безопасности, фильтры, которые вы задаете, не могут получить доступ к телу сообщения, принимать решения им приходится, основываясь только на данных, представленных в виде свойств сообщения. Чаще всего фильтры задаются на основе класса SqlFilter. В целях оптимизации, условия в этих фильтрах ограничены подмножеством синтаксиса SQL92. Вы можете провести прямое сравнение данных и значений с помощью обычных арифметических и логических операторов, но эти фильтры не поддерживают функции, например функция Substring отсутствует. Если потребуется маршрутизация на основе более сложных правил, необходимо реализовать эту логику в коде путем создания получателя, который проверяет данные сообщения, а затем отправляет это сообщение в другую очередь или топик по мере необходимости.
Более подробная информация о типах выражений, поддерживаемых классом SqlFilter представлена в статье «SqlFilter.SqlExpression Property» на сайте MSDN: http://msdn.microsoft.com/en- us/library/microsoft.servicebus.messaging.sqlfilter.sqlexpression.aspx

317
Пересылка сообщений в несколько пунктов назначения при помощи
топиков и подписок шины интеграции
В предыдущем разделе описывается процедура использования фильтров для распределения сообщений по различным непересекающимся группам, при этом каждая группа направляется в подписку шины интеграции, и каждое сообщение предназначено для одной конкретной подписки.
Тем не менее различные подписки могут иметь фильтры с пересекающимися предикатами. В этом случае копии одного и того же сообщения направляются каждой удовлетворяющей условиям подписке.
Этот механизм предоставляет средства для пересылки сообщений нескольким адресатам.
Обратная ситуация также возможна. Если фильтры всех подписок не соответствуют свойствам сообщения, это сообщение будет оставаться в очереди топике шины интеграции до истечения срока его действия.
Рекомендации по использованию топиков и подписок шины интеграции
для маршрутизации сообщений в несколько пунктов назначения
Фильтры с перекрывающимися предикатами позволяют реализовать ряд эффективных сценариев.
В следующем списке приставлены общие случаи:
Примечание
«
Приложение A. Репликация, распространение и синхронизация данных»
содержит описание нескольких дополнительных моделей использования топиков и подписок шины интеграции с целью запроса и обновления данных в системе, использующей реплицированные источники данных.

Ваша система позволяет приложениям-отправителям отсылать запросы на обслуживание, но все эти запросы должны быть занесены в журнал для аудита или диагностики.
Процедура занесения в журнал должна быть прозрачной для приложения-отправителя.
Это пример наиболее общей схемы отправки сообщений нескольким получателям. Службы могут использовать подписки для получения предназначенных им сообщений, но при этом все сообщения должны быть переданы в службу ведения журнала аудита, чтобы их можно было записать и сохранить. Пакет Windows Azure SDK предоставляет тип TrueFilter специально для этой цели. Этот фильтр подходит всем сообщениям, и любые подписки, которые используют этот фильтр, автоматически получат копию каждого сообщения, отправленного в этот топик.
Мнение Маркуса
TrueFilter — это фильтр по умолчанию для подписки, если вы не указываете другой фильтр при создании подписки, TrueFilter применяется автоматически.
На рисунке 7 показан пример системы, которая использует фильтр TrueFilter для копирования сообщений в журнал аудита с целью дальнейшей проверки.

318
Рисунок 7
Занесение сообщений в журнал с помощью TrueFilter
Получатель журнала аудита — это просто пример приложения, которое может эффективно использовать данный подход. Любая функция, которой требуются копии сообщений, проходящих через вашу систему, может быть реализована подобным образом. Например, вы можете создать приложение, которое подсчитывает количество сообщений, поступающих вашей системе в течение определенного периода времени, и отображает результаты — данные о пропускной способности и производительности вашего решения.
Разумеется, вы можете быть более избирательными. Вместо TrueFilter можно использовать перекрывающийся фильтр SqlFilter, который перехватывает сообщения с учетом значений определенных свойств. Эти сообщения будут направляться получателям для обработки, а также приложению-получателю журнала аудита.

В вашей системе возникает множество бизнес-событий. Каждое событие может быть обработано процессами, которых может быть от нуля и больше, и ваша система должна иметь возможность добавлять или удалять процессы, которые могут обрабатывать эти события, не затрагивая бизнес-логику системы. Обработчики событий могут быть запущены удаленно от процессов, которые генерируют эти события.
Процессы, которые генерируют события, чтобы сообщить заинтересованным сторонам о том, что произошло что-то важное. Процессы, прослушивающие события, по своей природе являются асинхронными и не связаны с процессами, которые генерируют события. Топики и подписки шины интеграции обеспечивают превосходную основу для создания такой системы, особенно с учетом требования, предусматривающего возможность размещения обработчиков событий в любом месте и гарантированную доставку событий.
С точки зрения обмена сообщениями, приложение может оповещать заинтересованные стороны о событиях, просто отправляя сообщение, содержащее данные о событиях, в топик шины
Топик шины
интеграции
Подписки шины
интеграции
Сообщение
Приложения- отправители
Сообщение
А
Сообщение Б
Сообщение
Б
Сообщение
А
Получатель
Получатель
Получатель журнала аудита
Журнал аудита
Фильтры направляют сообщения конкретным подпискам
TrueFilter копирует все сообщения в подписку журнала аудита

319 интеграции. Каждое приложение, которому требуются уведомления о событиях, может создать свою собственную подписку с фильтром, определяющим условия для сообщений-событий. Топик, в который приложение-отправитель посылает сообщения о событиях, может иметь свойство
DefaultMessageTimeToLive с соответствующим значением. В таком случае, если ни одно приложение не подписывается на события, оно будет удалено по истечении указанного срока.
Мнение Джаны
Не следует совместно использовать одну и ту же подписку на события двум отдельным приложениям, если они оба должны быть уведомлены о событии. Они будут конкурировать за сообщения о событиях, направляемых в подписку, и каждое сообщение будет передано только одному из приложений.
На рисунке 8 показан пример базовой системы управления конвейером на производственном предприятии. Когда необходимо начать производство, приложение Controller помещает сообщение «Пуск машины» в топик шины интеграции. Каждый агрегат, участвующий в процессе сборки, управляется программой-драйвером, которая получает это сообщение и запускает агрегат. Аналогичным образом, когда производство останавливается, приложение Controller отправляет сообщение «Стоп машины», и соответствующая программа-драйвер останавливает каждый агрегат в контролируемом режиме. Приложение Controller не учитывает особенности устройств, задействованных в процессе производства, агрегаты могут быть добавлены или удалены, но приложение Controller при этом изменять не придется.
Рисунок 8

Каталог: download
download -> Составление простейшей программы в среде lego education. Запуск модели «Обезьянка барабанщица», «Рычащий лев», «Автомобиль»
download -> Функциональные части компьютера, история развития, базовая конфигурация
download -> Компьютер: друг или враг?
download -> Лекция №2 «Теоретические основы игры дошкольника» Зарубежные и отечественные теории игры
download -> Доклад муниципальное образовательное
download -> Литература для воспитанников стр. Приложения стр
download -> Министерство здравоохранения Республики Беларусь
download -> Игра как средство активизации познавательной активности учащихся в ходе изучения темы Алгоритмизация и программирование


Поделитесь с Вашими друзьями:
1   ...   22   23   24   25   26   27   28   29   ...   33


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал