W takim przypadku mikrousług REST lub AMQP

16

Przeczytałem wiele artykułów dotyczących architektury mikrousług i zastanawiałem się, kiedy użyć AMQP lub REST.

Czytałem, że luźne łączenie usług jest dobrą rzeczą, a AMQP wydaje się w tym przypadku dobrym wyborem. Ale jeśli użyjemy AMQP, oznacza to, że nie potrzebujemy już punktów końcowych REST (ale oznacza to, że tracimy koncepcję HATEOAS).

Ale czy REST jest naprawdę dobrym sposobem na zbudowanie moich usług? Ponieważ nie będę używać żadnych punktów końcowych ... W którym przypadku jeden jest lepszy od drugiego?

Kiedy powinienem użyć jednego lub drugiego?

Thomas Thomas
źródło

Odpowiedzi:

10

Odrzucając REST, tracisz znacznie więcej niż tylko HATEOAS. Jeśli twoje mikrousługi są publiczne (i dobrym pomysłem jest, aby były publiczne, a przynajmniej pewnego dnia stają się publiczne¹), ​​używanie czegoś innego niż REST i SOAP byłoby problematyczne:

  • Niektórzy programiści nigdy nie używali AMQP,

  • Niektórzy korzystali z AMQP, ale często lepiej znają REST i SOAP,

  • Biblioteki AMQP dla niektórych języków nie są szczególnie proste,

  • Ręczne eksperymentowanie z usługą jest bardzo ograniczone: mogę użyć CURL do wykonania dowolnego żądania do Amazon S3; co powinienem zainstalować na swoim komputerze, jeśli chcę grać z wariantem S3 AMQP?

  • Debugowanie REST i SOAP jest łatwe. Po prostu śledzę wymiany HTTP i analizuję je. Nie jestem pewien, jakich narzędzi powinienem użyć do debugowania wymiany AMQP.

AMQP jest świetny, ale odbywa się w bardzo konkretnym celu wymiany opartej na zdarzeniach. Chociaż technicznie możliwe jest wykonywanie RPC z AMQP, nie jest to jego główny cel.

Ważny jest także aspekt asynchroniczny. Czasami jest to korzyść: nie chcę blokować interfejsu użytkownika aplikacji podczas wysyłania żądań do serwerów. Czasami po prostu utrudnia to zadanie: jeśli muszę odzyskać kopię zapasową pliku z Amazon S3, ponieważ lokalna została uszkodzona, a następnie przywrócić kopię zapasową, mój plik wsadowy musi koniecznie CURL, aby zakończyć zadanie przed kontynuowaniem, a synchroniczne działanie (z określonym limitem czasu) ma sens.

Zachowaj REST dla podstawowych operacji:

  • Uzyskanie produktu,

  • Przechowywanie faktury,

i używaj AMQP do zadań, w których przesyłanie wiadomości ma sens:

  • Przetwarzanie wszystkich faktur od września i powiadamianie aplikacji, gdy raport jest gotowy do wyświetlenia (biorąc pod uwagę, że operacja trwa zwykle od dwóch do dziesięciu minut),

    Zaletą AMQP jest tutaj aspekt asynchroniczny. Żądanie HTTP oczekujące na dziesięć minut ma duże szanse na przekroczenie limitu czasu i inne problemy.

  • Wysłanie informacji, że kopie zapasowe zostały uszkodzone dla każdego, kto może być zainteresowany, takich jak osoby obsługujące, administratorzy baz danych, zespół monitorujący, twórcy aplikacji korzystającej z tej bazy danych itp.

    Zaletą AMQP jest między innymi możliwość dodawania subskrybentów bez zmiany aplikacji, która śledzi kopie zapasowe i uruchamia alert, gdy znajdzie uszkodzony.


¹ Publiczna usługa internetowa niekoniecznie jest używana przez użytkowników spoza firmy. W dużych i średnich firmach z twoich usług często korzystają inne oddziały tej samej firmy i mają takie same wymagania, jak te, które byłyby stosowane przez osoby trzecie: nie powinny ufać żadnym połączeniom (fakt, że jakiś facet nigdy nie Słyszałem o tym, kto dzwoni do Twojej usługi, działa w tej samej firmie, co Ty nie oznacza, że ​​nie wykorzysta jej problemów związanych z bezpieczeństwem), powinien być odpowiednio udokumentowany (ponieważ ten sam Indianin niekoniecznie zna Twój numer telefonu i niekoniecznie znać angielski) itp.

