Créer un microservice adapté à vos besoins

Ce blog est basé sur la présentation de Haylee Millar lors de la conférence Symfony 2024. Haley est ingénieure produit chez Upsun. Nous avons utilisé des outils d'IA pour la transcription et pour améliorer la structure et la clarté du contenu.

Face à un système vieillissant qui nécessite de nouvelles fonctionnalités, de nombreuses équipes de développement se trouvent à la croisée des chemins. Faut-il corriger l'ancien système et prendre le risque d'une dette technique, ou faut-il se lancer dans l'architecture microservices ? Voici l'histoire d'une équipe qui a pris cette décision et ce qu'elle a appris en cours de route.

Qu'est-ce qu'un microservice ?

Un microservice est un service indépendant qui communique avec d'autres services via des API. Chaque service est faiblement couplé et peut être construit, déployé et mis à l'échelle de manière autonome. Il n'est pas nécessaire qu'il dispose d'une base de données, mais c'est souvent le cas. La clé réside dans la séparation, qui permet de modifier un service sans avoir à modifier l'ensemble de l'application.

Pensez-y comme à la cuisine d'un restaurant. Dans une approche monolithique, un seul chef s'occupe de tout : les entrées, les plats principaux, les desserts et les boissons. Avec les microservices, vous disposez de postes spécialisés : un chef salade, un maître grilladin, un chef pâtissier et un barman, chacun expert dans son domaine, mais coordonnant leurs efforts pour servir des repas complets.

Avantages

• Évolutivité : ajoutez des ressources aux services selon les besoins, plutôt que de faire évoluer l'ensemble de l'application.
• Rapidité : des bases de code plus petites facilitent le développement et le déploiement.
• Liberté technologique : choisissez la stack qui convient à chaque service. Vous n'êtes pas obligé d'utiliser le même langage ou le même cadre partout.
• Isolement des pannes : un service peut tomber en panne sans entraîner la défaillance de l'ensemble de l'application. Vous pouvez réduire les performances plutôt que de vous déconnecter.

Inconvénients

• Complexité : plus il y a de services, plus il y a de composants mobiles. Les appels réseau remplacent les appels en cours de traitement. Les données peuvent se trouver à plusieurs endroits, ce qui rend la cohérence plus difficile à assurer.
• Débogage : il peut être difficile d'identifier la source d'un problème dans un système distribué. Une journalisation rigoureuse, des identifiants de requête et un traçage distribué peuvent aider.
• Surface de sécurité : plus de services et plus de chemins réseau signifient plus de sécurité à assurer.

Quand choisir les microservices

Les microservices peuvent être une solution appropriée lorsque plusieurs équipes ont besoin d'autonomie, lorsque différentes fonctionnalités évoluent à des vitesses variables et lorsque vous avez besoin d'un développement, d'un déploiement et d'une mise à l'échelle indépendants pour des parties spécifiques de l'application. Ils ne sont pas la seule réponse. Il existe généralement plusieurs façons de résoudre un problème. Choisissez l'approche qui correspond le mieux à vos besoins et à vos contraintes.

Le véritable problème que nous devions résoudre

Notre équipe est responsable de la gestion des comptes. Nous gérions un site interne basé sur un monolithe Drupal. Nous avions prévu de le retirer, mais nous avions un problème immédiat à résoudre : l'utilisation abusive du produit par les utilisateurs.

Nous aurions pu ajouter de nouvelles fonctionnalités anti-abus à l'application Drupal. Nous avons choisi de ne pas le faire. Raisons :

• Nous ne voulions pas alourdir un système que nous avions prévu de retirer.
• Nous voulions agir rapidement sans être limités par les exigences spécifiques à Drupal.
• Nous disposions déjà de services externes à Drupal qui s'y intégraient, comme l'authentification et les organisations.

Nous avons proposé un nouveau microservice pour mettre en œuvre une logique anti-abus. Cette solution a remporté l'adhésion générale lors de nos discussions.

Le service que nous avons créé : KYC

Nous avons créé un microservice Symfony appelé Know Your Customer (KYC). KYC vérifie l'identité et le risque des clients. Nous avons délibérément commencé à petite échelle afin de pouvoir livrer rapidement et apprendre.

Commencer petit et intelligemment

Nous nous sommes concentrés sur cinq éléments fondamentaux :

• La synchronisation des données utilisateur garantissait que le service disposait des informations nécessaires.
• Un point de terminaison de score utilisateur pour l'équipe d'assistance.
• Un point de terminaison pour la vérification du personnel et la possibilité de bloquer un utilisateur en cas de détection d'abus.
• Des listes d'autorisation pour permettre au personnel interne de tester et de contourner les restrictions si nécessaire.

Nous avons clairement défini les responsabilités. Le KYC calculait un score, mais ne décidait pas de limiter les ressources. Notre service de comptabilité récupérait le score KYC et décidait de poursuivre ou d'interrompre l'action d'un utilisateur.

Choix de la stack et des outils

• PHP avec le framework Symfony, afin de pouvoir nous concentrer sur la logique plutôt que d'écrire tout à partir de zéro.
• PHPUnit pour les tests.
• GitLab CI/CD pour l'intégration continue, la livraison et le déploiement automatique.
• Un planificateur pour les tâches de synchronisation et les listes d'autorisation. Bundles et
  bibliothèques courants : framework JOSE, LexikJWTAuthenticationBundle pour JWT, CORS, Doctrine et Doctrine Migrations.

