Architecture orientée services-AMQP ou HTTP
Un peu d'arrière-plan.
Très grande application Django monolithique. Tous les composants utilisent la même base de données. Nous devons séparer les services afin que nous puissions indépendamment mettre à niveau certaines parties du système sans affecter le reste.
Nous utilisons RabbitMQ comme courtier pour le céleri.
En ce moment, nous avons deux options:
- Services HTTP utilisant une interface REST.
- JSONRPC sur AMQP vers un service de boucle d'événements
Mon équipe se penche vers HTTP parce que c'est ce qu'ils connaissent mais je pense que les avantages de L'utilisation de RPC sur AMQP l'emportent largement.
AMQP nous permet d'ajouter facilement l'équilibrage de charge et la haute disponibilité, avec des livraisons de messages garanties.
Alors qu'avec HTTP, nous devons créer des wrappers HTTP clients pour travailler avec les interfaces REST, nous devons mettre un équilibreur de charge et configurer cette infrastructure afin D'avoir HA etc.
Avec AMQP, je peux simplement générer une autre instance du service, il se connectera à la même file d'attente que les autres instances et BAM, HA et l'équilibrage de charge.
Est-ce que je manque quelque chose avec mes pensées sur AMQP?
2 réponses
Au début,
- REST, RPC - architecture patterns, AMQP-Wire-level et HTTP - application protocol qui s'exécutent sur TCP / IP
- AMQP est un protocole spécifique lorsque le protocole HTTP-general-purpose, ainsi, HTTP a une surcharge sacrément élevée par rapport à AMQP
- la nature AMQP est asynchrone où la nature HTTP est synchrone
- REST et RPC utilisent tous deux la sérialisation des données, quel format dépend de votre infrastructure. Si vous utilisez python partout je pensez que vous pouvez utiliser la sérialisation native python -
picklequi devrait être plus rapide que JSON ou tout autre format. - HTTP + REST et AMQP+RPC peuvent s'exécuter dans un environnement hétérogène et/ou distribué
Donc, si vous choisissez quoi utiliser: HTTP + REST ou AMQP+RPC, la réponse est vraiment sujette à la complexité de l'infrastructure et à l'utilisation des ressources. Sans aucune exigence spécifique, les deux solutions fonctionneront bien, mais je préférerais faire une abstraction pour pouvoir basculer entre elles transparent.
Vous avez dit que votre équipe était familière avec HTTP mais pas avec AMQP. Si le temps de développement est un moment important, vous avez une réponse.
Si vous voulez construire une infrastructure HA avec une complexité minimale, je suppose que le protocole AMQP est ce que vous voulez.
J'ai eu une expérience avec les deux et les avantages des services RESTful sont:
- ils sont bien mappés sur l'interface web
- les gens les connaissent
- facile à déboguer (en raison de l'objectif général de HTTP)
- Facile fournir API à des services tiers.
Avantages de la solution basée sur AMQP:
- sacrément rapide
- flexible
- facile à entretenir
- facile à mettre à l'échelle
- rentable (dans le sens de l'utilisation des ressources)
Notez que vous pouvez fournir une API RESTful à des services tiers en plus de votre API basée sur AMQP alors que REST n'est pas un protocole mais plutôt un paradigme, mais vous devriez y penser en construisant votre api RPC AQMP. Je l'ai fait dans de cette façon, fournir une API à des services tiers externes et fournir un accès à L'API sur les parties de l'infrastructure qui s'exécutent sur l'ancienne base de code ou où il n'est pas possible d'ajouter le support AMQP.
Si j'ai raison, votre question porte sur la façon de mieux organiser la communication entre les différentes parties de votre logiciel, pas sur la façon de fournir une API aux utilisateurs finaux.
Si vous avez un projet à forte charge RabbitMQ est sacrément bon morceau de logiciel et vous pouvez facilement ajouter n'importe quel nombre de travailleurs qui fonctionnent sur différentes machines. En outre, il a la mise en miroir et le clustering hors de la boîte. Et encore une chose, RabbitMQ est construit sur Erlang OTP, qui est une plate-forme stable et fiable ... (bla-bla-bla), il est bon non seulement pour le marketing, mais pour les ingénieurs aussi. J'ai eu un problème avec RabbitMQ une seule fois lorsque les journaux nginx ont pris tout l'espace disque sur la même partition où RabbitMQ s'exécute.
L'ironie de la solution OP a dû accepter is, AMQP ou d'autres solutions MQ sont souvent utilisées pour isoler les appelants du manque de fiabilité inhérent des services HTTP uniquement - pour fournir un certain niveau de timeout & réessayer la logique et la persistance des messages afin que l'appelant n'ait pas à implémenter son propre code D'isolation HTTP. Une passerelle HTTP très fine ou une couche d'adaptateur sur un noyau AMQP fiable, avec l'option d'aller directement à AMQP en utilisant un protocole client plus fiable comme JSONRPC serait souvent le meilleur la solution à ce scénario.