Architektura zorientowana na usługi - warstwa transportowa (http i wiadomości)

Question

Szukamy możliwości przeniesienia naszej architektury (i dodania nowych komponentów) za pomocą architektury SOA (Service Oriented Architecture). Będzie istnieć szereg zewnętrznych interfejsów API, które będą używane przez strony trzecie, co zrobimy za pomocą interfejsu HTTP REST, ale zastanawiałem się, co najlepiej byłoby użyć wewnętrznie, ponieważ wszystkie komponenty są pod naszą kontrolą i będą na ta sama sieć, jednak potencjalnie różne technologie (głównie .net i ruby ​​na szynach).

Czy można uzyskać duże korzyści wydajności/funkcjonalności za pomocą systemu przesyłania wiadomości (redis, rabbitmq, EMS, inne ważne wyjątki, o których nie słyszałem ...) zamiast HTTP (REST, SOAP, itp.).

Starałem się znaleźć dobre informacje na ten temat i (jak można prawdopodobnie powiedzieć) Jestem całkiem nowy w tym bocznym obszarze, więc każda rada lub dobre zasoby będą mile widziane!

Thnaks

Answer 1

Oprócz tego, o czym wspomniał @Will Hartung, powiedziałbym również, że zależy to od tego, co zamierzasz zrobić ze swoim systemem. Jeśli masz głównie aplikacje typu klient-serwer, w których masz mało serwerów/usług i są one całkowicie niezależne, prawdopodobnie łatwiej będzie wdrożyć umowy serwisowe poprzez REST przez HTTP.

Jeśli z drugiej strony cały system wykonuje komunikację dwukierunkową lub jest wiele wywołań między procesami (zwłaszcza jeśli każdy uczestnik systemu będzie zarówno klientem, jak i serwerem w pewnym punkcie), a następnie przesyłanie wiadomości jest najlepszym rozwiązaniem. Z opcji przesyłania wiadomości wynika, że ​​AMQP/RabbitMQ jest najbardziej funkcjonalnym i łatwym w użyciu rozwiązaniem. Oferuje prawdziwą asynchroniczną platformę do kodowania.

Najważniejszą zaletą korzystania z wiadomości jest to, że możesz mieć kolejki dla każdego typu wiadomości, więc gdy system się rozwija i zmienia, kolejki/wiadomości mogą być takie same, ale usługa, która je obsługuje, może się zmienić pod spodem. Promuje separację warstw.

Wreszcie, jest to ogromna rzecz, moim zdaniem, właściwe korzystanie z wiadomości promuje małe, niezależne fragmenty kodu. Są one zarówno bardziej testowalne, jak i łatwiejsze w utrzymaniu, a ogólnie upraszcza architekturę przedsiębiorstwa. Jeśli spróbujesz obsłużyć zbyt wiele usług z punktów końcowych HTTP, w końcu (w ciągu roku lub dwóch) otrzymasz (1) zbyt wiele punktów końcowych do śledzenia lub (2) nieosiągalnego bałaganu kodu spaghetti .

Moja firma zaczęła używać systemu opartego na wiadomościach i działała dla nas bardzo dobrze. Serwer RabbitMQ jest z pewnością najbardziej niezawodnym komponentem. Jeśli masz więcej pytań na temat wiadomości lub architektury SOA, możesz zapytać.

Answer 2

Wiadomości zwykle daje bardziej luźno sprzężona architektura. Może być również bardziej odporny, ponieważ poszczególne komponenty mogą zawieść bez zabicia całej infrastruktury.

Minusem jest złożoność, zmiana paradygmatu na model asynchroniczny i prawdopodobnie wydajność (szczególnie jeśli utrzymuje się komunikaty w każdym miejscu).

Należy również upewnić się, że system przesyłania wiadomości jest wyjątkowo wytrzymały. Jeden aspekt twojej logiki może zostać przerwany i ponownie uruchomiony bez wpływu na wszystko, ale jeśli stracisz podstawową bazę wiadomości, wtedy WSZYSTKIE twoje logiki nie będą czekać na tworzenie kopii zapasowych wiadomości.

Na szczęście, magistrala komunikatów może być długa, bez ludzi, którzy manipulują i dotykają jej, największego źródła błędów i niestabilności w każdym systemie.