À partir de la version 1.7, nous avons ajouté Symfony Messenger pour synchroniser les scores IP à partir d'un service externe.

Hébergement et processus

Nous avons hébergé le service sur notre plateforme, car nous sommes une entreprise de plateforme en tant que service. Pour les équipes curieuses de déployer Symfony, nous avons montré comment configurer une application de démonstration à l'aide de la ligne de commande Symfony et comment initialiser un projet existant, ajouter les fichiers nécessaires et le déployer.

Comment cela a évolué

Nous avons finalisé la conception du KYC en juin 2022. Il a fallu environ six mois pour le mettre en œuvre après que les parties prenantes se soient mises d'accord. Depuis lors, nous avons maintenu un rythme de publication régulier. Au moment de la présentation, nous en étions à la version 2.23.

Ce qui a changé entre les versions 1.0 et 2.23 :

• Plus de types de scores : risque global, client connu, essais gratuits et tests.
• Des profils de paiement qui aident à décider des méthodes de paiement à autoriser.
• Contrôles externes des risques pour l'adresse IP et le mode de paiement.
• Premiers pas vers l'apprentissage automatique.
• Travail continu pour enrichir la logique de notation des utilisateurs.

Ce qui a bien fonctionné

• Itération rapide : KYC est un petit service qui ne fait pas partie du monolithe, ce qui nous permet de le déployer rapidement. Nous pouvons publier plusieurs versions en une journée sans mettre en péril l'ensemble de l'application.
• Plus de fonctionnalités plus rapidement : cette rapidité nous permet d'ajouter des fonctionnalités utiles pour l'équipe d'assistance et d'améliorer progressivement la logique de notation.
• Stack à jour : Symfony et PHP restent à jour sans être liés à un ancien système que nous prévoyons de retirer.
• Économies de ressources : le développement plus rapide et la mise à l'échelle ciblée permettent de gagner du temps et de réduire les coûts.

Les défis

• Synchronisation des données : la synchronisation des données avec la source de vérité nécessite un travail minutieux.
• Complexité pour l'assistance : un nouveau service introduit de nouveaux chemins pour la gestion des tickets. L'assistance traite désormais les cas où les utilisateurs sont bloqués, ce qui modifie les processus.
• Charge du système distribué : la gestion de plusieurs services a introduit une charge opérationnelle qui n'existait pas avec le système monolithique.

Points forts des questions-réponses

Quels outils ont été les plus utiles pour les microservices ?
Le choix de Symfony a été la meilleure décision. Il est léger et modulaire, et nous sommes déjà familiarisés avec PHP. Les bundles nous ont fourni les éléments de base dont nous avions besoin sans nécessiter d'outils personnalisés lourds.

Avez-vous versionné vos points de terminaison API, tels que /v1 et /v2 ?
Nous ne l'avons pas fait jusqu'à présent, mais c'est une bonne idée à envisager.

Comment avez-vous géré la confidentialité ?
Nous évitons de stocker des données personnelles dans KYC lorsque cela n'est pas nécessaire. À la place, nous utilisons des identifiants uniques pour rechercher des informations personnelles dans le service de comptes lorsque cela est nécessaire. Lors de la synchronisation, nous veillons à ne transférer que ce qui est nécessaire.

Partagez-vous du code entre les projets Symfony ?
Pas pour l'instant. Nous avons commencé simplement avec les bundles standard. Le partage de paquets pourrait s'avérer utile plus tard si le besoin s'en fait sentir.

Qu'en est-il du monolithe Drupal ?
Il existe toujours. Nous avançons par étapes. Il n'est pas possible de tout réécrire d'un seul coup. Nous séparons les différentes parties et les réimplémentons de manière plus modulaire. Dans la mesure du possible, nous recherchons des produits existants plutôt que de tout développer à partir de zéro.

Comment avez-vous géré la synchronisation des services externes et la disponibilité ? Le principal défi
consistait à maintenir les données des utilisateurs à jour. Nous avons ajouté une logique de rafraîchissement et veillé à ce que les scores soient calculés dès la création des comptes. Nous utilisons un worker de synchronisation et un chemin asynchrone en arrière-plan, ce qui nous permet de faire face lorsqu'un score n'est pas disponible immédiatement.

Conclusions à retenir

• Commencez petit. Une petite partie avec une propriété claire peut rapidement apporter de la valeur.
• Gardez le point de décision proche du domaine. Si cela correspond à votre architecture, laissez le calcul des scores dans un service et l'application dans un autre.
• Investissez tôt dans les journaux, les identifiants de requête et le traçage. Ils s'avèrent payants dès la première apparition d'un bug interservices.
• Prévoyez la synchronisation. Identifiez votre source de vérité et concevez des chemins de rafraîchissement dès le premier jour.
• Attendez-vous à des changements au niveau du support. Les nouveaux services modifient souvent le flux des tickets.

Les microservices ne sont pas magiques. Ils constituent un moyen d'accélérer le processus lorsque les équipes ont besoin d'autonomie et que certaines parties de votre système évoluent à des rythmes différents. Pour nous, le fait de scinder le KYC en microservice nous a permis de déployer rapidement des fonctionnalités anti-abus, de maintenir notre stack à jour et d'éviter d'alourdir un monolithe que nous prévoyons de retirer.