Czy powinienem zamienić z WCF na NserviceBus


13

Mamy centralny serwer, który wysyła i odbiera wiadomości z wielu komputerów, które znajdują się w sieciach klientów w różnych lokalizacjach. Aby to ułatwić, obecnie używam WCF z TCPNetBindings, używając komunikacji dupleksowej zabezpieczonej certyfikatami.

Teraz mamy z tym wiele problemów - głównie dlatego, że jesteśmy proszeni o wsparcie w „trybie odłączonym” (musimy być odporni na awarie). Z tego co wiem, nie ma prostego sposobu na zrobienie tego przy użyciu stosu WCF - musielibyśmy coś zaimplementować i być może użyć msmq. Ostatnio patrzyłem na NServiceBus i widzę, że wydaje się dobrze pasować do rachunku - tolerancja na awarie, wiadomości mogą być wysyłane przez Internet za pośrednictwem prostej bramy http itp. Wiem, że jest dobrze szanowany w społeczności, i Rozumiem dlaczego, patrząc na to.

Więc moje pytanie brzmi ... Czy zatrudnienie NServiceBus brzmi jak rozsądny pomysł, czy może ktoś ma jakieś inne sugestie / doświadczenia związane z rzeczywistością? Myślę, że martwię się o wprowadzenie nowej technologii, o której relatywnie mało wiem, i borykam się z problemami takimi jak zabezpieczenie, ustawienie wszystkiego w niezawodny sposób, przeszkody po drodze. Jestem też nieufny wobec „złota- nakładanie "architektury i wybieranie czegoś błyszczącego, co skończy mnie w implementacji w porównaniu do trzymania się WCF i po prostu sprawi, że będzie dla mnie działać.

Dzięki!


1
> obsługa „trybu odłączonego” (musimy być odporni na awarie) Czy nadal nie będziesz musiał sam budować dużej tolerancji na awarie po stronie klienta? Odporność MSMQ na błędy na serwerze jest świetna do przywracania stanu w przypadku problemu, ale nadal widzę, że boli mnie głowa klienta bez względu na to, co wybierzesz.
brian

1
Muszę wesprzeć „gwarancję”, że klient wyśle ​​wiadomość do serwera, a serwer w końcu ją dostanie - więc jeśli jesteśmy offline, musimy próbować, aż tam dotrzemy. To właśnie robi NSB „za darmo”, podczas gdy jako rozwiązanie WCF (jak sądzę) wymagałoby kodu.
Matt Roberts,

Częściowo zgadzam się z Brianem. MSMQ, jeśli poprawnie skonfigurowany w ostatnich wersjach, daje całkiem dobry tryb rozłączania po wyjęciu z pudełka, o ile skonfigurujesz kolejkę i komunikat tak, aby zachowywały się w ten sposób. Klient może zachować wiadomości w lokalnej kolejce wychodzącej i wysłać je ponownie, gdy serwer będzie ponownie dostępny w kolejce zdalnej.
Bill

WCF ma powiązania MSMQ ... Mam ścisłą wiedzę na temat kilku udanych aplikacji na dużą skalę, które wykorzystują to. To powiedziawszy, lubię też nServiceBus, ale robi to inaczej.
Kyle Hodgson,

Odpowiedzi:


12

Moja sugestia, jeśli musisz być szybki w tej sprawie i potrzebujesz tylko czegoś prostego, aby ułatwić trwałą (rozłączoną) obsługę WCF, to zajrzyj do powiązań WCF - MSMQ. Jeśli potrzebujesz czegoś w większym środowisku, spójrz na nServiceBus.

Moim zdaniem nServiceBus naprawdę zacznie świecić w większym rozproszonym środowisku. Weźmy na przykład następujący przykład (to byłoby piekło na ziemi z WCF, ale proste z nServiceBus):

  • Infrastruktura składa się z warstwy serwera aplikacji, warstwy serwera pamięci podręcznej, warstwy bazy danych tylko do odczytu, warstwy bazy danych do odczytu / zapisu
  • Za każdym razem, gdy klient prześle nowy wpis, naprawdę chcesz, aby wszystkie te poziomy były aktualizowane jednocześnie
  • W WCF musisz ujawnić osobne usługi na każdym poziomie warstwy i poprosić klienta o wypchnięcie ich wszystkich (lub zlecenie centralnej aranżacji robienia tego samego za Ciebie)
  • W nServiceBus każdy poziom byłby subskrybentem tych informacji, a klient opublikowałby je raz, pozwalając magistrali usług zająć się resztą

WCF ma powiązania MSMQ

Jeśli jednak chcesz pozostać przy WCF (krótkie terminy, potrzebujesz innych funkcji WCF), radzę zajrzeć do tego artykułu na MSDN. Pokazuje, jak używać powiązań WCF dla MSMQ, a następnie pokazuje, jak przeprowadzić migrację jednej usługi z HTTP do MSMQ. Po drodze pokazuje niektóre problemy z tym scenariuszem (i przydatne rozwiązania tych problemów).

Obie te sugestie w dużym stopniu wykorzystują MSMQ, więc należy pamiętać o tym: w przeciwieństwie do Apache MQ, RabbitMQ i innych popularnych systemów kolejkowania, MSMQ nie jest typową architekturą kolejek opartą na brokerze, jest natomiast kolejką rozproszoną. Oznacza to, że jeśli klient WCF wysyła komunikat za pośrednictwem transportu MSMQ, podczas gdy nie może połączyć się ze zdalnym serwerem, który obsługuje kolejkę, komputer kliencki będzie kolejkować komunikat w lokalnie nazywanej „kolejką wychodzącą”. Wiadomość pozostanie tam bezpiecznie, dopóki usługa MSMQ klienta nie wykryje, że może ponownie połączyć się ze zdalną usługą MSMQ. W tym momencie wiadomość przepłynie od klienta do miejsca docelowego.

Istnieje co najmniej jedno zastrzeżenie do powyższego - jeśli serwer zdalny jest zbyt długo w trybie offline (sprawdź dokumentację MSMQ), klient zrezygnuje i przeniesie wiadomość z wychodzącej do kolejki brakujących wiadomości. Wiadomości przesyłane do kolejki niedostarczonych wiadomości nie mogą być ponownie wysyłane automatycznie, muszą zostać odbudowane.

Jeśli potrzebujesz szyfrowania i nie masz ActiveDirectory, w tym wpisie na blogu Sergey Sorokin szczegółowo opisuje kroki niezbędne do szyfrowania komunikacji MSMQ za pomocą WCF bez Active Directory.


7

Nie zastępują one 1 na 1 - wiele razy użyjesz NServiceBus do przesyłania wiadomości do lub odbierania wiadomości z punktu końcowego WCF.

W każdym razie, obsługa scenariuszy trybu rozłącznego, takich jak ten, naprawdę świeci w kolejkach komunikatów. NServiceBus to dobre miejsce na rozpoczęcie. Istnieje wiele innych opcji. Zauważyłem, że wiele z nich faktycznie pakuje MSMQ pod koniec dnia - MSMQ jest bardzo solidnym zapleczem i prawdopodobnie warto go użyć, gdy zostanie udostępniony.


Dzięki. Podkreślono, chociaż w moim przypadku widzę zamianę 1: 1, ponieważ większość moich komunikatorów WCF obsługuje komunikację między tymi komputerami a serwerem - wydaje mi się, że nsb zajmuje się tym wszystkim, dlatego jest to zamiana -out dla mnie.
Matt Roberts,

Gotcha, to powinno działać całkiem dobrze dla ciebie.
Wyatt Barnett
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.