Microservices, exemple d’implémentation

Après un premier article décrivant les avantages de l’architecture microservice, il nous semble intéressant d’approfondir encore le sujet en partant d’un besoin business et en y répondant par une implémentation de cette architecture.
Le besoin que nous allions étudier est issu du use-case décrit dans l’article « Architectures de la transformation digitale » et peut-être résumé pour ce qui nous concerne, par les éléments suivants :

  • ClouDigit est leader de la fabrication et distribution en magasin de clou et s’appuie sur une chaine logistique éprouvée et décentralisée ;
  • Cette structure rachète le site clou.net, qui pour sa part, est un acteur incontournable de la commercialisation e-commerce et s’appuie en conséquence sur une plateforme de vente fonctionnelle et une logistique centralisée ;
  • Il est décidé de mutualiser les forces de ces deux structures et ainsi de créer une nouvelle offre commercialisable à partir du site web, en l’occurrence un retrait boutique dans les 2 heures.

Bien entendu, dans le cadre de cette nouvelle offre il ne faut pas décevoir le client final. En conséquence une vérification de la disponibilité des stocks de la/les boutique(s) près de chez lui sera un préalable à la proposition de ce nouveau service.

 

Pourquoi ce sujet ?

Bien entendu, je pourrais vous expliquer qu’en tant qu’auteur de l’article, je fais ce que je veux. Mais je préfère vous expliquer pourquoi une architecture microservice est particulièrement adaptée à ce besoin.

De fait, si on se rappelle le concept des microservices (article « Microservices, le concept. »), et d’après cette définition, un microservice se doit d’être élastique, tolérant, ouvert, minimal et complet auxquels on peut rajouter stable et autonome.

Or, si on détaille notre besoin on constate que :

  • Le besoin est nouveau et n’est couvert par aucune brique du SI existant ;
  • Le périmètre fonctionnel est limité et indépendant des fonctionnalités du site web existant ou des outils de logistique. Il peut donc être décrit comme une fonctionnalité complémentaire et indépendante. Cependant cette fonctionnalité devra pouvoir s’intégrer au site web existant afin que les utilisateurs puissent l’utiliser et devra permettre de faire le lien entre le site e-commerce , sa chaîne logistique centralisée et la chaîne logistique décentralisée de ClouDIgit, permettant ainsi de tirer le meilleur parti des deux. Cette fonctionnalité aura pour objectif de :
    • Connaître les boutiques ;
    • Connaître les stocks de produits des boutiques et leurs mouvements ;
    • Émettre des réservations de stocks ;
    • Transmettre des bons de préparation aux boutiques ;
    • Prévenir un internaute qu’une commande est disponible en boutique ;
    • Avoir connaissance qu’un retrait boutique est effectif ;
    • Mettre à jour les stocks de la boutique.

Ce périmètre restreint et limité peut donc tout à fait être décomposé (ou pris en charge) par un (ou plusieurs) microservice(s).  De plus ils pourront être mis à disposition d’autres applications, afin d’exploiter les données de gestion des stocks et des commandes en boutique de proximité, comme l’application de gestion des approvisionnements …

  • Les concepts et connaissances métiers nécessaires pour répondre à ce besoin ne sont pas dans le scope de l’équipe s’occupant du site web (stock, boutique) et donc certainement, ce n’est pas cette équipe qui s’occupera de cette implémentation ;
  • La criticité de ce module est différente de celle du site web mais surtout ne doit pas impacter/déstabiliser ce dernier en cas d’indisponibilité.

On peut donc remarquer que cette nouvelle fonctionnalité (brique fonctionnelle), doit répondre à des caractéristiques qui correspondent aux problématiques traitées par les architectures microservice.

Besoin business

Les besoins du site web sont :

  • Avoir la liste des agences pouvant effectuer cette opération de retrait boutique (ouverture, localisation et stock suffisant) ;
  • Pouvoir choisir une boutique de retrait ;
  • Afficher les coordonnées de l’agence choisie (checkout et email de confirmation de commande) ;
  • Etre assuré que le stock est réservé, jusqu’à la fin de la transaction (expérience utilisateur).

