AMQP convient-il à la fois comme bus logiciel intra et inter-machine?

Question

J'essaie de me faire comprendre AMQP . Cela convient parfaitement à la communication inter-machine (cluster, LAN, WAN) entre applications, mais je ne sais pas si cela convient (en termes d’architecture et de mise en œuvre actuelle) à une utilisation en tant que bus logiciel au sein d’une seule machine.

Est-il utile de tirer un cadre actuel de transmission de messages hautes performances pour le remplacer par AMQP, ou cela tombe-t-il dans le même déroutement que RPC en estompant la distinction entre communication locale et non locale?

Je me méfie également des conséquences de l'utilisation d'une technologie de réseau étendu pour les communications intra-machine, bien que cela puisse être davantage un problème d'implémentation qu'une architecture.

Des histoires de guerre seraient appréciées.

Answer 1

AMQP n'est pas un framework RPC. Il fournit les éléments de base pour modéliser des éléments tels que les files d'attente partagées, RPC, pubsub, etc., mais il n'exige aucune manière spécifique de l'utiliser.

Si vous souhaitez partitionner votre application (en la rendant distribuable par la suite) et la relier à AMQP, je pense que c'est la bonne technologie. Il existe peut-être des alternatives plus rapides, mais probablement aucune aussi générique que AMQP.

Answer 2

L’AMQP est une spécification qui vous permet de comparer des pommes avec des oranges. Il n’existe pas vraiment de fournisseurs AMQP prêts pour la production; Au moment de la rédaction du présent document, aucun des principaux fournisseurs de messagerie ou fournisseurs de messagerie n’a pris en charge AMQP (par exemple, IBM, Tibco, Sonic, BEA, Oracle, SwiftMQ, MS, Apache ActiveMQ, openmq de Sun). Tous les fournisseurs AMQP disponibles sont donc relativement nouveaux.

Je vous recommande donc de comparer le fournisseur AMQP qui vous intéresse avec votre infrastructure de transmission de messages. Inutile d'extraire quelque chose qui fonctionne bien à cause de la façon dont il lit & amp; écrit des octets dans une socket:)

Answer 3

La norme AMQP arrive à maturité et résout certains des problèmes épineux qui ont nui aux normes de messagerie telles que JMS. A votre question de savoir s'il vaut la peine de remplacer une solution existante, je dirais que cela dépend. Je serais très sceptique, étant donné que le système fonctionne déjà, est en production et très performant.

Si vous rencontrez des problèmes tels que:

• L'interopérabilité ne fonctionne pas
• Impossible d'évoluer facilement
• Les performances ne suffisent pas
• La solution de messagerie actuelle est coûteuse (à maintenir)

Vous devriez étudier le travail requis et analyser les avantages de manière plus précise. Si vous êtes déjà satisfait, le remplacement d’un framework de messagerie n’est pas rentable.

Answer 4

Pour une base fiable et extrêmement flexible (en termes de modèles de messagerie), il peut être utilisé dans de nombreux scénarios de messagerie, à la fois intra-machine (inter-processus) et inter-réseau. Il peut évoluer de zéro à d’énormes systèmes multi-réseaux à large bande passante.

Je l’évalue actuellement pour un système petit, mais relativement complexe, en temps quasi réel où nous ne nous soucions pas de la distance parcourue par les messages ni de qui / quoi (dans des limites raisonnables) les consomme. Si un consommateur est assis sur la même machine, qu’il en soit ainsi. J'essaierais de voir ce que vous en feriez. Si vous souhaitez créer un prototype de système, utilisez python et la bibliothèque Pika .

Answer 5

AMQP ressemble plus à une offre de middleware de transport fiable pour SOA qu’à une utilisation interne.

Answer 6

Si les performances dans un scénario intra-machine vous intéressent principalement, la question est moins importante pour AMQP (qui n’est qu’un protocole filaire) que pour la mise en œuvre à essayer.

En supprimant la latence introduite par le réseau, vous serez probablement beaucoup plus sensible aux performances brutes des différentes implémentations. Par conséquent, je regarderais des produits implémentés en C ++ tels que Qpid ou Zeromq.

Qpid peut facilement atteindre 400 000 messages / seconde (avec des messages de 1024 octets) sur du matériel adéquat (quad core). Zeromq fonctionnera probablement beaucoup mieux, car vous pouvez avoir des canaux peer to peer alors que Qpid utilise une architecture de courtier (avec une étape).