Points clés
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 :
- Identifier les coutures dans la base de code existante
- Extraire les contextes délimités en modules séparés
- Refactoriser les structures de données et les bases de données partagées
- Créer des API pour la communication inter-modules
- Extraire les modules en services séparés
- 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.
Dernière mise à jour:
FAQ
What's Building Microservices by Sam Newman about?
- Microservices Architecture: The book explores microservices, which are small, autonomous services that collaborate to form a system. It highlights how this architecture can enhance software delivery speed and flexibility.
- Business Domain Focus: Microservices are modeled around business domains, aligning software design with business needs and avoiding issues of monolithic architectures.
- Practical Guidance: Sam Newman provides real-world examples from companies like Netflix and Amazon, offering a comprehensive guide for adopting or understanding microservices.
Why should I read Building Microservices by Sam Newman?
- Comprehensive Resource: It covers design, development, deployment, testing, and maintenance of microservices, making it ideal for those transitioning from monolithic systems.
- Real-World Examples: The book includes insights from organizations that have successfully implemented microservices, providing practical perspectives and lessons learned.
- Continuous Learning: It encourages embracing continuous learning to keep up with the fast-evolving nature of microservices technology and practices.
What are the key takeaways of Building Microservices by Sam Newman?
- Microservices Benefits: The book outlines benefits like improved scalability, resilience, and quick adoption of new technologies due to service autonomy.
- Loose Coupling and High Cohesion: Emphasizes designing services to be loosely coupled and highly cohesive, facilitating easier maintenance and updates.
- Integration Strategies: Discusses synchronous and asynchronous communication strategies, crucial for maintaining service autonomy and effective collaboration.
What is the definition of microservices according to Building Microservices by Sam Newman?
- Small, Autonomous Services: Defined as "small, autonomous services that work together," highlighting their independence and functionality without reliance on others.
- Business Functionality Focus: Each microservice handles a specific business capability, aligning with organizational goals and prioritizing work effectively.
- Decoupled Communication: Services communicate through well-defined APIs, maintaining loose coupling and enabling independent development and deployment.
How does Building Microservices by Sam Newman suggest modeling services?
- Bounded Contexts: Introduces bounded contexts from Domain-Driven Design to define service boundaries, with each context representing a specific responsibility.
- Loose Coupling and High Cohesion: Stresses that related functionality should reside within the same service, while unrelated functionality should be separated.
- Iterative Approach: Recommends refining service boundaries over time to accommodate changes in business requirements and technology.
What are the integration strategies discussed in Building Microservices by Sam Newman?
- Synchronous vs. Asynchronous: Contrasts synchronous communication, where a service waits for a response, with asynchronous communication, where services operate independently.
- Event-Driven Architecture: Advocates for event-driven architectures, where services emit events to signal state changes, promoting loose coupling.
- REST and RPC: Discusses RESTful APIs and Remote Procedure Calls for service communication, emphasizing technology-agnostic APIs for flexibility.
What are the challenges of deploying microservices as outlined in Building Microservices by Sam Newman?
- Increased Complexity: Warns of the complexity due to interdependencies between services, which can lead to deployment challenges without proper management.
- Continuous Integration and Delivery: Emphasizes robust CI/CD practices to manage microservices effectively, ensuring quick and reliable deployments.
- Monitoring and Management: Suggests comprehensive monitoring solutions to track the health and performance of each service independently.
How does Building Microservices by Sam Newman address testing in microservices?
- Types of Tests: Categorizes tests into technology-facing and business-facing, including unit, integration, and end-to-end tests for service reliability.
- Consumer-Driven Contracts: Introduces consumer-driven contracts to validate service interactions, ensuring changes in one service don't break dependent services.
- Automated Testing: Advocates for automated testing to maintain quality and speed in deployment, allowing confident release of changes.
What is the significance of Conway’s Law in Building Microservices by Sam Newman?
- Organizational Structure and Architecture: Discusses Conway’s Law, which states that system designs reflect the communication structures of organizations.
- Team Autonomy: Emphasizes organizing microservices around autonomous teams that own specific services, fostering accountability and ownership.
- Impact on Design: Highlights the importance of aligning team structures with service boundaries for effective collaboration and faster feature delivery.
What are the best quotes from Building Microservices by Sam Newman and what do they mean?
- Freedom to React: "Microservices give us significantly more freedom to react and make different decisions," highlighting agility compared to monolithic architectures.
- Service Autonomy: "The golden rule: can you make a change to a service and deploy it by itself without changing anything else?" emphasizes designing independent services.
- Postel's Law: "Be conservative in what you do, be liberal in what you accept from others," underscores flexibility in service interactions while maintaining strict internal standards.
What are some architectural safety measures discussed in Building Microservices by Sam Newman?
- Circuit Breakers: Prevent cascading failures by stopping further calls to a failing service, allowing it to recover without being overwhelmed.
- Bulkheads: Isolate different parts of a system to prevent a failure in one area from affecting others, enhancing resilience and stability.
- Timeouts: Setting appropriate timeouts for service calls to avoid hanging requests, ensuring services can fail fast and recover effectively.
How does Building Microservices by Sam Newman suggest handling service discovery?
- Dynamic Service Registries: Discusses using tools like Consul and Eureka for managing service discovery, allowing easy registration and discovery of services.
- DNS as a Solution: Mentions DNS for service discovery, though it may not suit highly dynamic environments, suggesting load balancers to mitigate limitations.
- Human-Friendly Interfaces: Emphasizes creating user-friendly interfaces for service discovery, aiding developers in finding and understanding available services.
Avis
Building Microservices reçoit des avis mitigés, beaucoup louant son aperçu complet des concepts de microservices et ses conseils pratiques. Les lecteurs apprécient l'approche prudente de l'auteur et les exemples concrets tirés du monde réel. Les critiques soulignent le manque de profondeur sur certains sujets et le potentiel du livre à survendre les microservices. Nombreux sont ceux qui le trouvent précieux pour les débutants mais moins utile pour les architectes expérimentés. Le livre couvre divers aspects des microservices, y compris la conception, le déploiement, les tests et la mise à l'échelle. Certains lecteurs auraient souhaité plus de détails concrets sur la mise en œuvre, tandis que d'autres ont apprécié sa perspective globale sur l'architecture logicielle.
Similar Books