Les besoins de la boutique sont :

  • Etre informé qu’une commande doit être préparée ;
  • Ne pas tomber en rupture de stock et pouvoir préparer la commande ;
  • Pouvoir indiquer qu’une commande a été préparée et que l’internaute peut passer retirer sa commande ;
  • Indiquer que la commande a été retirée par l’internaute (maj des stocks).

 

Organisation microservice

De fait, l’analyse des besoins et des fonctionnalités de ces derniers montrent qu’ils peuvent être décomposés en trois fonctions indépendantes … ça sera les 3 microservices :

  • Les boutiques ;
  • Les stocks ;
  • Les demandes de retrait boutique.

Ce sont les trois microservices que nous allons donc implémenter dans notre architecture et détailler ci-dessous.
Ces trois microservices communiqueront par l’intermédiaire de deux mécanismes : API REST (synchrone) et bus de messages (asynchrone).

Pour mémoire et pour rappel, les API REST sont le moyen d’exposer les fonctionnalités rendues par les microservices à des clients extérieurs (ici le site web, demain une application mobile ou un autre client ayant besoin de ces services), mais servent très peu à communiquer entre eux, puisqu’un microservice est autonome (d’un point de vue données et fonctionnalités).

Par contre si deux microservices doivent échanger de l’information, la bonne pratique veut qu’ils communiquent par un bus de message. Le cas d’une communication entre deux microservices par message est lorsqu’un microservice doit signaler qu’il a fini son traitement et que le résultat doit être traité par un autre microservice.

Le seul cas où deux microservices communiquent par API REST est lorsqu’un microservice doit appeler un microservice d’un tiers (ex : mon microservice a besoin de récupérer des données météo qui sont fournies par un organisme externe ou dans notre cas appeler les services de géolocalisation du fournisseur de gestion des tournées de livraison).

Ainsi, concernant la communication asynchrone utilisée par les microservices, nous allons baser notre implémentation sur un bus applicatif et en l’occurrence par l’abonnement à certains événements.

Nous distinguerons deux types d’événements :

  • Des événements d’action dont le but est de lancer des actions.

Exemples :

    • Maj des stocks ;
    • Demande de retrait boutique.
  • Des événements de synchronisation qui sont issus soit des microservices, soit de l’environnement extérieur et qui vont permettre de synchroniser les bases internes.

Exemples :

    • Modification de stock physique ;
    • Modification d’information sur une agence.

Bien entendu, plusieurs microservices peuvent s’abonner au même événement (mais pas dans notre exemple).

 

Le microservice « demande retrait boutique » (DRB)

 

Ce microservice ne contiendra qu’une table, elle est cependant vitale à toute cette implémentation.
Cette table contiendra les informations suivantes :

  • Identifiant unique de réservation ;
  • Identifiant du panier (clef unique du site web) ;
  • Identifiant boutique ;
  • Identifiant produit ;
  • Quantité de la commande ;
  • Date et heure de la réservation (si on veut gérer en automatique, l’abandon de panier et donc l’annulation automatique de réservation au bout d’un certain temps – non abordé ici) ;
  • Statut de cette demande (potentielle / annulée / confirmée / retrait prêt / retirée) ;
  • Numéro de commande web (à partir du statut confirmée) ;
  • Information sur l’internaute (à partir du statut confirmée).

L’identifiant unique de réservation est l’information que devra transmettre le site web lors de la validation finale de la commande (après le paiement) .

Le microservice exposera via son API REST les services permettant aux clients de :

  • Lister les boutiques disponibles pour un retrait ;
  • Faire une réservation de stock ;
  • Interroger une réservation ;
  • Lister les commandes en attente de préparation et/ou à retirer ;
  • Changer le statut d’une commande.

    Il permettra également aux autres microservices : 

    • D’être informé du changement de statut d’une commande.

 

 

Le microservice  « boutique »

 

C’est un microservice dont la structure BDD contiendra :

  • L’adresse de la boutique ;
  • Les horaires d’ouverture des boutiques.

Le microservice exposera via son API REST les services permettant aux clients :

    • D’obtenir la liste des boutiques ouvertes près d’une localisation ;
    • D’obtenir des informations sur une boutique.
  • Par abonnement :
    • De synchroniser l’ERP avec la base d’agence utilisée par le microservice ;
    • D’être informé qu’une nouvelle commande de « retrait boutique », doit être traitée par une agence.

 

 

 

 

Le microservice  « stock »

