Абстрагируете ли вы существование служебной шины / распределенного обмена сообщениями? - PullRequest
Новая
       24

Абстрагируете ли вы существование служебной шины / распределенного обмена сообщениями?

0 голосов
/ 23 апреля 2011

Я сейчас работаю над системой, которая находится в одном пространстве процессов; мы разбиваем это на несколько процессов, первоначально для запуска на одном компьютере, но в конечном итоге для распределения по нескольким отдельным машинам. Я склоняюсь к использованию ESB (NServiceBus, Rhino ESB) или, возможно, катаюсь со своими очередями WCF + для обработки сценариев pub / sub и запроса / ответа, которые есть в нашем приложении.

Однако я борюсь с абстракцией: я не хочу, чтобы различные компоненты знали, что они разговаривают по шине. Текущие API-интерфейсы, соединяющие различные сервисы, довольно хорошо соответствуют этой модели, но я хочу скрыть это со стороны клиента и сервера. Если не считать много пользовательских прокси-кодов для клиента и сервера, есть ли лучший способ подойти к этому? Я понимаю, что WCF может автоматически генерировать прокси на основе определения сервиса, но мне действительно нравятся некоторые другие вещи, которые я получаю с (скажем) Rhino Servicebus.

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

Какие-нибудь ресурсы / шаблоны / инструменты, чтобы помочь мне сделать это? Пожалуйста, задавайте вопросы, если мне не ясно. Спасибо.

1 Ответ

1 голос
/ 26 апреля 2011

Не может быть ни одного решения / готового компонента, который мог бы вам помочь.

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

Service_A     depends on      Service_B  
Service_C     depends on      Service_B  
Service_B     depends on      Service_D

В этом сценарии наилучшим способомпрогресс заключается в следующем:

  1. Определить контракты, выставленные Service_B и Service_D как внешние зависимости (возможно, как веб-сервис, хотя ESB поддерживает несколько протоколов) в сервисахService_A, Service_C и Service_B и использовать через ESB.
  2. В ESB, для начала, направьте службы Service_B и Service_D на один и тот же экземпляр.
  3. Если вы мигрируете Service_D и Service_B как Service_Dx и Service_Bx в другом местоположении, ESB можно перенастроить для маршрутизации в новое местоположение.Кроме того, ESB может быть сконфигурирован для маршрутизации на Service_B или Service_Bx на основе некоторого набора параметров (например, тестовых данных на Service_B и производственных данных на Service_Bx)

Задача 2:
Вероятно, проблему МОК трудно решить;в этом может не быть необходимости.
Я предполагаю, что клиенты вместо того, чтобы потреблять их из известного местоположения, получают информацию о местонахождении места обслуживания.Это в действительности передает конфигурацию на сторону клиента.При этом для каждого нового клиента, добавляемого в систему, должен быть отдельный элемент управления конфигурацией.Это может привести к логистическим проблемам.

Пожалуйста, опубликуйте свое окончательное решение, очень интересно узнать ваш подход.

...