Чи варто мінятися з WCF на NserviceBus

У нас є центральний сервер, який надсилає та отримує повідомлення з ряду ПК, які розміщені в клієнтських мережах у різних місцях. Щоб полегшити це, в даний час я використовую WCF з TCPNetBindings, використовуючи дуплексне спілкування, захищене сертифікатами.

Зараз у нас є низка проблем із цим - головним чином у тому, що нас просять підтримувати "відключений режим" (нам потрібно бути вірогідними). З того, що я знаю, немає простого способу зробити це за допомогою стека WCF - нам знадобиться щось реалізувати і, можливо, використовувати msmq. Нещодавно я дивився на NServiceBus, і, як я бачу, здається, що він добре підходить до рахунку - толерантність до помилок, повідомлення можуть надсилатися через Інтернет через простий http шлюз і т. Д. Я знаю, що це добре поважають у громаді, і Я можу зрозуміти, чому з цього погляду.

Отже, моє запитання таке: чи використовує NServiceBus звучання як розумна ідея, чи хтось має інші пропозиції / досвід у реальному світі, які стосуються цього? Напевно, я переживаю за те, щоб запровадити нову техніку, про яку я знаю порівняно мало, і зіткнутися з проблемами з такими речами, як її безпека, налаштування все надійним способом. покриття "архітектури та вибору чогось блискучого, що в кінцевому підсумку збиває мене з моменту впровадження, порівняно з дотриманням WCF і просто змушує його працювати для мене".

Спасибі!

Моя пропозиція, якщо вам потрібно бути швидким щодо цього, і вам потрібно лише щось просте, щоб полегшити довговічну (відключену) роботу з 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.

Вони не є заміною 1 на 1 - багато разів ви будете використовувати NServiceBus для введення повідомлень або прийому повідомлень з кінцевої точки WCF.

У будь-якому випадку, поводження з відключеними сценаріями режимів на кшталт цього справді світить черги повідомлень. NServiceBus - це гарне місце для початку. Існує ряд інших варіантів. Зауважу, багато з них насправді завершують MSMQ наприкінці дня - MSMQ - це дуже міцний задній край і, ймовірно, варто використовувати його, коли він стає доступним.