Czy AMQP jest odpowiedni zarówno jako maszyna do komunikacji wewnętrznej, jak i między maszynami?

Question

Próbuję zrozumieć moją opinię na temat AMQP. Wygląda świetnie na komunikację między maszynami (klastry, sieć LAN, WAN) między aplikacjami, ale nie jestem pewien, czy jest odpowiedni (w architekturze i obecnie stosowane warunki) do użycia jako magistrala programowa w ramach jednej maszyny.

Czy warto wyciągnąć aktualną wiadomość o wysokiej wydajności, która przekazuje framework, aby zastąpić ją AMQP, czy też należy to do same trap as RPC, zacierając rozróżnienie między komunikacją lokalną i nielokalną?

Jestem także nieufny wobec wpływu na wydajność korzystania z technologii WAN w komunikacji wewnątrz maszynowej, chociaż może to być raczej problem związany z implementacją niż architektura.

Historie wojenne będą mile widziane.

Answer 1

AMQP nie jest strukturą RPC. Dostarcza elementów do modelowania rzeczy takich jak kolejki współdzielone, RPC, pubsub itp., Ale nie nakazuje żadnego konkretnego sposobu korzystania z niego.

Jeśli chcesz podzielić aplikację na partycje (dzięki czemu można ją dystrybuować po drodze) i połączyć ją z AMQP, myślę, że jest to właściwa technologia. Możliwe, że istnieją szybsze alternatywy, ale prawdopodobnie żadne z nich nie są tak ogólne jak AMQP.

Answer 2

AMQP to specyfikacja, dzięki której można naprawdę porównać jabłka z pomarańczami. Nie ma tak wielu naprawdę gotowych dostawców AMQP; żaden z głównych dostawców lub dostawców komunikatów nie obsługuje AMQP w czasie pisania (np. IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq od Sun) - więc wszyscy dostępni dostawcy AMQP są całkiem nowi.

Polecam więc porównanie dowolnego dostawcy AMQP, który cię interesuje, z ramą przekazującą wiadomości. Nie ma sensu wyrzucać czegoś, co działa dobrze tylko ze względu na sposób, w jaki odczytuje & zapisuje bajty do gniazda :)

Answer 3

AMQP wygląda bardziej jak niezawodna oferta oprogramowania pośredniczącego do transportu SOA niż coś, co można wykorzystać wewnętrznie.

Answer 4

Jako podstawa niezawodnej, niezwykle elastycznej (pod względem wzorców komunikacyjnych) może być używana w wielu scenariuszach przesyłania wiadomości, zarówno wewnątrz komputera (tj. Między procesami), jak i między sieciami. Może przeskalować od zera do ogromnych systemów wielopasmowych o dużej przepustowości.

Obecnie oceniam to za mały, ale stosunkowo złożony system w czasie zbliżonym do rzeczywistego, w którym nie obchodzi nas, jak daleko podróżuje wiadomość i kto/co (w granicach rozsądku;) je konsumuje. Jeśli konsument siedzi na tej samej maszynie, niech tak będzie. Pozwoliłabym mu spróbować i zobaczyć, co z tego robisz. Jeśli chcesz wybić prototypowy system, użyj Pythona i biblioteki Pika.

Answer 5

Jeśli interesujesz się przede wszystkim występami w scenariuszu wewnątrz maszyny, pytanie dotyczy mniej AMQP (który jest tylko protokołem na poziomie drutu), niż to, którą implementację powinieneś wypróbować.

Usuwając opóźnienia wprowadzone przez sieć, prawdopodobnie będziesz bardziej wrażliwy na surowe wyniki różnych implementacji. Dlatego przyjrzałbym się produktom zaimplementowanym w C++, takim jak Qpid lub Zeromq.

Qpid może łatwo osiągnąć 400 000 wiadomości na sekundę (z wiadomościami o wielkości 1024 bajtów) na pewnym przyzwoitym sprzęcie (czterordzeniowy rdzeń). Zeromq będzie prawdopodobnie działał dużo lepiej, ponieważ możesz mieć kanały peer to peer, podczas gdy Qpid używa architektury brokera (która miała krok).

Answer 6

Standard AMQP jest coraz bardziej dojrzały i rozwiązuje niektóre problemy związane z owłosieniem, które nękały inne standardy przesyłania wiadomości, takie jak JMS. Na pytanie, czy warto zastąpić istniejące rozwiązanie, powiedziałbym, że to zależy. Byłbym bardzo sceptyczny, ponieważ prawdopodobnie system już działa, jest produkowany i wysoce wydajny.

Jeśli masz problemy, takie jak:

• Interoperacyjności nie działa
• nie można skalować się łatwo
• wydajność nie jest wystarczająco
• Obecne rozwiązanie jest kosztowne dobre wiadomości (aby utrzymać)

Należy zbadać wymagane prace i dokładniej przeanalizować korzyści. Jeśli jesteś już szczęśliwy, zastąpienie struktury przesyłania wiadomości nie zwróci kosztów inwestycji.