Dans le paysage cloud-natif moderne, l'architecture sans serveur est apparue comme un paradigme puissant qui permet aux développeurs de construire et de déployer des applications avec une agilité et une rentabilité sans précédent. En abstractionnant la gestion de l'infrastructure, les plateformes sans serveur permettent aux équipes de se concentrer sur l'écriture de logiques d'affaires tandis que le fournisseur de cloud gère l'échelle, la disponibilité et la maintenance des serveurs. Combiné avec les microservices, l'informatique sans serveur crée une base hautement modulaire où chaque service fonctionne indépendamment, s'échelle sur demande et ne supporte des coûts que lorsqu'il est invoqué.

Comprendre les microservices sans serveur

Les microservices sans serveur sont de petites unités autonomes de fonctionnalité qui fonctionnent sur des plateformes de calcul sans serveur telles que AWS Lambda, Azure Functions, Google Cloud Functions ou Cloudflare Workers. Chaque microservice gère une capacité d'affaires spécifique – par exemple, l'authentification des utilisateurs, le traitement des commandes, la validation des paiements ou le réglage des stocks.

Ce qui rend les microservices sans serveur particulièrement attrayant est l'élimination de la gestion des serveurs. Les développeurs n'ont jamais besoin de fournir ou de patcher des machines virtuelles; au lieu de cela, ils chargent le code et définissent les déclencheurs. Le fournisseur de cloud évalue automatiquement le service de zéro à des milliers d'exécutions simultanées basées sur des requêtes ou des événements entrants. Ceci est idéal pour les charges de travail avec un trafic variable, comme les commandes de commerce électronique, l'ingestion de données IoT, ou le traitement de fichiers en temps réel.

Pour atténuer ces problèmes, de nombreuses architectures sans serveur adoptent une communication par événement. Plutôt que d'appeler un autre service directement, un service émet un événement lorsqu'une action importante se produit. D'autres services s'abonnent aux événements pertinents et réagissent en conséquence. Ce modèle n'est pas nouveau – il a été utilisé dans les systèmes d'entreprise depuis des décennies – mais les plateformes sans serveur facilitent la mise en œuvre, le suivi et l'échelle des workflows par événement.

