Альтернатива маршрутизации на основе контента для разделения задач по регионам в мире

Question

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

Похоже, что классический сценарий для маршрутизации контента на основе: путем добавления «область поля (как в примере виджет/гаджет в Enterprise Integration Pattern книги)

Благодарности

----- ------- Edit 31/10/15 ----------------

в ответ на @mookid, в отношении ребуса предложения решения:

До недавнего времени у меня было представление о том, что команды плохие («разрушает архитектуру |»), потому что я предположил, что sendin g до конечной точки означает конкретный потребитель (по ip-адресу). Поэтому я предпочел использовать события для всего, что затем вызвало проблемы с решением проблемы регионов.

Но теперь, когда я думаю об этом, я могу использовать интерфейс IOrderPlaced и создать 2 конечных точки для каждого сообщения: IOrderPlaced_USA, IORderPlaced_EU. имя конечной точки будет помещено в app.config, и поэтому серверы США будут иметь другой app.config, чем серверы ЕС.

это позволит мне использовать один и тот же сервер RabbitMQ для обоих регионов, но не разрешит мне отправлять сообщения из ЕС в США - это может быть приемлемо Мое понимание выше верно?

У меня возникли проблемы с размещением всех деталей, не могли бы вы представить свое мнение о том, как сравнивается предлагаемое вами решение?

Благодаря

Answer 1

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

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

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

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

await bus.SendLocal(new DoSomething { Region = "US" }); 

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

public class DoSomethingForwarder : IHandleMessages<DoSomething> 
{ 
    readonly IBus bus; 

    public DoSomethingForwarder(IBus bus) 
    { 
     this.bus = bus; 
    } 

    public async Task Handle(DoSomething message) 
    { 
     var destination = DecideWhereToSend(message); 

     await bus.Advanced.TransportMessage.Forward(destination); 
    } 

    string DecideWhereToSend(DoSomething message) 
    { 
     //I'll leave the implementation to you :) 
    } 
} 

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

Если вы хотите, чтобы ваш маршрутизатор быстрее и эффективнее переключался на изменения схемы сообщений, вы также можете маршрутизировать сообщения на основе значений заголовков на adding a "transport message forwarder" via the routing configuration API.

Не уверен, как NServiceBus и MassTransit делают такие вещи, но я уверен, что они могут сделать это почти так же.