Communication et Azure Service Fabric

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

1 3 - Communication et Azure Service Fabric

  • Ou en  utilisant un composant intermédiaire : un API Gateway

Nous pouvons alors développer notre propre API Gateway :

2 3 - Communication et Azure Service Fabric

Ou utiliser une passerelle de Type Azure API Management :

3 3 - Communication et Azure Service Fabric

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 :

4 3 - Communication et Azure Service Fabric

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 :

5 3 - Communication et Azure Service Fabric

Appel depuis l’extérieur :

6 3 - Communication et Azure Service Fabric

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.

7 3 - Communication et Azure Service Fabric

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.

8 2 - Communication et Azure Service Fabric

  • 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.

9 2 - Communication et Azure Service Fabric

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.

10 2 - Communication et Azure Service Fabric

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 !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *