Styles architecturaux II : systèmes distribués

Bienvenue dans le chapitre 6 : Styles architecturaux, deuxième partie, systèmes distribués. Le chapitre 5 a décrit des styles dans lesquels l’ensemble du système est déployé comme une seule unité. Ce chapitre pose les mêmes questions à travers un réseau. Il explique quand la distribution d’un système vaut son coût, quels sont les principaux styles distribués, et de quels mécanismes ils dépendent tous. Et il se montre précis sur les défaillances, les garanties de livraison et la cohérence.

Presque tous les systèmes d’une certaine taille sont aujourd’hui distribués d’une manière ou d’une autre. Une application mobile dialogue avec des services backend, qui appellent des prestataires de paiement, des services de cartographie et des courtiers de messages, et les services eux-mêmes tournent sur de nombreuses machines. Découper un système peut apporter une mise à l’échelle indépendante, l’isolation des pannes, des mises en production indépendantes et des équipes autonomes. Cela apporte aussi des problèmes qui ne peuvent pas se produire à l’intérieur d’un seul processus : des messages perdus ou dupliqués, des services lents plutôt que morts, des données qui divergent d’une copie à l’autre, et des pannes sur des machines dont vous ignoriez dépendre.

Le chapitre est de niveau intermédiaire à avancé. Il s’adresse aux développeurs et aux architectes qui conçoivent ou évaluent des systèmes composés de nombreux services. Il s’appuie sur les styles du chapitre 5 et les qualités du chapitre 2, désormais soumis aux conditions du réseau. En particulier, il utilise la disponibilité en série et en parallèle, le couplage et la loi de Conway, ainsi que le quantum d’architecture, le monolithe modulaire et les contextes délimités. Et il mène au chapitre 7, qui traite de la partie la plus difficile de la distribution : les données.

L’idée la plus importante du chapitre est que la distribution est un échange, pas une amélioration. Chaque avantage se paie en latence, en cohérence, en observabilité et en effort d’exploitation. Un bon architecte sait dire quel avantage est acheté, à quel prix, et pourquoi une option moins chère à l’intérieur d’un monolithe ne suffit pas.

Le chapitre va du pourquoi au comment. La section six point un expose les raisons de distribuer, les huit illusions de l’informatique distribuée et la défaillance partielle, et vous donne l’arithmétique nécessaire pour évaluer le prix de l’échange avant de vous y engager. La section six point deux traite de l’architecture à base de services, un juste milieu pragmatique composé de quelques services de domaine à gros grain, et de l’architecture orientée services classique, y compris les raisons de sa disgrâce. La section six point trois traite des microservices : des services alignés sur les contextes délimités, le déploiement indépendant, une base de données par service, la manière de décider de la taille d’un service, et le monolithe distribué. La section six point quatre traite de l’architecture pilotée par les événements : événements et commandes, courtiers et médiateurs, garanties de livraison, et consommateurs capables de recevoir sans risque deux fois le même message.

Voici l’arithmétique de la section six point un. Passer une commande traverse cinq services : l’API gateway, puis les commandes, la carte, la tarification et le paiement. Chacun attend la réponse du suivant, et chacun, pris isolément, est disponible quatre-vingt-dix-neuf virgule neuf pour cent du temps. Mais les disponibilités se multiplient. Ensemble, elles donnent un chemin de requête à environ quatre-vingt-dix-neuf virgule cinq pour cent seulement : environ trois virgule six heures d’indisponibilité par mois. Et les latences s’additionnent. Avec vingt millisecondes de travail dans chaque service, plus un peu pour chaque saut réseau, la médiane est d’environ cent dix millisecondes. Cinq services respectables chacun pris isolément ont produit un chemin de requête bien plus faible. Voilà le prix de la distribution, calculé sur le papier avant de construire quoi que ce soit.

Ce diagramme montre la défaillance partielle, le problème qui définit le domaine. Un service des commandes demande à un service de paiement d’autoriser vingt-quatre livres cinquante, et attend la réponse. Trois choses différentes peuvent mal tourner. La requête est perdue, et aucun débit n’a eu lieu. Le service de paiement plante ou se bloque, et personne ne le sait. Ou bien la réponse est perdue, et la carte a été débitée. Pour l’appelant, les trois cas sont identiques : aucune réponse avant l’expiration du délai. Toute opération susceptible d’être retentée doit donc être idempotente, c’est-à-dire que l’effectuer deux fois a le même effet que l’effectuer une fois.

La seconde moitié se tourne vers les mécanismes dont dépend tout style distribué. La section six point cinq compare la communication synchrone et asynchrone et le couplage que crée chacune, et traite de la conception d’API, du versionnage et des tests de contrat. La section six point six porte sur ce que peuvent attendre les lecteurs de données copiées : les modèles de cohérence, ce que dit réellement le théorème CAP, et PACELC. La section six point sept explique pourquoi on évite la validation en deux phases entre services, et comment les sagas, les transactions compensatoires et le patron outbox maintiennent la justesse des processus métier sans elle. La section six point huit conclut avec deux styles adaptés à des profils de charge particuliers : les fonctions serverless, qui descendent à zéro, et l’architecture basée sur l’espace, qui garde les données en mémoire pour survivre à des pics extrêmes, comme l’ouverture d’une billetterie.

Trois habitudes traversent toutes les sections. Premièrement, comptez les dépendances synchrones, pas les services. Le nombre d’éléments qui doivent tous fonctionner au même moment pour qu’une requête aboutisse détermine sa disponibilité et sa latence. Deuxièmement, partez du principe que les messages sont perdus, retardés, dupliqués et réordonnés, et concevez les récepteurs de sorte qu’un message répété ne fasse aucun dégât. Troisièmement, décidez à qui appartient chaque donnée, car la propriété détermine où les transactions sont possibles, et où la cohérence doit être gérée entre services. Le chapitre 7 développe cette habitude en un traitement complet de l’architecture des données.

Si vous découvrez le sujet, lisez d’abord le résumé d’ouverture de chaque section et les encadrés intitulés Si vous débutez. Les ingénieurs expérimentés trouveront de la précision là où elle compte. La lecture du chapitre prend environ trois heures et demie. Deux exemples reviennent. La plateforme de livraison de repas illustre une conception distribuée ordinaire. Un système de billetterie pour une tournée des stades montre ce qui change quand des dizaines de milliers de personnes veulent les mêmes quelques places à la même seconde. Chaque section se termine par quelques questions d’autoévaluation. Répondez-y de tête avant de regarder. Quand vous serez prêt, passez le test facultatif du chapitre : vingt questions à choix multiples et deux réponses rédigées, en quarante-cinq minutes environ. La note de réussite est de quatre-vingts pour cent.

Voilà la carte du chapitre 6. Commencez par la section six point un, où nous mettons en balance les raisons de distribuer et les illusions qui rendent la distribution plus difficile qu’il n’y paraît. À très vite.