J'implémente une communication de style RPC à l'aide de RabbitMQ avec l'idée de créer une architecture de pipeline asynchrone. Je travaille avec Java Spring et AMQP.
J'effectuerai une chaîne de communication de type RPC - une communication avec un serveur en déclenchera un autre, et un autre en déclenchera un autre, jusqu'à ce que finalement arrivé à la fin de la chaîne et que le serveur commençant la chaîne reçoive la réponse finale . J'ai trouvé deux techniques qui semblent convenir à mon besoin:
asyncRabbitTemplate convertSendAndReceive (...) : push en utilisant cette méthode, une fois qu'un consommateur reçoit, déclenchez un autre convertSendAndReceive (... ) et ainsi de suite ... une chaîne, jusqu'à ce que le résultat final se retrouve sur le serveur qui a initié l'ensemble du processus.
utilisez le modèle push / subscribe, où un producteur va pousser en utilisant convertAndSend (...) , un consommateur écoutera via @RabbitListen et poussera vers un autre qui écoute et ainsi de suite; dans cette configuration, le serveur avec l'appel initial convertAndSend (...) recevra la réponse finale.
Je ne sais pas quelle est la différence entre ces approches? Quand opter pour l'un ou l'autre? Y a-t-il un compromis de performance? L'un nécessite-t-il plus d'efforts de programmation que l'autre?
3 Réponses :
Je pense qu'il y a un problème conceptuel ici. Je n'ai pas d'outil de diagramme de séquence sous la main, mais en RPC,
Tout autre élément que celui-ci n'est PAS RPC. Les autres termes que j'ai utilisés pour décrire cela sont «demande / réponse» et «client / serveur». C'est le modèle utilisé par à peu près tous les services Web, il est donc omniprésent dans l'architecture des applications.
La pratique que vous semblez décrire ici est connue sous le nom de chaînage d'événements . Cela semble assez simple dans le concept, mais ce que vous avez en fait est une série d'actions indépendantes s'orchestrant toutes. C'est ainsi que fonctionne le monde réel, et une caractéristique clé du monde réel est qu'il est non déterministe . Cela signifie que, étant donné la même séquence d'actions, la sortie résultante n'est pas garantie d'être la même.
La plupart des programmes informatiques reposent sur un comportement déterministe, où les mêmes entrées donnent toujours exactement les mêmes résultats.
Cela aurait dû être un commentaire sur la réponse de @ theMayer. Cependant, je voudrais développer le détail de RPC avec une image. @theMayer, n'hésitez pas à intégrer cette image si vous le souhaitez, je supprimerais cette réponse.
Un appel RPC s'exécute généralement comme ci-dessous:
N'hésitez pas à modifier ma réponse. Le diagramme est un peu plus compliqué que ce que j'aurais probablement dessiné mais il est toujours valable.
Si je comprends bien, vous créez une cascade d'événements qui devraient se terminer au début. Le modèle RPC est destiné aux appels directs entre deux parties qui se connaissent.
Donc, vous pouvez certainement aller avec des sujets, si vous pouvez définir comment vos données se transforment après chaque station (ie metal_bar -> squeezed_metal_bar -> curved_metal_bar -> cuillère), cela permettra de mettre à l'échelle chaque station indépendamment et même d'ajouter des services qui surveillent / réagir à l'une des étapes sans rien changer d'autre, mais méfiez-vous de la mise à l'échelle de l'appelant initial - vous pourriez avoir besoin d'une solution pour ce problème
Je ne sais pas si c'est une question à laquelle on peut répondre, mais juste mes 2 cents - un modèle d'enchaînement des messages de cette façon est susceptible de conduire à de mauvais résultats et à la déception. Vous devez être en mesure de gérer le flux de travail dans son ensemble et de redémarrer les opérations ayant échoué.