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 15. Structures organisationnelles

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

Bien qu'une grande partie du livre se soit concentrée jusqu'à présent sur les défis techniques liés à l'adoption d'une architecture fine, nous avons également examiné l'interaction entre notre architecture de microservices et la façon dont nous organisons nos équipes. Dans "Toward Stream-Aligned Teams", nous avons étudié le concept d'équipes alignées sur les flux, qui sont responsables de bout en bout de la livraison des fonctionnalités orientées vers l'utilisateur, et la façon dont les microservices peuvent contribuer à faire de ces structures d'équipe une réalité.

Nous devons maintenant étoffer ces idées et nous pencher sur d'autres considérations organisationnelles. Comme nous le verrons, si tu veux tirer le meilleur parti des microservices, tu ignores l'organigramme de ton entreprise à tes risques et périls !

Organisations à liens lâches

Tout au long de le livre, j'ai plaidé en faveur d'une architecture faiblement couplée et j'ai fait valoir que l'alignement sur des équipes plus autonomes, faiblement couplées et alignées sur les flux allait probablement donner les meilleurs résultats. Le passage à une architecture de microservices sans changement de structure organisationnelle émoussera l'utilité des microservices - tu pourrais finir par payer le coût (considérable) du changement architectural, sans obtenir ...