Перенаправление сообщения NServiceBus на основе доступности конечной точки

Question

Я новичок в NServiceBus, но в настоящее время использую его с SQL Server Transport для отправки сообщений между тремя машинами: один относится к конечной точке с именем Server, а два относятся к конечной точке, называемой Agent. Это работает, как ожидалось, с сообщениями, отправленными на конечную точку Agent, распределенную на одну из двух машин с помощью стандартного циклического цикла.

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

Однако, мне нужно построить в частном случае: если все машины на PriorityAgent конечной точки в настоящее время вниз, сообщения, которые обычно должны быть отправлены должны быть отправлены в Agent конечной точки вместо этого, так что они могут быть обработаны без задержки. С другой стороны, если все машины на конечной точке Agent в настоящее время недоступны, любые сообщения Agent не следует отправлять в PriorityAgent, они могут просто подождать, пока не вернется машина Agent.

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

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

2. Дает PriorityAgent сообщениям с коротким сроком действия и как-то обрабатывает истечение, чтобы перенаправить сообщения на конечную точку Agent. Я не уверен, действительно ли это возможно.

Является одним из этих решений на правильном пути, или я полностью закрыт?

Answer 1

Вы не видели, чтобы многие делали это, потому что это считается антипаттерном. Или, скорее, один из двух антипаттернов.

1) Либо вы отправляете команду, и в этом случае RECEIVER команды определяет контракт. Почему вы отправляете команду, определенную PriorityAgent, на Agent? Там не должно быть сцепления. Команда принадлежит ОДНОЙ логической конечной точке/очереди.

2) Или вы публикуете событие, определяемое тем, кто публикует, с обоими PriorityAgent и Agent в качестве подписчиков. Оба подписчика должны быть на 100% автономны и ничего не сообщать. Проверка биений/обмен информацией между этими двумя логическими отдельными объектами - это плохо. Почему у них в первую очередь есть место? Если они знают друг о друге «грязные секреты», они должны быть одинаковыми.

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

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

Answer 2

Я Деннис ван дер Стелт, и я работаю для Частного программного обеспечения, создателей NServiceBus.

Из чего я понимаю, и PriorityAgent, и Agent уже рассчитаны на несколько машин? Затем они оба работают по конкурирующим потребителям схеме. Другими словами, обе машины пытаются собрать сообщения из одной очереди, где только один победит и начнет обработку сообщения.

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

Кроме того, SQL Server имеет всевозможные функции (например, Always-On), чтобы убедиться, что он (полностью) не работает. Зачем пытаться решать сложные сценарии с помощью пользовательских решений сборки, когда SQL Server уже может решить это для вас?

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

Это некоторые из решений, доступных в качестве стандартных шаблонов обмена сообщениями или инфраструктурные решения для решения вашей проблемы. Опять же, мне не совсем понятно, что вы ищете. Если вы хотите продолжить обсуждение; возможно, вы хотите отправить по электронной почте support@particular.net, и мы можем продолжить обсуждение там.