book

Construire des microservices, 2e édition

by Sam Newman

November 2024

Intermediate to advanced

616 pages

21h 44m

French

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Qui devrait lire ce livre ?Pourquoi j'ai écrit ce livreQu'est-ce qui a changé depuis la première édition ?Naviguer dans ce livrePremière partie, "Fondation"Partie II, "Mise en oeuvre"Partie III, "Les gens"Conventions utilisées dans ce livreApprentissage en ligne O'ReillyComment nous contacterRemerciements
Les microservices en un coup d'œilConcepts clés des microservicesDéploiement indépendantModelé autour d'un domaine d'activitéPosséder son propre ÉtatTailleFlexibilitéAlignement de l'architecture et de l'organisationLe monolitheLe monolithe à processus uniqueLe monolithe modulaireLe monolithe distribuéMonolithes et contestation de livraisonAvantages des monolithesTechnologie habilitanteAgrégation de journaux et traçage distribuéConteneurs et KubernetesStreamingCloud public et Serverless (sans serveur)Avantages des microservicesHétérogénéité technologiqueRobustesseMise à l'échelleFacilité de déploiementAlignement organisationnelComposabilitéLes points douloureux des microservicesExpérience des développeursSurcharge technologiqueCoûtRapportsSurveillance et dépannageSécuritéTestTemps de latenceCohérence des donnéesDois-je utiliser des microservices ?Pour qui ils pourraient ne pas travaillerLà où ils fonctionnent bienRésumé
Présentation de MusicCorpQu'est-ce qui fait une bonne frontière de microservice ?Dissimulation d'informationsCohésionAccouplementL'interaction du couplage et de la cohésionTypes d'accouplementsCouplage de domainesCouplage de passageCouplage communCouplage de contenuJuste assez de conception pilotée par les domainesLangage omniprésentAgrégatContexte limitéMapper les agrégats et les contextes délimités aux microservicesEvent Storming (tempête d'événements)Arguments en faveur d'une conception pilotée par le domaine pour les microservicesAlternatives aux limites des domaines d'activitéVolatilitéDonnéesTechnologieOrganisationnelMélange de modèles et d'exceptionsRésumé
Aie un objectifMigration incrémentielleLe monolithe est rarement l'ennemiLes dangers de la décomposition prématuréeQue diviser en premier ?Décomposition par coucheLe code d'abordLes données d'abordModèles de décomposition utilesModèle de figue étrangleuseCourse parallèleFonction TogglePréoccupations liées à la décomposition des donnéesPerformanceIntégrité des donnéesTransactionsOutillageBase de données des rapportsRésumé
Du processus en cours à l'interprocessusPerformanceChanger d'interfaceTraitement des erreursTechnologie pour la communication inter-processus : De nombreux choixStyles de communication des microservicesMélanger et assortirModèle : Blocage synchroneAvantagesInconvénientsOù l'utiliserModèle : Asynchrone non bloquantAvantagesInconvénientsOù l'utiliserModèle : Communication par le biais de données communesMise en œuvreAvantagesInconvénientsOù l'utiliserModèle : Communication demande-réponseMise en œuvre : Synchrone ou asynchroneOù l'utiliserModèle : Communication pilotée par les événementsMise en œuvreQu'est-ce qu'un événement ?Où l'utiliserProcède avec prudenceRésumé
À la recherche de la technologie idéaleFacilite la rétrocompatibilitéRends ton interface expliciteFais en sorte que tes API ne soient pas dépendantes de la technologieRends ton service simple pour les consommateursCacher les détails de la mise en œuvre interneChoix technologiquesAppels de procédure à distanceRESTGraphQLCourtiers en messagesFormats de sérialisationFormats textuelsFormats binairesSchémasRuptures de contrat structurelles ou sémantiquesDevrais-tu utiliser des schémas ?Gérer les changements entre les microservicesÉviter les rupturesChangements dans l'expansionLecteur tolérantLa bonne technologieInterface expliciteSaisis à temps les changements de rupture accidentelsGérer les rupturesDéploiement par étapesFaire coexister des versions de microservices incompatibles.Emuler l'ancienne interfaceQuelle approche dois-je privilégier ?Le contrat socialSuivi de l'utilisationMesures extrêmesDRY et les périls de la réutilisation du code dans un monde de microservices.Partager le code via les bibliothèquesDécouverte des servicesSystème de noms de domaine (DNS)Registres de services dynamiquesN'oublie pas les humains !Maille de services et passerelles APIPasserelles APIMaille de serviceQu'en est-il des autres protocoles ?Services de documentationSchémas explicitesLe système d'auto-descriptionRésumé
Transactions de la base de donnéesTransactions ACIDToujours ACID, mais sans atomicité ?Transactions distribuées - Commandes en deux phasesTransactions distribuées - Dis simplement nonSagasModes de défaillance de SagaMise en œuvre des sagasSagas et transactions distribuéesRésumé
Une brève introduction à l'intégration continueFais-tu vraiment de l'IC ?Modèles de branchementPipelines de construction et livraison continueOutillageCompromis et environnementsCréation d'artefactsCartographier le code source et les Builds vers les microservices.Un Repo géant, une construction géanteModèle : Un dépôt par microservice (aka Multirepo)Modèle : MonorepoQuelle approche devrais-je utiliser ?Résumé

De la logique à la physiqueInstances multiplesLa base de donnéesEnvironnementsPrincipes du déploiement des microservicesExécution isoléeL'automatisation en point de mireL'infrastructure en tant que code (IAC)Déploiement sans temps d'arrêtGestion de l'état désiréOptions de déploiementMachines physiquesMachines virtuellesConteneursConteneurs d'applicationPlate-forme en tant que service (PaaS)Fonction en tant que service (FaaS)Quelle est l'option de déploiement qui te convient le mieux ?Kubernetes et l'orchestration des conteneurs.Arguments en faveur de l'orchestration des conteneursUne vue simplifiée des concepts de KubernetesMultitenancy et FédérationLa fédération de l'informatique native dans le cloud.Plateformes et portabilitéBarre, opérateurs et CRDs, Oh My !Et KnativeL'avenirDevrais-tu l'utiliser ?Livraison progressiveSéparer le déploiement de la mise en circulationEn route vers la livraison progressiveBascules de fonctionsLibération des canarisCourse parallèleRésumé
Types de testsPortée du testTests unitairesTests de serviceTests de bout en boutCompromisMise en œuvre des tests de serviceSe moquer ou s'acharnerUn service de talons plus intelligentMise en œuvre des tests de bout en bout (les plus délicats)Tests fragiles et fragilisésQui rédige ces tests de bout en bout ?Combien de temps doivent durer les tests de bout en bout ?Le grand empilementLa métaversionManque de testabilité indépendanteFaut-il éviter les tests de bout en bout ?Tests de contrats et contrats axés sur le consommateur (CDC)Le mot de la finExpérience des développeursDe la préproduction aux tests de productionTypes de tests en productionSécuriser les tests en productionLe temps moyen de réparation est-il supérieur au temps moyen entre les défaillances ?Tests interfonctionnelsTests de performanceTests de robustesseRésumé
Perturbation, panique et confusionUn seul microservice, un seul serveurUn seul microservice, plusieurs serveursServices multiples, serveurs multiplesObservabilité et surveillanceLes piliers de l'observabilité ? Pas si viteLes éléments de base de l'observabilitéAgrégation de journauxAgrégation des mesuresTraçage distribuéEst-ce que nous nous en sortons bien ?AlerteSuivi sémantiqueTest en productionLa normalisationSélection des outilsDémocratiqueFacile à intégrerFournir un contexteEn temps réelAdapté à ton échelleL'expert dans la machinePour commencerRésumé
Principes fondamentauxPrincipe du moindre privilègeDéfense en profondeurAutomatisationIntégrer la sécurité dans le processus de livraisonLes cinq fonctions de la cybersécuritéIdentifierProtégerDétecterRépondsRécupérerFondements de la sécurité des applicationsRéférencesPatchingSauvegardesReconstruireConfiance implicite contre confiance zéroConfiance impliciteZéro confianceC'est un spectreSécuriser les donnéesDonnées en transitDonnées au reposAuthentification et autorisationAuthentification de service à serviceAuthentification humaineImplémentations courantes de l'authentification uniquePasserelle d'authentification uniqueAutorisation à grain finLe problème du député confusAutorisation centralisée, en amontDécentraliser l'autorisationJetons Web JSONRésumé
Qu'est-ce que la résilience ?RobustesseRebondirExtensibilité gracieuseAdaptabilité durableEt l'architecture microserviceL'échec est partoutCombien c'est trop ?Fonctionnalité dégradéeModèles de stabilitéTemps mortsTentativesCloisonsDisjoncteursL'isolementRedondanceLogiciels intermédiairesIdempotenceRépartir les risquesThéorème CAPSacrifier la cohérenceSacrifier la disponibilitéSacrifier la tolérance de partition ?AP ou CP ?Ce n'est pas tout ou rienEt le monde réelIngénierie du chaosJours de matchExpériences de productionDe la robustesse à l'au-delàBlâmeRésumé
Les quatre axes de la mise à l'échelleÉchelle verticaleDuplication horizontalePartitionnement des donnéesDécomposition fonctionnelleCombiner les modèlesCommence petitMise en cachePour la performancePour l'échellePour la robustesseOù mettre en cacheInvalidationLa règle d'or de la mise en cacheFraîcheur contre optimisationEmpoisonnement de la cache : Un récit édifiantMise à l'échelle automatiqueRecommencer à zéroRésumé
Vers le numériqueModèles de propriétéConducteurs d'équipes frontales dédiéesVers des équipes alignées sur les cours d'eauSpécialistes du partageAssurer la cohérenceRelever les défis techniquesModèle : Frontend monolithiqueQuand l'utiliser ?Modèle : Micro FrontendsMise en œuvreQuand l'utiliser ?Modèle : Décomposition par pageOù l'utiliserModèle : Décomposition basée sur les widgetsMise en œuvreQuand l'utiliser ?ContraintesModèle : Passerelle d'agrégation centralePropriétéDifférents types d'interfaces utilisateurDes préoccupations multiplesQuand l'utiliser ?Modèle : Backend pour Frontend (BFF)Combien de BFF ?Réutilisation et BFFsBFFs pour le Web de bureau et au-delàQuand utiliserGraphQLUne approche hybrideRésumé
Organisations à liens lâchesLoi de ConwayPreuvesTaille de l'équipeComprendre la loi de ConwayPetites équipes, grandes organisationsSur l'autonomiePropriété forte ou propriété collectiveUne propriété fortePropriété collectiveAu niveau de l'équipe par rapport au niveau de l'organisationModèles d'équilibrePermettre aux équipes de travaillerCommunautés de pratiqueLa plateformeMicroservices partagésTrop difficile à diviserChangements transversauxGoulots d'étranglement de la livraisonSource ouverte interneRôle des membres du comité de rédactionMaturitéOutillageMicroservices enfichables et modulairesChangez les avisLe service des orphelinsÉtude de cas : realestate.com.auRépartition géographiqueLa loi de Conway à l'enversLes gensRésumé
Qu'est-ce qu'un nom ?Qu'est-ce que l'architecture logicielle ?Rendre le changement possibleUne vision évolutive pour l'architecteDéfinir les limites du systèmeUne construction socialeHabitabilitéUne approche fondée sur des principesObjectifs stratégiquesPrincipesPratiquesCombiner les principes et les pratiquesUn exemple concretGuider une architecture évolutiveL'architecture dans une organisation alignée sur les cours d'eauConstituer une équipeLa norme requiseSurveillanceInterfacesSécurité architecturaleLa gouvernance et la route pavéeExemplairesModèle de microservice sur mesureLa route pavée à l'échelleDette techniqueTraitement des exceptionsRésumé
Qu'est-ce que les microservices ?Passer aux microservicesStyles de communicationFlux de travailConstruireDéploiementTestSurveillance et observabilitéSécuritéLa résilienceMise à l'échelleInterfaces utilisateurOrganisationL'architecturePour en savoir plusRegarder vers l'avenirDernières paroles

Content preview from Construire des microservices, 2e édition

Chapitre 5. Mise en œuvre de la communication entre microservices

Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : translation-feedback@oreilly.com

Comme nous l'avons vu dans le chapitre précédent, ton choix de technologie doit être guidé en grande partie par le style de communication que tu souhaites. Décider entre des appels synchrones bloquants ou asynchrones non bloquants, une collaboration de type demande-réponse ou événementielle, t'aidera à réduire ce qui pourrait autrement être une très longue liste de technologies. Dans ce chapitre, nous allons nous pencher sur certaines des technologies couramment utilisées pour la communication entre microservices.

À la recherche de la technologie idéale

Il y a un éventail déconcertant d'options pour la façon dont un microservice peut parler à un autre. Mais quelle est la bonne option - SOAP ? XML-RPC ? REST ? gRPC ? Et de nouvelles options sont toujours en train de voir le jour. Ainsi, avant de discuter d'une technologie spécifique, réfléchissons à ce que nous attendons de la technologie que nous choisissons.

Facilite la rétrocompatibilité

Lorsque apporte des modifications à nos microservices, nous devons nous assurer de ne pas rompre la compatibilité avec les microservices consommateurs. C'est pourquoi nous voulons nous assurer que la technologie que nous choisissons permet d'effectuer facilement des changements rétrocompatibles. Des opérations simples telles que l'ajout de nouveaux ...