Architecture orientée services - AMQP ou HTTP

Question

Un peu de fond.

Très gros monolithique Django. Tous les composants utilisent la même base de données. Nous devons séparer les services afin de pouvoir mettre à niveau indépendamment certaines parties du système sans affecter le reste.

Nous utilisons RabbitMQ comme courtier pour Celery.

À l'heure actuelle, nous avons deux options:

Services HTTP utilisant une interface REST.
JSONRPC sur AMQP vers un service de boucle d'événements

Mon équipe penche vers HTTP parce que c'est ce qu'elle connaît, mais je pense que les avantages de l'utilisation de RPC sur AMQP l'emportent largement.

AMQP nous offre les capacités d'ajouter facilement l'équilibrage de charge et la haute disponibilité, avec des remises de messages garanties.

Alors qu'avec HTTP, nous devons créer des wrappers HTTP clients pour travailler avec les interfaces REST, nous devons mettre en place 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.

Suis-je en train de manquer quelque chose avec mes pensées sur l'AMQP?

pinepain · Accepted Answer

En premier,

REST, RPC - modèles d'architecture, AMQP - niveau filaire et HTTP - protocole d'application qui s'exécute au-dessus de TCP/IP
AMQP est un protocole spécifique lorsque HTTP - protocole à usage général, donc, HTTP a un sacré surdébit comparé à AMQP
La nature AMQP est asynchrone alors que la nature HTTP est synchrone
les deux REST et RPC utilisent la sérialisation des données, quel format dépend de vous et cela dépend de l'infrastructure. Si vous utilisez python partout, je pense que vous pouvez utiliser = python sérialisation native - pickle qui 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 dépend vraiment de la complexité de l'infrastructure et de l'utilisation des ressources. Sans aucune exigence spécifique, les deux solutions fonctionneront bien, mais je préfère faire quelques abstractions pour pouvoir basculer entre elles de manière transparente.

Vous avez dit que votre équipe connaissait bien HTTP mais pas AMQP. Si le temps de développement est un moment important, vous avez obtenu 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 ont bien mappé sur l'interface web
les gens les connaissent
facile à déboguer (en raison de l'objectif général de HTTP)
fournir facilement une API aux services tiers.

Avantages de la solution basée sur AMQP:

sacrément rapide
souple
rentable (au 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 tandis que REST n'est pas un protocole mais plutôt un paradigme, mais vous devriez y penser en construisant votre RPC AQMP Je l'ai fait de cette manière pour fournir une API à des services tiers externes et fournir un accès à l'API sur la partie de l'infrastructure qui fonctionne sur l'ancienne base de code ou où il n'est pas possible d'ajouter le support AMQP.

Si j'ai raison, votre question est de savoir comment mieux organiser la communication entre les différentes parties de votre logiciel, pas comment fournir une API aux utilisateurs finaux.

Si vous avez un projet à forte charge, RabbitMQ est un sacré bon logiciel et vous pouvez facilement ajouter un nombre illimité de travailleurs fonctionnant sur différentes machines. Il a également une mise en miroir et une mise en cluster hors de la boîte. Et encore une chose, RabbitMQ est construit sur Erlang OTP, qui est une plate-forme stable et hautement fiable ... (bla-bla-bla), il est bon non seulement pour le marketing, mais aussi pour les ingénieurs. 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 fonctionne.

UPD (mai 2018): Saurabh Bhoomkar a publié un lien vers l'article MQ vs HTTP écrit par Arnold Shoon le 7 juin 2012, en voici une copie:

Je parcourais mes anciens fichiers et suis tombé sur mes notes sur MQ et pensais partager certaines raisons d'utiliser MQ par rapport à HTTP:

Si votre consommateur traite à un taux fixe (c'est-à-dire qu'il ne peut pas gérer les inondations vers le serveur HTTP [rafales]), l'utilisation de MQ offre la flexibilité pour le service de tamponner les autres demandes par rapport à l'enliser.

Modèles d'échange de traitement et de messagerie indépendants du temps - si le thread effectue un feu et oublie, alors MQ est mieux adapté à ce modèle par rapport à HTTP.

Les processus à longue durée de vie conviennent mieux à MQ, car vous pouvez envoyer une demande et avoir un thread séparé à l'écoute des réponses (notez que WS-Addressing permet à HTTP de traiter de cette manière mais nécessite que les deux points de terminaison prennent en charge cette capacité).

Couplage lâche où un processus peut continuer à fonctionner même si l'autre processus n'est pas disponible par rapport à HTTP devant réessayer.

Demande de priorisation où les messages les plus importants peuvent passer au premier plan de la file d'attente.

Transactions XA - MQ est entièrement compatible XA - HTTP ne l'est pas.

Tolérance aux pannes - Les messages MQ survivent aux pannes de serveur ou de réseau - HTTP ne le fait pas.

MQ prévoit une livraison "assurée" des messages une seule et unique fois, contrairement à http.

MQ offre la possibilité de segmenter et de grouper les messages pour les messages volumineux - HTTP n'a pas cette capacité car il traite chaque transaction séparément.

MQ fournit une interface pub/sub où HTTP est point à point.

UPD (décembre 2018) : Comme remarqué par @ Kevin dans les commentaires ci-dessous, il est douteux que RabbitMQ évolue mieux que les services RESTful. Ma réponse initiale était basée simplement sur l'ajout de plus de travailleurs, ce qui n'est qu'une partie de la mise à l'échelle et tant que la capacité d'un courtier AMQP unique n'est pas dépassée, il est vrai, bien qu'après cela, cela nécessite des techniques plus avancées comme Hautement disponible (Miroir) ) Queues , ce qui fait que les services HTTP et AMQP ont une complexité non triviale à l'échelle au niveau de l'infrastructure.

Après mûre réflexion, j'ai également supprimé que la maintenance du courtier AMQP (RabbitMQ) est plus simple que n'importe quel serveur HTTP: la réponse originale a été écrite en juin 2013 et a beaucoup changé depuis ce temps, mais le principal changement est que j'obtiens plus d'informations sur les deux approches. , donc du mieux que je puisse dire maintenant que "votre kilométrage peut varier".

Notez également que la comparaison de HTTP et AMQP est Apple aux oranges dans une certaine mesure, donc s'il vous plaît, n'interprétez pas cette réponse comme le guide ultime sur lequel baser votre décision, mais prenez-la plutôt comme l'une des sources ou comme référence pour vos recherches ultérieures pour savoir quelle solution exacte correspondra à votre cas particulier.

Chris Johnson · Answer

L'ironie de la solution qu'OP devait accepter est que AMQP ou d'autres solutions MQ sont souvent utilisées pour isoler les appelants de la non-fiabilité inhérente des services HTTP uniquement - pour fournir un certain niveau de logique de délai d'attente et de nouvelle tentative et de persistance des messages afin que l'appelant ne le fasse pas '' Je n'ai 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 la meilleure solution pour ce scénario.