Kolejka wiadomości a usługi sieciowe? [Zamknięte]


258

Pod jakimi warunkami preferowane byłyby aplikacje rozmawiające za pośrednictwem kolejki wiadomości zamiast usług internetowych (mam na myśli tylko XML, JSON lub YAML lub cokolwiek innego przez HTTP, a nie żaden konkretny typ)?

Muszę rozmawiać między dwiema aplikacjami w sieci lokalnej. Jedna będzie aplikacją internetową i będzie wymagała poleceń w innej aplikacji (działającej na innym sprzęcie). Żądania obejmują tworzenie użytkowników, przenoszenie plików i tworzenie katalogów. W jakich warunkach wolałbym XML Web Services (lub zwykły TCP lub coś takiego) niż używanie kolejki komunikatów?

Aplikacja internetowa to Ruby on Rails, ale myślę, że pytanie jest szersze.

Odpowiedzi:


315

Kiedy korzystasz z usługi internetowej, masz klienta i serwer:

  1. Jeśli serwer ulegnie awarii, klient musi wziąć odpowiedzialność za obsługę błędu.
  2. Gdy serwer ponownie działa, klient jest odpowiedzialny za jego ponowne wysłanie.
  3. Jeśli serwer udzieli odpowiedzi na wezwanie, a klient się nie powiedzie, operacja zostanie utracona.
  4. Nie masz sporu, to znaczy: jeśli milion klientów wywoła usługę internetową na jednym serwerze w ciągu sekundy, najprawdopodobniej twój serwer przestanie działać.
  5. Możesz oczekiwać natychmiastowej odpowiedzi od serwera, ale możesz również obsługiwać połączenia asynchroniczne.

Korzystając z kolejki komunikatów, takiej jak RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, oczekujesz różnych i bardziej odpornych na błędy wyników:

  1. Jeśli serwer ulegnie awarii, kolejka utrzymuje komunikat (opcjonalnie, nawet jeśli urządzenie zostanie zamknięte).
  2. Gdy serwer znów działa, odbiera oczekującą wiadomość.
  3. Jeśli serwer udzieli odpowiedzi na połączenie, a klient nie powiedzie się, jeśli klient nie potwierdzi odpowiedzi, komunikat będzie trwał.
  4. Masz spór, możesz zdecydować, ile żądań jest obsługiwanych przez serwer (zamiast tego nazywaj go pracownikiem).
  5. Nie oczekujesz natychmiastowej odpowiedzi synchronicznej, ale możesz implementować / symulować połączenia synchroniczne.

Kolejki wiadomości mają o wiele więcej funkcji, ale jest to pewna ogólna reguła, aby zdecydować, czy chcesz samodzielnie poradzić sobie z błędami, czy pozostawić je w kolejce wiadomości.


1
Jeśli używane jest wiązanie SOAP / JMS , uzyskuje się również luźne sprzężenie w usługach sieciowych.
koppor

W przypadku wielu mikrousług po stronie serwera, która powinna być preferowana usługa sieciowa lub kolejkowanie?
shivendra pratap singh

Drogi @ sw. , czy mogę wiedzieć, czy to oznacza, że ​​możemy umieścić MQ przed normalnymi stronami internetowymi? Załóżmy, że mam witrynę Wordpress (stos LAMP). Czy mogę używać MQ przed Apache, aby żądania przychodziły 1 po 1, zamiast wszystkich przychodzących w tym samym czasie. W takim przypadku klienci (przeglądarki) są podłączeni do MQ zamiast do Apache, mam rację? Ale czy przeglądarki utrzymują otwarte połączenie HTTP i czekają na odpowiedź Apache? Proszę, pomóż mi trochę zrozumieć. Doceń swoją życzliwość.
夏 期 劇場

@ 夏 期 劇場 jaki jest twój przypadek użycia? Co próbujesz osiągnąć, aby użytkownik końcowy korzystał z przeglądarki?
sw.

Czy te obawy związane z konfiguracjami klient / serwer nadal nie dotyczą między kolejką a serwerem oraz między klientem a kolejką? Wygląda na to, że paradygmat klient / serwer nadal istnieje i teraz jest w dwóch miejscach.
imagineerTat

75

Niedawno przeprowadzono wiele badań nad tym, w jaki sposób wywołania REST HTTP mogłyby zastąpić koncepcję kolejki komunikatów.

Jeśli jako zasób wprowadzisz koncepcję procesu i zadania, potrzeba środkowej warstwy wiadomości zacznie wyparowywać.

Dawny:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Zadanie może składać się z wielu etapów inicjowania, a proces może zwrócić status po odpytywaniu lub POST na adres URL wywołania zwrotnego po zakończeniu.

Jest to bardzo proste i staje się dość potężne, gdy zdasz sobie sprawę, że możesz teraz subskrybować kanał rss / atom wszystkich działających procesów i zadań bez żadnej warstwy środkowej. Każdy system kolejkowania i tak będzie wymagał jakiegoś interfejsu WWW, a ta koncepcja ma go wbudowaną bez kolejnej warstwy niestandardowego kodu.

Twoje zasoby istnieją, dopóki ich nie usuniesz, co oznacza, że ​​możesz wyświetlić informacje historyczne długo po zakończeniu procesu i zadania.

Wbudowano funkcję wykrywania usług, nawet dla zadania składającego się z wielu kroków, bez żadnych dodatkowych skomplikowanych protokołów.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Twoje odkrycie usługi jest formą HTML - uniwersalnym i czytelnym dla człowieka formatem.

