Quels sont les bons exemples d'utilisation d'un système d'événements en cours de traitement par rapport aux microservices avec un courtier?

Question

J'ai vu récemment qu'il existe différents frameworks qui permettent l'utilisation d'une architecture de messagerie mais qui sont implémentés en cours, en utilisant des threads identiques et différents. Ceux que je connais sont Spring, Guava EventBus et Reactor.

Ma question concerne les cas d'utilisation où quelqu'un voudrait les utiliser plutôt que d'envoyer des messages à un courtier à part entière. Je comprends que son utilisation permet un meilleur découplage de la logique métier mais dans une architecture de microservices, vous publieriez normalement des événements à consommer par d'autres microservices. L'avantage de cela est la tolérance de panne que vous avez en ajoutant un groupe de courtiers où un message erroné causé par une défaillance dans une instance peut être réessayé par un autre. La mise en œuvre d'une logique décomposée et exécutée en envoyant des messages qui sont ensuite consommés par le même système, en particulier lorsque les abonnés sont exécutés dans des threads différents, me semble difficile de remettre les données dans un état cohérent.

Answer 1

Les avantages des microservices sur le processus ne sont pas vraiment dans le changement qu'il représente pour la consommation de messages.

Les microservices vous permettent d'exécuter une partie de votre code sur des nœuds spécifiques dans un cluster, ce qui permet d'allouer des calculs lourds sur des ordinateurs puissants et des ressources secondaires ou légères sur des ressources moins puissantes. Globalement, cela vous permet de mieux équilibrer les performances et de faire évoluer vos ressources sur les portions de code qui en ont besoin.

De même, lorsque vous mettez à jour le code d'un micro-service, vous n'avez pas d'impact sur les autres services, de sorte que vos modifications (et erreurs) sont isolées. Si tout se déroule dans le même processus, toute mise à jour incorrecte peut rendre la solution entière inutilisable. En fin de compte, sortir la communication de votre processus (courtier tiers) vous permet de la partager avec plus de personnes, d'agents, de processus, etc. Sinon, les gens doivent faire partie de votre processus (un module?) Et Ce n'est vraiment pas efficace. Honnêtement, la seule bonne raison que vous avez pour la communication intra-processus au sein de votre monolithique est pour la vitesse (communication en mémoire plutôt que la communication sur le fil).