Building Microservices

1. Microservices : Petits services autonomes qui travaillent ensemble

Les microservices sont de petits services autonomes qui travaillent ensemble.

Fondation des microservices. L'architecture des microservices repose sur le principe de développer des logiciels sous forme d'une suite de petits services indépendants. Chaque service se concentre sur une tâche spécifique, fonctionne dans son propre processus et communique via des mécanismes légers comme les API HTTP/REST. Cette approche permet une plus grande flexibilité, évolutivité et maintenabilité par rapport aux architectures monolithiques.

Avantages et défis. Les principaux avantages des microservices incluent :

• Amélioration de la modularité
• Évolutivité plus facile des composants individuels
• Diversité technologique
• Meilleure isolation des pannes
• Cycles de déploiement plus rapides

Cependant, les microservices introduisent également des défis tels que :

• Complexité opérationnelle accrue
• Problèmes de systèmes distribués (par exemple, latence réseau, tolérance aux pannes)
• Cohérence des données entre les services

2. Architecture évolutive : S'adapter aux exigences changeantes

Le rôle de l'architecte est de voir la situation dans son ensemble et de comprendre cet équilibre.

Adopter le changement. L'architecture évolutive met l'accent sur la nécessité pour les systèmes de s'adapter aux exigences changeantes au fil du temps. Cette approche reconnaît qu'il est impossible de prévoir tous les besoins futurs, et se concentre donc sur la création d'une base flexible qui peut évoluer.

Principes clés :

• Changement incrémental : Faire de petites mises à jour fréquentes plutôt que de grandes mises à jour rares
• Changement guidé : Utiliser des principes et des pratiques pour guider les décisions architecturales
• Architectures multiples : Reconnaître que différentes parties du système peuvent évoluer à des rythmes différents

Les architectes dans ce modèle agissent davantage comme des urbanistes, établissant des lignes directrices et des contraintes, plutôt que de dicter chaque détail. Cela permet aux équipes de prendre des décisions locales tout en assurant la cohésion globale du système.

3. Modélisation des services : Définir les limites et les contextes

Nous concentrons les limites de nos services sur les limites commerciales, rendant évident l'emplacement du code pour une fonctionnalité donnée.

Conception pilotée par le domaine. Modéliser efficacement les services nécessite une compréhension approfondie du domaine commercial. La conception pilotée par le domaine (DDD) fournit des concepts précieux pour définir les limites des services :

• Contextes délimités : Zones du domaine avec des limites claires
• Langage ubiquitaire : Un langage commun partagé par les développeurs et les experts du domaine
• Agrégats : Groupes d'objets de domaine traités comme une unité

Identifier les limites des services :

• S'aligner sur les capacités commerciales
• Encapsuler les données et les comportements
• Minimiser les dépendances entre les services
• Considérer la structure de l'équipe et les schémas de communication

Des limites bien définies conduisent à des services plus cohérents et à un couplage plus lâche entre eux, facilitant le développement et le déploiement indépendants.

4. Stratégies d'intégration : Choisir la bonne approche pour la communication

Soyez conservateur dans ce que vous faites, soyez libéral dans ce que vous acceptez des autres.

Importance de l'intégration. Une intégration efficace est cruciale pour que les microservices fonctionnent ensemble de manière transparente. Le choix de la technologie d'intégration a un impact significatif sur la flexibilité, les performances et la maintenabilité du système.

Principaux modèles d'intégration :

• Communication synchrone : REST, gRPC
• Communication asynchrone : Files de messages, diffusion d'événements
• Passerelles API : Pour le routage et la composition des requêtes
• Maillage de services : Pour gérer la communication entre services

Meilleures pratiques :

• Utiliser des protocoles indépendants de la technologie (par exemple, HTTP)
• Mettre en œuvre des lecteurs tolérants pour gérer les changements avec grâce
• Concevoir pour l'échec avec des disjoncteurs et des cloisons
• Envisager des architectures pilotées par les événements pour un couplage lâche

La bonne stratégie d'intégration dépend de votre cas d'utilisation spécifique, des exigences de performance et de l'expertise de l'équipe.

5. Fractionner le monolithe : Transition vers les microservices

Pensez à notre monolithe comme à un bloc de marbre. Nous pourrions tout faire exploser, mais cela se termine rarement bien. Il est beaucoup plus logique de le tailler progressivement.

Approche incrémentale. La transition d'une architecture monolithique vers des microservices se fait mieux progressivement. Cela permet aux équipes d'apprendre et de s'adapter tout en minimisant les risques.

Étapes pour fractionner un monolithe :

1. Identifier les coutures dans la base de code existante
2. Extraire les contextes délimités en modules séparés
3. Refactoriser les structures de données et les bases de données partagées
4. Créer des API pour la communication inter-modules
5. Extraire les modules en services séparés
6. Implémenter de nouvelles fonctionnalités sous forme de microservices

Défis à considérer :

• Dépendances de données entre les services
• Intégrité transactionnelle à travers les limites des services
• Impact des performances de la communication réseau
• Complexité opérationnelle de la gestion de multiples services

Commencez par les extractions les plus faciles et les moins risquées pour acquérir de la confiance et de l'expérience avant de s'attaquer aux parties plus complexes du système.

6. Techniques de déploiement : Assurer la fiabilité et l'évolutivité

Si faire quelque chose est juste mais difficile, nous devrions nous efforcer de rendre les choses plus faciles.