Cały przepływ może być używany programowo lub przez człowieka, przy użyciu powszechnie akceptowanych narzędzi. Jest sterowany przez klienta, a zatem RESTful. Każde narzędzie utworzone dla Internetu może sterować procesami biznesowymi. Nadal masz alternatywne kanały komunikatów przez asynchroniczne testowanie POST do osobnej tablicy serwerów dziennika.

Po zastanowieniu się przez chwilę usiądź i zaczniesz zdawać sobie sprawę, że REST może po prostu wyeliminować potrzebę kolejki przesyłania wiadomości i ESB.

http://www.infoq.com/presentations/BPM-with-REST


11
@tempire co z odpornością na uszkodzenia i tak dalej? REST jest fajny, ale deweloper sam buduje oprogramowanie pośrednie
Dan Rosenstark

10
@Yar Większość pytań na temat „co z tym” można powtórzyć, „jak się to robi w Internecie?”. Odporność na awarie może być obsługiwana przez moduły równoważące obciążenie, a nawet manipulowanie rekordami dns. Do rozwiązania jest jeszcze kilka problemów, takich jak skalowalność pozioma - sieć z natury nie radzi sobie tak dobrze (na przykład ataki DDos).
burza

8
@tempire, nie ma gwarancji dostawy w Internecie, prawda? Naciskam poddaj się i modlę się, aby wiadomość dotarła do miejsca przeznaczenia. W przypadku MQ wiem, że jeśli dojdę do MQ, to skończę. Zajmie się dostarczeniem wiadomości do miejsca docelowego.
Dan Rosenstark,

10
@ Yar zastanów się jednak, co oznacza „gwarantowana dostawa”. Jest to tak „gwarantowane”, jak czas pracy kolejki wiadomości. Zastąp kolejkę komunikatów serwerem REST, który traktuje zadania i procesy jako zasoby, a Ty masz taką samą „gwarancję” jak wszystko inne. Zasadniczo nadal masz kolejkę komunikatów, ale w standardowym dostępnym formacie internetowym, który można monitorować za pomocą dowolnego narzędzia internetowego.
piątek

16
@Yar - Nie sądzę, aby wiele osób rozumiało definicję problemu, którą MQ stara się rozwiązać wystarczająco, aby nawet rozważyć takie rzeczy. Rozumieją MQ, ale różni się to od zrozumienia przestrzeni problemowej. Jest to jednak powszechny problem, ponieważ uważam, że większość programistów i menedżerów na świecie została przeszkolona w zakresie łączenia elementów zamiast rozwiązań inżynieryjnych.
burza

32

Kolejki wiadomości są idealne dla żądań, których przetworzenie może zająć dużo czasu. Żądania są umieszczane w kolejce i mogą być przetwarzane w trybie offline bez blokowania klienta. Jeśli klient musi zostać powiadomiony o zakończeniu, możesz zapewnić mu okresowe sprawdzanie statusu żądania.

Kolejki wiadomości pozwalają także lepiej skalować w czasie. Poprawia to zdolność do radzenia sobie z gwałtownymi ruchami, ponieważ faktyczne przetwarzanie może być rozłożone w czasie.

Zauważ, że kolejki wiadomości i usługi sieciowe są pojęciami ortogonalnymi, tzn. Nie wykluczają się wzajemnie. Np. Możesz mieć serwis internetowy oparty na XML, który działa jako interfejs do kolejki komunikatów. Myślę, że rozróżnienie, którego szukasz, to kolejki wiadomości w porównaniu z żądaniem / odpowiedzią, ta ostatnia ma miejsce, gdy żądanie jest przetwarzane synchronicznie.


3
Tak, właśnie o tym myślałem: nie chodzi o to, czy blokują, czy nie blokują. To, czy wymagają dłuższego i / lub nieprzewidywalnego czasu przetwarzania ... Jeśli chodzi o prostopadłość, prawdą jest również to, że usługi sieciowe mogą być używane do długich żądań (oczywiście oddzielny dropoff i odbiór). Jednak jeśli masz luksus kolejki wiadomości, może to być dobry pomysł.
Dan Rosenstark,

Moje nowe pytanie brzmi: co by było, gdyby proces był synchroniczny, ale asynchroniczny po przekroczeniu limitu czasu? Wtedy być może lepiej pasowałyby usługi sieciowe.
Dan Rosenstark,

27

Kolejki komunikatów są asynchroniczne i mogą ponawiać kilka razy, jeśli dostarczanie się nie powiedzie. Użyj kolejki komunikatów, jeśli requester nie musi czekać na odpowiedź.

Wyrażenie „usługi sieciowe” przywodzi mi na myśl synchroniczne wywołania rozproszonego komponentu przez HTTP. Skorzystaj z usług internetowych, jeśli requester potrzebuje odpowiedzi z powrotem.


1
Dzięki za to, tak „gwarantowana dostawa”, muszę pomyśleć o tym, czy to ważne. Chodzi mi o to, że synchronizacja vs. asynchronizacja jest w pewnym sensie czymś smakowym. Chociaż są wyraźnie czarno-białe obudowy, istnieje również ogromny szary środek.
Dan Rosenstark,

22

Myślę, że ogólnie rzecz biorąc, potrzebujesz usługi sieci Web dla zadania blokującego (zadania te muszą zostać zakończone, zanim wykonamy więcej kodu) oraz kolejki komunikatów dla zadania nieblokującego (może to zająć trochę czasu, ale nie trzeba na to czekać).


Usługi sieciowe oferują również metody jednokierunkowe ( @Oneway ). Aby otrzymać odpowiedź, klient musi zaoferować usługę internetową.
koppor
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.