C’est un microservice dont la structure BDD contiendra  :

  • Un code produit et un libellé ;
  • Une structure détaillant :
    • Code produit ;
    • Identifiant agence ;
    • Quantité en stock ;
    • Quantité réservée.

Le microservice exposera via son API REST les services permettant aux clients :

  • D’obtenir le libellé d’un produit ;
  • D’obtenir une quantité de stock disponible dans une boutique.
  • Par abonnement :
    • Synchroniser l’ERP avec la base produit utilisée par le microservice ;
    • Synchroniser le stock du produit avec les autres composantes du SI ;
    • Faire une réservation de stock ;
    • Mettre à jour un stock.

 

 

 

Ainsi comme on le voit sur nos 3 microservices,  deux sont très simples (boutique et stock) et demanderont très peu d’évolution à moyen terme.
Le microservice « demande retrait boutique », lui est un peu plus complexe, mais finalement si vous regardez bien, pas tant que ça (Il y a beaucoup de schémas).
Donc en résumé, et pour l’instant, nous avons une architecture simple, qui répond aux besoins et qui va s’intégrer facilement.

Intégration des microservices

Sur le site web

Choix d’une boutique :

Le besoin du microservice est de connaître un identifiant unique de panier, connaître la localisation de l’internaute, le produit et la quantité commandée avant de pouvoir potentiellement proposer une liste de boutiques possibles pour le retrait boutique.

L’affichage de cette liste sera effectué indirectement , par réception de l’API d’un flux de données qui sera intégré et affiché après retraitement et validation par le client.
La présentation et l’action de choisir la boutique est à la discrétion de l’équipe web, mais devra de toute manière lors du choix appeler le microservice et l’API « Faire une réservation de stock ».

Le microservice aura également besoin de communiquer et stocker l’identification de réservation et l’identification de la boutique sur la commande. Pour ce faire, il faudra ouvrir une API se basant sur l’identifiant panier.

 

Affichage/utilisation des informations d’une boutique :

Appel du microservice « Interroger une réservation ».

Validation de la commande :

A l’enregistrement de la commande, génération d’un message « Changement-statut-commande » pour confirmer la commande.
Le microservice aura également besoin de lire des informations sur la commande (No de commande, information sur le client). Demande donc d’une API de lecture implémentée sur le site web.

Dans l’extranet « boutique »

 

Commande prête ou retirée par le client

Comme pour le site web cette liste sera affichée indirectement, par réception de l’API d’un flux de données et intégration et l’affichage de ces données après retraitement.
La présentation et l’action de choisir la boutique sont à la discrétion de l’équipe intranet, mais devront de toute manière lors du choix appeler le microservice et l’API « Changement-statut-commande »

 

Conclusion

 

En conclusion le workflow complet de cette implémentation, peut donc résumé par le schéma suivant :

Comme on peut le voir, cette architecture est simple et son intégration au sein d’outils tiers aisée. Elle permet de gérer la scalabilité et la flexibilité de ces services métiers indépendamment du reste du système. Mais, un autre avantage est que cette architecture, et l’implémentation de ces microservices, permet à toutes les applications du système d’information d’utiliser ces informations et ces fonctionnalités en appelant les interfaces fournies. L’application utilisant les fonctionnalités n’a alors pas à s’occuper de la logique métier propre à ces fonctions.

 

La difficulté est déportée alors du côté de l’implémentation du microservice sans impact sur le front
De la même manière, en cas de défaillance des microservices, que se passe-t-il sur le front-office ? Rien.
Certes on ne propose pas de retrait boutique mais on continue à vendre, le dysfonctionnement du microservice est limité à son domaine et n’impacte pas ; ne doit pas impacter l’application où il est inclus.
Cependant, si cette approche limite les dysfonctionnements, elle a également un effet négatif.
C’est pour cela qu’il est primordial dans le cadre d’implémentation de cette architecture de mettre en place des outils de monitoring pointus et détaillés permettant de :

  • Remonter les anomalies des microservices,  et donc d’identifier les dysfonctionnements ;
  • Surveiller leurs capacités (temps de réponses, trafic entrant) et en conséquence agir sur le dimensionnement de l’architecture.

Comme je l’espère, l’implémentation des microservices est maintenant démystifiée et passée du stade « oui je connais » à « oui en effet je comprends ».