Architecture orientée services – AMQP ou HTTP

Un peu de fond

Très grande application monolithique de Django. Tous les composants utilisent la même firebase database. Nous devons séparer les services pour pouvoir mettre à niveau de manière indépendante certaines parties du système sans affecter le rest.

Nous utilisons RabbitMQ en tant que courtier pour Celery.

En ce moment nous avons deux options:

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

Mon équipe se penche vers HTTP car c’est ce à quoi ils sont habitués, mais je pense que les avantages de l’utilisation de RPC sur AMQP l’emportent largement.

AMQP nous offre la possibilité d’append facilement un équilibrage de charge et une haute disponibilité, avec des livraisons de messages garanties.

Alors qu’avec HTTP, nous devons créer des wrappers HTTP client pour travailler avec les interfaces REST, nous devons installer un équilibreur de charge et configurer cette infrastructure pour disposer de HA, etc.

Avec AMQP, je peux simplement générer une autre instance du service, celle-ci se connectera à la même queue que les autres instances et à bam, HA et à l’équilibrage de charge.

Est-ce que quelque chose me manque dans mes pensées sur le programme AMQP?

En premier,

  • REST, RPC – modèles d’architecture, AMQP – niveau de câble et HTTP – protocole d’application qui s’exécute sur TCP / IP
  • AMQP est un protocole spécifique lorsque HTTP – protocole à usage général, ainsi HTTP a une surcharge é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 vous et de l’infrastructure. Si vous utilisez Python partout, je pense que vous pouvez utiliser la sérialisation native de python – 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 dissortingbué

Donc, si vous choisissez ce qu’il faut utiliser: HTTP + REST ou AMQP + RPC, la réponse est vraiment liée à la complexité de l’infrastructure et à l’utilisation des ressources. Sans exigences spécifiques, les deux solutions fonctionneront correctement, mais je préférerais faire des abstractions pour pouvoir basculer entre elles de manière transparente.

Vous avez dit que votre équipe connaît bien 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 les suivants:

  • ils ont bien mappé sur l’interface web
  • les gens les connaissent
  • facile à déboguer (en raison de l’objective général de HTTP)
  • facile à fournir API aux services tiers.

Avantages de la solution basée sur AMQP:

  • sacrément rapide
  • flexible
  • facile à maintenir
  • facile à l’échelle
  • rentable (en termes d’utilisation des ressources)

Notez que vous pouvez fournir l’API RESTful aux services tiers au-dessus de votre API basée sur AMQP, alors que REST n’est pas un protocole mais plutôt un paradigme, mais vous devriez penser à construire votre API RQ AQMP. Je l’ai fait de cette manière pour fournir une API à des services tiers externes et fournir un access à l’API sur les parties de l’infrastructure qui s’exécutent sur une ancienne base de code ou lorsqu’il est impossible d’append une prise en charge AMQP.

Si je ne me trompe pas, votre question porte sur la manière de mieux organiser la communication entre les différentes parties de votre logiciel, et non sur la façon de fournir une API aux utilisateurs finaux.

Si vous avez un projet à forte charge, RabbitMQ est un bon logiciel et vous pouvez facilement append un nombre illimité d’employés sur différentes machines. En outre, il a la mise en miroir et la mise en cluster hors de la boîte. Et encore une chose, RabbitMQ est basé sur Erlang OTP, une plate-forme stable et hautement fiable … (bla-bla-bla), non seulement pour le marketing, mais aussi pour les ingénieurs. J’ai rencontré 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 est exécuté.

L’ironie de la solution que doit accepter OP est que les solutions AMQP ou MQ sont souvent utilisées pour isoler les appelants du manque de fiabilité inhérent aux services HTTP uniquement – pour fournir un certain niveau de logique t mettre en œuvre son propre code d’isolation HTTP. Une passerelle HTTP ou une couche d’adaptateur très fine sur un cœur 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.