W takim przypadku mikrousług REST lub AMQP

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?

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.}

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.

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.

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.