Caractéristiques clés des microservices sans serveur

  • Apatridie:[ Chaque instance de fonction est éphémère et ne devrait pas dépendre de l'état local. L'état est stocké de l'extérieur dans des bases de données, des caches ou des magasins d'objets.
  • Responsabilité unique :[ Chaque microservice effectue une tâche ciblée, ce qui facilite les tests, le débogage et le remplacement.
  • Scalage automatique:[ La plate-forme échafaude les instances de service en haut ou en bas en réponse à la demande, sans intervention manuelle.
  • Pay-per-execution:[ Les coûts sont basés sur le temps d'exécution, l'attribution de mémoire et le nombre d'invocations, et non sur la capacité de ralenti.
  • Déclencheurs pilotés par l'événement:[ Les fonctions peuvent être invoquées par des requêtes HTTP, des modifications de base de données, des files d'attente de messages, des minuteurs ou d'autres événements cloud.

Qu'est-ce que la communication par événement?

La communication par événement est un modèle architectural où les services échangent de l'information en émettant et en consommant des événements. Un événement est un enregistrement d'un changement d'état ou d'une action – par exemple, « utilisateur inscrit », « paiement complété » ou « article expédié ». Le service qui produit l'événement ne sait pas quels services, s'il en existe, le consommeront.

Les événements sont généralement publiés sur une plateforme de messagerie – un intermédiaire ou un bus d'événements – qui gère la livraison aux abonnés. Le courtier peut tamponner les événements, les livrer à plusieurs abonnés, gérer les rétractations et persister les événements pour une rediffusion ultérieure. Les services de courtiers d'événements communs comprennent Amazon Simple Notification Service (SNS) et Simple Queue Service (SQS), Apache Kafka et Google Pub/Sub.

Comment les événements se produisent dans un système sans serveur

Considérez un flux simplifié de traitement des commandes. Lorsqu'un client soumet une commande, une passerelle API reçoit la requête HTTP et déclenche une fonction AWS Lambda. Cette fonction valide l'entrée, écrit l'ordre dans une base de données, puis publie un événement sur un sujet SNS : OrderPlaced. Le sujet SNS diffuse l'événement sur plusieurs files d'attente SQS, chacune abonnée par un microservice différent :

  • Le service d'inventaire[ reçoit le stock d'événements et de décréments.
  • Le Service de paiement traite le paiement et, après avoir réussi, publie un PaiementSuccède événement.
  • Le service d'expédition[ attend les deux OrdrePlacé[ et PaiementSuccédé pour déclencher la préparation du paquet.
  • Le service de notification écoute tous les événements liés à la commande pour envoyer des courriels ou des mises à jour SMS au client.

Comme chaque service fonctionne de façon indépendante et ne s'inscrit qu'à des événements pertinents, le système peut continuer à fonctionner même si un service n'est pas disponible temporairement. Le courtier conserve les messages non livrés, garantissant ainsi une perte de données.

Avantages de l'architecture animée par des événements

  • Découplage: Les producteurs et les consommateurs n'ont aucune dépendance directe. Un service peut être remplacé, mis à jour ou mis à l'échelle sans affecter les autres. Cela réduit le rayon de bouffée des défaillances et simplifie les déploiements.
  • Scalabilité: Les événements sont traités de manière asynchrone. Si le trafic s'accentue, le courtier de messages tamponne les événements entrants, empêchant ainsi la surcharge. Chaque consommateur peut s'élargir indépendamment en fonction de sa propre profondeur de file d'attente.
  • Resilience:[ Une défaillance chez un consommateur ne s'est pas encaissée. Le courtier peut réessayer la livraison ou l'acheminement des messages en attente d'une lettre morte pour une analyse ultérieure.
  • Flexibilité: De nouveaux services peuvent être ajoutés plus tard en s'inscrivant à des événements existants sans modifier le producteur. Cela permet le développement de fonctionnalités supplémentaires et supporte des environnements polyglottes (différents langages de programmation par service).
  • Traçabilité: Les journaux d'événements fournissent un enregistrement chronologique de tous les changements d'état, ce qui est inestimable pour débogage, vérification et rejouer les événements passés pour reconstruire l'état.

Mise en œuvre des microservices Event-Driven

La transition de la théorie à la pratique exige une attention particulière à l'infrastructure, à la conception des services et à l'outillage opérationnel. Les pratiques exemplaires suivantes aident à garantir que les microservices sans serveur, qui sont axés sur les événements, sont robustes, durables et prêts à être produits.

Choisir une plateforme de messagerie

Le choix du courtier d'événements dépend de votre fournisseur de cloud, des exigences de débit, des garanties de commande et des tolérances de latence. Voici une comparaison des options populaires:

  • Amazon SNS + SQS: Idéal pour les applications sans serveur AWS. SNS fournit des messages pub/sous-messagerie avec fan-out à plusieurs files d'attente SQS. SQS offre une file d'attente durable et évolutive avec livraison au moins une fois. Supporte les files d'attente FIFO pour une commande stricte. En savoir plus à Amazon SNS documentation.
  • Apache Kafka / Amazon MSK: Meilleur pour les flux d'événements à haut débit, commandés avec replayability. Kafka conserve les événements pour une période configurable, permettant à plusieurs consommateurs de rejouer l'historique. Convient pour l'approvisionnement d'événements et les pipelines de données. Voir Apache Kafka docs.
  • Google Pub/Sub: Très bien intégré avec les fonctions et les flux de travail de Google Cloud. Fournit une évolutivité globale, une livraison exactement une fois avec des clés de commande optionnelles. Se référer à Google Pub/Sub documentation.
  • Azure Event Grid + Service Bus: Event Grid est pour pub/sous-réactivité à l'échelle; Service Bus offre une file d'attente d'entreprise avec des sessions et des transactions. Idéal pour les architectures Azure-native.

Lors de la sélection d'un courtier, examinez si vous avez besoin de commande de message, exactement une fois vs. au-dessous-une fois sémantique, et l'intégration avec les déclencheurs natifs de vos fonctions sans serveur (par exemple, la cartographie des sources d'événements de Lambda SQS).

Conception de services d'idéoponte

Si un consommateur échoue après avoir traité un événement mais avant d'en accuser réception, le courtier le retransmettra. Pour éviter le double traitement – par exemple, le fait de facturer deux fois un client ou de déprécier deux fois l'inventaire – les services doivent être idéoptents. L'état de santé signifie que le traitement du même événement plusieurs fois produit le même résultat que le traitement une fois.

Les stratégies communes d'aide sociale comprennent :

  • Clés d'idempotency:[ Chaque événement porte un identifiant unique (p. ex., un UUID). Le consommateur stocke les ID traités dans une base de données (avec un TTL pour éviter une croissance non limitée).
  • Utilisation des contraintes de base de données:[ Utiliser des index uniques ou des écritures conditionnelles pour empêcher les duplications. Par exemple, une base de données SQL peut utiliser .
  • Idempotency basé sur l'état:[ Vérifiez l'état actuel avant d'appliquer des changements. Par exemple, un ordre ne peut passer de "Pending" à "Confirmé" une fois. Le service vérifie l'état actuel et rejette les transitions dupliquées.

La mise en œuvre de l'aide-mémoire ajoute un petit montant de frais généraux, mais est essentielle à l'intégrité des données, en particulier dans les transactions financières.

Gestion et récupération des erreurs

Une base de données en aval peut être indisponible, une API tierce peut être momentanément éliminée ou une règle d'affaires erronée peut causer une exception. Des systèmes robustes axés sur les événements prévoient de telles défaillances et la conception pour une récupération gracieuse.

Les principales pratiques sont les suivantes :

  • Les files d'attente à lettres mortes (DLQ):[ Les messages qui ne peuvent pas être traités après un certain nombre de requêtes (p. ex., 3) sont déplacés vers une file d'attente séparée pour une inspection manuelle.
  • Défaut exponentiel avec jitter: Au lieu de reessayer immédiatement, calculez le temps d'attente comme 2^n secondes (n = tentative de réessayer) plus un jeu aléatoire pour éviter les problèmes de troupeau tonnerre.
  • Disjoncteurs: Si un service échoue à plusieurs reprises en appelant une dépendance externe, il devrait cesser d'essayer pendant une période pour permettre à la dépendance de récupérer. Vous pouvez implémenter cela en utilisant une machine d'état ou un service géré comme AWS AppConfig.
  • Rejouer les événements: Gardez les événements dans le courtier pendant une période de rétention suffisante pour que vous puissiez les reproduire après une correction de bug. Pour Kafka, ceci est intégré; pour SQS, vous pourriez avoir besoin de capturer des événements dans un magasin durable comme S3.

Surveillance et exploitation forestière

Avec des centaines ou des milliers de microservices animés par des événements, la surveillance devient essentielle pour détecter les problèmes et optimiser les performances. Chaque service devrait émettre des journaux, des métriques et des traces qui alimentent une plateforme d'observation centralisée.

  • Retraçage distribué:[ Utilisez des outils comme AWS X-Ray, OpenTelemetry ou Datadog pour tracer un événement unique au fur et à mesure qu'il circule sur les services.
  • Mesures de profondeur de la file d'attente:[Surveiller le nombre de messages dans chaque file d'attente. Un retard croissant peut indiquer un consommateur trop lent ou défaillant.
  • Les taux d'erreur et le nombre de DLQ :[ suivent le nombre de messages envoyés aux files d'attentes en lettres mortes.
  • Loging avec des ID de corrélation: Passez un ID de corrélation unique dans chaque événement afin de pouvoir relier des journaux de différents services pour le même flux de requête. Logage structuré (JSON) simplifie la recherche.

Pour une plongée plus profonde dans la surveillance sans serveur, reportez-vous à AWS Lambda documentation de surveillance.

Étude de cas: Plateforme de commerce électronique

Pour illustrer ces concepts, envisagez une plateforme de commerce électronique qui a migré d'une application monolithique vers des microservices sans serveur axés sur des événements. La plateforme gère le catalogue de produits, le panier d'achat, la commande, le paiement, l'inventaire, l'expédition et les notifications.

Avant: Un monolithe a traité chaque étape de manière synchronisée. Lorsqu'un utilisateur a passé une commande, l'application a bloqué jusqu'à ce que l'inventaire soit déprécié, le paiement a été autorisé et des étiquettes d'expédition ont été créées. Si une étape a échoué, la transaction entière a été retournée – ou pire, l'utilisateur a dû faire face à un délai.

Après la migration vers un serveur sans événement:

  • Le service de commande (AWS Lambda) valide l'ordre et publie OrderPlaced événement sur un sujet SNS.
  • Le service de paiement est abonné à une file d'attente dédiée SQS. Il traite le paiement via Stripe ou PayPal. Sur succès, il publie PaiementComplété; sur échec, il publie PaiementÉchec à un sujet distinct.
  • Le service d'inventaire écoute OrderPlaced[. Il réserve temporairement les articles. Si le stock est insuffisant, il publie OutOfStock événement, déclenchant un flux de travail d'annulation.
  • Le service d'expédition souscrit aux deux PaiementComplété et InventoryReserved. Ce n'est que lorsque les deux sont survenus qu'il crée une étiquette d'expédition avec un tiers transporteur.
  • Le Service de notification écoute tous les événements : envoie des courriels de confirmation de commande, un reçu de paiement, des mises à jour d'expédition et des alertes de défaillance.
  • Analytics Service consomme asynchronement des événements pour mettre à jour les tableaux de bord et les modèles d'apprentissage automatique pour les recommandations de produits.

Cette architecture permet à chaque service de échouer indépendamment. Si l'API d'expédition est lente, la file d'attente des demandes tampons; l'expédition est traitée plus tard. Si le paiement échoue, le service de notification informe le client sans bloquer l'inventaire ou l'expédition. La plate-forme peut également introduire de nouveaux services – comme la détection de fraude – en s'inscrivant à des événements existants sans changement de code à d'autres composants.

Amélioration des mesures clés : La plateforme gère 10x trafic augmente pendant les ventes de vacances sans provisionnement. Le temps moyen de traitement des commandes est passé de 15 secondes à moins de 2 secondes (synchrone).

Considérations avancées

Alors que les microservices sans serveur, pilotés par des événements, offrent de nombreux avantages, les architectes doivent aborder plusieurs sujets avancés pour assurer le succès à long terme.

Cohérence des données et Sagas

Les transactions distribuées sur plusieurs services sont difficiles à coordonner sans coordination centralisée. Le modèle de saga est une solution commune : chaque service effectue une transaction locale et publie un événement. Si un service ultérieur échoue, des événements compensatoires sont émis pour annuler des actions antérieures. Par exemple, si le paiement échoue après que l'inventaire a été réservé, un InventoryRelease événement est publié.

Sécurité

Les sujets et files d'attente des événements doivent être sécurisés pour empêcher la publication ou la consommation non autorisée. Utilisez les politiques IAM (AWS), comptes de service (GCP) ou identités gérées (Azure) pour limiter l'accès. Cryptez les événements au repos et en transit. Validez que les événements proviennent de sources fiables; envisagez d'utiliser des signatures numériques ou la validation de schéma d'événements.

Gestion des coûts

Si sans serveur réduit les coûts inactif, les volumes d'événements élevés peuvent conduire à des factures inattendues. Surveiller l'utilisation : chaque invocation de Lambda, message SQS et notification SNS a un coût. Utilisez la concurrence réservée pour limiter l'échelle de fonction en cas de bugs. Activer les balises d'allocation des coûts et définir des budgets avec des alertes.

Version et schéma Evolution

Avec l'évolution des microservices, les schémas d'événements peuvent changer. Utilisez un registre de schémas (par exemple, AWS Glue Schema Registry, Confluent Schema Registry) pour faire respecter la compatibilité entre les producteurs et les consommateurs. Evolve schemas en ajoutant des champs optionnels (compatibilité avant) et en dépréciant les anciens.

Conclusion

En découplant les services par des événements asynchrones, vous réduisez le risque de défaillances en cascade, simplifiez le déploiement et permettent une échelle indépendante. Les meilleures pratiques décrites – choisir la bonne plateforme de messagerie, concevoir des consommateurs idéopontes, mettre en œuvre la gestion des erreurs avec des files d'attentes en lettres mortes et investir dans l'observation – constituent une base solide pour les architectures de production.

L'étude de cas sur le commerce électronique montre comment une application réelle peut tirer parti de ces modèles pour gérer les pics de trafic, améliorer la vitesse du développeur et réduire les coûts opérationnels. En adoptant des microservices sans serveur, commencez petit, mesurez soigneusement et itérer. L'écosystème nuageux fournit des éléments de construction puissants; avec un design réfléchi, vous pouvez les assembler en un système qui grandit avec grâce aux côtés de votre entreprise.

Pour plus de détails, explorez le guide d'architecture AWS-Event-drived et .