Должен ли я поменяться с WCF на NserviceBus


13

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

Теперь у нас есть ряд проблем с этим - главным образом, нас просят поддержать «отключенный режим» (мы должны быть отказоустойчивыми). Из того, что я знаю, нет простого способа сделать это с помощью стека WCF - нам нужно что-то реализовать и, возможно, использовать msmq. В последнее время я смотрел на NServiceBus, и, насколько я понимаю, он, кажется, вполне соответствует требованиям - отказоустойчивость, сообщения можно отправлять через Интернет через простой http-шлюз и т. Д. Я знаю, что это хорошо уважают в сообществе, и Я могу понять, почему, глядя на это.

Итак, мой вопрос ... Похоже ли использование NServiceBus на разумную идею, или у кого-нибудь есть какие-либо другие предложения / опыт из реальной жизни, связанные с этим? Я думаю, я беспокоюсь о внедрении новой технологии, о которой я знаю относительно немного, и сталкиваюсь с проблемами с такими вещами, как ее защита, налаживание всего надежным способом, ошибки в пути ... Я также опасаюсь "золота- обожаю архитектуру, и выбираю что-то блестящее, что в конечном итоге заставит меня замолчать в реализации, а не придерживаться WCF и просто заставит это работать на меня ...

Благодарность!


1
> Поддерживать «отключенный режим» (мы должны быть отказоустойчивыми). Разве вам не придется самостоятельно создавать большую отказоустойчивость на стороне клиента? Отказоустойчивость MSMQ на сервере отлично подходит для восстановления состояния в случае возникновения проблемы, но я по-прежнему вижу, что это огромная головная боль для клиента, независимо от того, что вы выбрали.
Брайан

1
Хорошо, что мне нужно поддержать, это «гарантия», что клиент отправит сообщение на сервер, а сервер получит его в конце концов - поэтому, если мы не в сети, нам нужно продолжать попытки, пока мы не доберемся до этого. Это то, что NSB делает «бесплатно», тогда как для решения WCF (я думаю) потребуется код.
Мэтт Робертс

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

У WCF есть привязки MSMQ ... Я хорошо знаком с несколькими крупномасштабными успешными приложениями, которые используют это. Тем не менее, мне также нравится nServiceBus, но это делает другое.
Кайл Ходжсон

Ответы:


12

Мое предложение, если вам нужно быть быстрым в этом и нужно только что-то простое, чтобы упростить долговременную (отключенную) работу с WCF, это посмотреть на привязки WCF - MSMQ. Если вам нужно что-то в большей среде, посмотрите на nServiceBus.

На мой взгляд, nServiceBus действительно начал бы сиять в более крупной распределенной среде. Взять, к примеру, следующий пример (это было бы адом на земле с WCF, но просто с nServiceBus):

  • Инфраструктура, состоящая из уровня сервера приложений, уровня сервера кэша, уровня базы данных только для чтения, уровня базы данных для чтения / записи
  • Каждый раз, когда клиент отправляет новую запись, вы действительно хотите, чтобы все эти уровни обновлялись одновременно
  • В WCF вам нужно было бы предоставлять отдельные сервисы на каждом уровне уровня, чтобы клиент давил на них всех (или чтобы какая-то центральная оркестровка делала то же самое для вас)
  • В nServiceBus каждый уровень будет подписчиком этой информации, и клиент будет публиковать ее один раз, что позволит служебной шине позаботиться об остальном.

WCF имеет привязки MSMQ

Однако если вам нужно в основном придерживаться WCF (короткие сроки, нужны другие функции WCF), я бы посоветовал вам ознакомиться с этой статьей на MSDN. В нем показано, как использовать привязки WCF для MSMQ, а затем показано, как перенести один сервис из HTTP в MSMQ. По пути он показывает некоторые проблемы с этим сценарием (и полезные решения этих проблем).

Оба эти предложения интенсивно используют MSMQ, поэтому обратите внимание на это: в отличие от Apache MQ, RabbitMQ и других популярных систем массового обслуживания, MSMQ - это не типичная архитектура очереди на основе брокера, а распределенная очередь. Это означает, что если ваш клиент WCF отправляет сообщение через транспорт MSMQ, в то время как он не может подключиться к удаленному серверу, на котором размещена очередь, клиентский компьютер вместо этого поместит сообщение в очередь, которая называется «Исходящая очередь». Сообщение будет оставаться там безопасно до тех пор, пока служба MSMQ клиента не обнаружит, что она может снова подключиться к удаленной службе MSMQ. В этот момент сообщение будет передаваться от клиента до конечного пункта назначения.

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

Если вам требуется шифрование и у вас нет ActiveDirectory, в этой записи блога Сергей Сорокин подробно описывает шаги, необходимые для шифрования связи MSMQ с использованием WCF без Active Directory.


7

Они не являются заменой 1 к 1 - во многих случаях вы будете использовать NServiceBus для подачи сообщений или получения сообщений от конечной точки WCF.

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


Благодарю. Точка взята, хотя я вижу замену 1: 1 в моем случае, потому что большая часть моих коммуникаций WCF предназначена для поддержки связи между этими ПК и сервером - кажется, nsb обо всем позаботится обо мне, поэтому это своп для меня.
Мэтт Робертс

Понятно, тогда это должно сработать для вас.
Уайетт Барнетт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.