Déploiement automatisé. Un déploiement fiable et évolutif est crucial pour le succès des microservices. Les pratiques d'intégration continue et de livraison continue (CI/CD) sont essentielles pour gérer la complexité accrue des déploiements.

Principales techniques de déploiement :

• Infrastructure en tant que code (IaC)
• Conteneurisation (par exemple, Docker)
• Plateformes d'orchestration (par exemple, Kubernetes)
• Déploiements blue-green
• Releases canary

Considérations de déploiement :

• Découverte de services et gestion de la configuration
• Surveillance et journalisation
• Sécurité et contrôle d'accès
• Migrations de bases de données et cohérence des données

Investissez dans les outils et l'automatisation pour rendre les déploiements plus faciles, plus rapides et plus fiables. Cela permet aux équipes de déployer fréquemment en toute confiance, réalisant ainsi tous les avantages de l'architecture des microservices.

7. Tester les microservices : Maintenir la qualité dans un système distribué

Plus il y a de pièces mobiles, plus nos tests peuvent être fragiles et moins ils sont déterministes.

Stratégie de test complète. Tester les microservices nécessite une approche multi-couches pour garantir à la fois la qualité des services individuels et le comportement global du système.

Pyramide de test pour les microservices :

• Tests unitaires : Tests rapides et ciblés pour les composants individuels
• Tests d'intégration : Vérifier les interactions entre les services
• Tests de contrat : Assurer que les services respectent les interfaces convenues
• Tests de bout en bout : Valider le comportement de l'ensemble du système

Défis de test :

• Complexité accrue due à la nature distribuée
• Gestion des données de test entre les services
• Simulation d'environnements proches de la production
• Gestion des interactions asynchrones

Mettez l'accent sur des boucles de rétroaction rapides avec des tests unitaires et d'intégration, tout en utilisant moins de tests de bout en bout, soigneusement choisis, pour valider les chemins critiques. Envisagez d'utiliser des contrats pilotés par les consommateurs pour gérer efficacement les dépendances des services.

8. Surveillance et sécurité : Maintenir les microservices en bonne santé et protégés

Une bonne journalisation, et spécifiquement la capacité d'agréger les journaux de plusieurs systèmes, ne concerne pas la prévention, mais peut aider à détecter et à récupérer des incidents.

Approche holistique. Une surveillance et une sécurité efficaces sont cruciales pour maintenir un écosystème de microservices en bonne santé. Ces aspects deviennent plus complexes et importants dans les systèmes distribués.

Meilleures pratiques de surveillance :

• Journalisation centralisée et agrégation des journaux
• Traçage distribué (par exemple, en utilisant des identifiants de corrélation)
• Alertes en temps réel et tableaux de bord
• Surveillance des performances des applications (APM)
• Surveillance synthétique pour les chemins critiques

Considérations de sécurité :

• Authentification et autorisation entre services
• Passerelles API pour la sécurité des bords
• Gestion des secrets
• Segmentation du réseau
• Audits de sécurité réguliers et tests de pénétration

Mettez en œuvre une stratégie de défense en profondeur, sécurisant à la fois le périmètre et les services individuels. Utilisez l'automatisation pour assurer l'application cohérente des politiques de sécurité à tous les services.

9. Loi de Conway : Aligner l'organisation et la conception du système

La loi de Conway souligne les dangers de tenter d'imposer une conception de système qui ne correspond pas à l'organisation.

Impact organisationnel. La loi de Conway stipule que la conception du système reflète les structures de communication au sein d'une organisation. Ce principe a des implications significatives pour l'architecture des microservices.

Aligner les équipes et les services :

• Organiser les équipes autour des capacités commerciales
• Donner aux équipes la responsabilité de bout en bout des services
• Minimiser les dépendances entre les équipes
• Favoriser une culture de collaboration et de responsabilité partagée

Considérations :

• Taille et composition des équipes
• Schémas de communication et outils
• Processus de prise de décision
• Développement des compétences et partage des connaissances

Reconnaissez que la structure organisationnelle et l'architecture du système sont interdépendantes. Faites évoluer les deux en tandem pour créer un environnement propice au développement et à l'exploitation réussis des microservices.

10. Évoluer les microservices : Gérer la croissance et les pannes

À grande échelle, même si vous achetez le meilleur équipement, le matériel le plus cher, vous ne pouvez pas éviter le fait que les choses peuvent et vont échouer.

Concevoir pour l'échelle et la résilience. Les architectures de microservices doivent être conçues pour gérer à la fois la croissance de la demande et les pannes inévitables de manière gracieuse.

Stratégies d'évolutivité :

• Évolutivité horizontale (ajout de plus d'instances)
• Évolutivité verticale (augmentation des ressources par instance)
• Mise en cache (en mémoire, distribuée)
• Partitionnement et réplication des bases de données
• Traitement asynchrone et architectures pilotées par les événements

Modèles de résilience :

• Disjoncteurs pour prévenir les pannes en cascade
• Cloisons pour l'isolation des pannes
• Timeouts et nouvelles tentatives avec backoff exponentiel
• Dégradation gracieuse des fonctionnalités

Considérations du théorème CAP :

• Cohérence
• Disponibilité
• Tolérance aux partitions

Comprenez que des compromis sont nécessaires lors de l'évolutivité des systèmes distribués. Priorisez en fonction de vos exigences et contraintes spécifiques. Mettez en œuvre des pratiques d'observabilité et d'ingénierie du chaos pour améliorer continuellement la résilience du système.

Last updated: July 26, 2024