Arseni Mourzenko
źródło
Co z ładowaniem zależnych obiektów za pomocą AMQP? Podobnie jak użytkownik związany z usługą rozliczeniową (w ogromnej architekturze mikrousług), wzmocnić asynchroniczność dostępu do hateoas VS REST (synchroniczny)?
Thomas Thomas
5

Użyj obu.

Usługi sieciowe JSON w stylu REST świetnie nadają się do współpracy z javascript, iOS itp

AMQP doskonale nadaje się do długotrwałych procesów, zdarzeń i zarządzania mikrousługami.

Ale oba są tylko opakowaniami komunikacyjnymi dla faktycznej usługi, możesz ujawnić tę samą usługę na wiele sposobów i prawdopodobnie powinno.

AMPQ może działać dobrze narażony przez Websockets, które mogą wyglądać prawie jak punkt końcowy REST, jeśli zmrużysz go.

Ewan
źródło
1
„jeśli zezujesz na to” lol, to było świetne.
Iain Duncan,
0

REST to standardowa technologia, która szczególnie nadaje się do interoperacyjności między komponentami - jest to kluczowa część, świetna do tworzenia usługi internetowej, z której może korzystać ktoś inny. Ma on jednak typowe problemy z taką interoperacyjnością, ponieważ jest mniej wydajny niż protokół niestandardowy.

Jeśli piszesz architekturę zaplecza, w której usługi są konsumowane tylko przez ciebie, możesz użyć dowolnego protokołu, który ci się podoba - nie musisz już ograniczać się do takiego, który jest tak interoperacyjny. Możesz użyć MQ lub czegoś bardziej ściśle powiązanego i wydajnego. To, którego używasz, zależy od przypadku użycia. Magistrala komunikatów jest bardzo dobra dla rozproszonego zestawu usług przetwarzających dane, w których klient nie dba o to, kto odbiera wysyłane przez niego wiadomości.

gbjbaanb
źródło
2
Nie zgadzam się, jeśli o mnie chodzi, mają one różne cele; (ogólnie) nie powinieneś ujawniać AMQP przez publiczny internet; z jednej strony ma o wiele mniej funkcji uwierzytelniania i zwykle publiczni internauci chcą odpowiedzi od swoich działań. Z tego powodu REST idealnie nadaje się do publicznego korzystania z Internetu. Największą różnicą jest to, że AMQP jest asynchroniczny ( możliwe są zachowania podobne do synchronicznych , ale nie do tego służą MQ), a REST jest synchroniczny (tak, zwracanie 202jest dyktowane asynchronią, ale dlaczego wtedy użyłeś REST? Prawdopodobnie dlatego, że jest publiczny).
Jimmy Hoffa
Na marginesie, ujawnienie AMQP do użycia przez websocket, aby użytkownicy mogli otrzymywać wypychania w czasie rzeczywistym zamiast konieczności odpytywania, jest w rzeczywistości powodem do publicznego udostępniania AMQP; ale znowu: Różne cele, nie robisz REST, aby konsumenci mogli uzyskać wypchnięcia, to kolejny scenariusz, w którym używasz AMQP do czegoś, czego REST nie może zrobić.
Jimmy Hoffa,
@JimmyHoffa Doszedłem do wniosku, że pyta, czego użyć, aby podłączyć swoje serwery sieciowe, klientów lub cokolwiek do jego mikroserwisów w wewnętrznej sieci LAN, a nie przez Internet - stąd moja uwaga, że ​​REST jest do tego dobry, ale jeśli wszystko, czego używasz, jest pod Twoją kontrolą kontrola, możesz użyć, co chcesz.
gbjbaanb,
Tak, to na pewno ma sens; Jego pytanie czytam jednak inaczej: wygląda na to, że czytał o idei mikrousług i nie rozumie istotnych powodów wyboru AMQP zamiast REST. Wewnętrznie możesz użyć, co chcesz, ale wciąż istnieją konkretne powody, aby używać AMQP vs REST nawet wewnętrznie; usługi, które chcą asynchronizacji, powinny wewnętrznie korzystać z AMQP, usługi synchroniczne (pomyśl o czystej usłudze przetwarzania: Dane wejściowe - Dane przetwarzane -> Dane przetwarzane) powinny być typu REST. Obie technologie IPC mają wyraźne zalety i wady, znasz je i powinieneś wymienić je w swojej odpowiedzi! :)
Jimmy Hoffa,
0

AMQP obsługuje również komunikację punkt-punkt (na przykład zobacz python-qpid-protonsamouczek). Za pomocą tego można zaimplementować interfejs RESTful, ponieważ REST !=HTTP.

AMQP działa również znacznie lepiej niż HTTP.

Cochise Ruhulessin
źródło