Hello !
Suite au dernier article je vais présenter comment Service Fabric peut nous aider à répondre à certaines problématiques liées à la mise en œuvre de microservices. Aujourd’hui l’aspect communication !
Cet article est une “réponse” aux questions soulevées ici !
Communication clients / services
Nous avons deux possibilités pour qu’un client (web, application Windows, mobile) puissent échanger avec un service :
- Communication directe
- Ou en utilisant un composant intermédiaire : un API Gateway
Nous pouvons alors développer notre propre API Gateway :
Ou utiliser une passerelle de Type Azure API Management :
Cet outil permet de configurer simplement un API Gateway dans Azure. Il n’y a pas de développement supplémentaire à produire.
APIM est conçue pour :
- Gérer les API complexes avec des règles de routage
- Un contrôle d’accès (Authentification)
- Une surveillance
- Une journalisation des événements
- Une mise en cache des réponses
Attention en contrepartie notre point d’accès unique à notre API est par définition un point de défaillance important de notre système. S’il tombe, il n’y a plus de communication possible. Du côté du trafic réseaux il peut également devenir un goulot d’étranglement s’il ne s’adapte pas à la charge.
Communication entre services
Pour la communication entre services nous avions listé deux possibilités :
- Echange synchrone via commande HTTP
Attention ici il s’agit bien de l’appel qui est synchrone dans le sens ou le contact entre les deux services est direct. Au niveau applicatif l’appel peut être asynchrone dans le sens ou le client peut faire un traitement en attendant une réponse du service.
Si la communication entre services est directe, cela implique que les services sachent à quelle adresse ils peuvent s’appeler. Pour cela, Azure Service Fabric nous propose une solution de Reverse Proxy.
Au démarrage d’un service celui-ci vient s’identifier auprès du service d’attribution de noms d’ASF. Celui-ci tient une table qui mappe les instances de service et les adresses de point de terminaison :
La résolution et la connexion aux services impliquent l’exécution des étapes suivantes en boucle :
- Obtenir le point de terminaison publié par un service à partir du Service d’attribution de noms.
- Se connecter au service sur le point de terminaison en question.
- Si la tentative de connexion échoue, les étapes précédentes de résolution et de connexion doivent être réessayées, et ce cycle se répète jusqu’à ce que la connexion aboutisse ou qu’elle soit désactivée (Pattern circuit breaker)
Appel entre services :
Appel depuis l’extérieur :
Dans les deux cas c’est le reverse proxy qui nous renseigne sur les url des instances de services accessibles.
- Échange asynchrone via un bus d’évènement basé sur le protocole AMQP.
Si nos besoins nous conduisent vers une communication asynchrone, nous pouvons utiliser Azure Service Bus. Il y a alors deux cas d’utilisation.
-
- Les files d’attente
Elles permettent une communication unidirectionnelle. Chacune agit comme un intermédiaire (ou broker) qui stocke les messages envoyés jusqu’à leur réception. Chaque message est reçu par un destinataire unique.
Il s’agit du cas le plus simple pour une communication par message : un émetteur, une file d’attente, un destinataire.
- Les rubriques
Les expéditeurs envoient les messages à la rubrique de la même façon qu’ils envoient des messages dans la file d’attente. Ces messages ont le même aspect.
À l’inverse des files d’attente cependant, un message unique envoyé à une rubrique peut être reçu par plusieurs abonnements. Cette approche, communément appelée publication et abonnement (ou pub/sub), est utile quand plusieurs applications sont intéressées par les mêmes messages.
Les files d’attente et les rubriques dans Azure Service Bus se basent sur le protocole AMQP : ce protocole de messagerie open standard permet le développement d’applications basées sur des messages à l’aide de composants créés avec plusieurs langages, infrastructures et systèmes d’exploitation.
Qu’il s’agisse d’une communication synchrone via appel HTTP ou asynchrone avec Azure Service Bus, les deux implémentations sont possibles avec Azure Service Fabric. Les deux solutions ont des avantages et des inconvénients, à chacun de les mesurer en amont du projet !
