Microservices: REST vs Messaging
J'ai entendu dire qu'Amazon utilise HTTP pour son architecture basée sur les microservices. Une alternative est d'utiliser un système de messagerie comme les systèmes RabbitMQ ou Solace. J'ai personnellement de l'expérience avec l'architecture de microservices basée sur Solace, mais jamais avec REST.
Avez-vous une idée de ce qu'utilisent diverses implémentations de grandes ligues comme Amazon, Netflix, UK Gov, etc.?
Un autre aspect est, dans les microservices, les choses suivantes sont requises (en plus des autres):
* Correspondance de motifs
* Messagerie asynchrone .. le système de réception est peut-être en panne
* Publier s'abonner
* Événement de chargement du cache .. c.-à-d. Au démarrage, un service peut avoir besoin de charger toutes les données d'un couple d'autres services, et devrait être averti lorsque les données sont complètement chargées, afin qu'il puisse "savoir" qu'elles est maintenant prêt à répondre aux demandes
Ces aspects se font naturellement avec la messagerie plutôt qu'avec REST. Pourquoi quelqu'un devrait-il utiliser REST (sauf pour l'API publique). Merci.
Une norme que j'ai suivie dans le passé consiste à utiliser les services Web lorsque l'exigence clé est la vitesse (et la perte de données n'est pas critique) et la messagerie lorsque l'exigence clé est la fiabilité. Comme vous l'avez dit, si le système de réception est en panne, un message restera dans la file d'attente jusqu'à ce que le système revienne pour le traiter. Si c'est un point de terminaison REST et qu'il est en panne, les demandes échoueront simplement.