Architektura zorientowana na usługi-AMQP lub HTTP

Na początku

• REST, RPC-wzorce architektury, AMQP-wire - level I HTTP-protokół aplikacji, które działają na szczycie TCP / IP
• AMQP jest specyficznym protokołem, gdy HTTP - general-purpose protocol, więc HTTP ma cholernie wysokie koszty w porównaniu do AMQP
• natura AMQP jest asynchroniczna, gdzie natura HTTP jest synchroniczna
• ZARÓWNO REST, jak i RPC używają serializacji danych, który format zależy od Ciebie i zależy od infrastruktury. Jeśli używasz Pythona wszędzie I myślę, że możesz użyć natywnej serializacji Pythona - pickle, która powinna być szybsza niż JSON lub jakiekolwiek inne formaty.
• ZARÓWNO HTTP + REST jak i AMQP + RPC mogą działać w środowisku heterogenicznym i / lub rozproszonym

Więc Jeśli wybierasz, czego użyć: HTTP + REST lub AMQP + RPC, odpowiedź jest naprawdę przedmiotem złożoności infrastruktury i wykorzystania zasobów. Bez żadnych szczególnych wymagań oba rozwiązania będą działać dobrze, ale wolałbym zrobić trochę abstrakcji, aby móc przełączać się między nimi przejrzyście.

Powiedziałeś, że twój zespół zna HTTP, ale nie AMQP. Jeśli czas rozwoju jest ważnym czasem, masz odpowiedź.

Jeśli chcesz zbudować infrastrukturę HA przy minimalnej złożoności, to chyba protokół AMQP jest tym, czego chcesz.

Miałem doświadczenie z obu z nich i zalety usług RESTful są:

• dobrze odwzorowane na interfejsie WWW
• ludzie są z nimi zaznajomieni
• Łatwy do debugowania (ze względu na ogólny cel HTTP)
• łatwe dostarczanie API do Usług stron trzecich.

Zalety rozwiązania opartego na AMQP:

• damn fast
• elastyczny
• Łatwy w utrzymaniu
Łatwe skalowanie]}
• opłacalne (w znaczeniu wykorzystania zasobów)

Zauważ, że możesz dostarczyć RESTful API do usług innych firm na bazie API opartego na AMQP, podczas gdy REST nie jest protokołem, ale raczej paradygmatem, ale powinieneś pomyśleć o tym, budując swoje aqmp RPC api. Zrobiłem to w w ten sposób można udostępnić API zewnętrznym usługom stron trzecich i zapewnić dostęp do API w tych częściach infrastruktury, które działają na starej bazie kodu lub w których nie można dodać obsługi AMQP.

Jeśli mam rację, twoje pytanie dotyczy tego, jak lepiej zorganizować komunikację między różnymi częściami oprogramowania, a nie jak udostępnić API użytkownikom końcowym.

Jeśli masz projekt o dużym obciążeniu RabbitMQ jest cholernie dobrym oprogramowaniem i możesz łatwo dodać dowolną liczbę pracowników, które działają na różne maszyny. Ma również lustrzane odbicie i klastrowanie po wyjęciu z pudełka. I jeszcze jedno, RabbitMQ jest zbudowany na bazie Erlang OTP, która jest wysoce niezawodną, stabilną platformą ... ( bla-bla-bla), jest dobry nie tylko dla marketingu, ale także dla inżynierów. Miałem problem z RabbitMQ tylko raz, gdy dzienniki nginx zajmowały całe miejsce na dysku na tej samej partycji, na której działał RabbitMQ.