microservices-patterns
Concevoir des architectures de microservices avec des patrons éprouvés
La construction de systèmes distribués avec des microservices introduit une complexité dans les limites de services, la communication inter-services et la tolérance aux pannes. Cette compétence fournit des patrons éprouvés pour la décomposition de services, l'architecture pilotée par les événements, la coordination de sagas et l'implémentation de disjoncteurs pour vous aider à construire des systèmes résilients et évolutifs.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "microservices-patterns". Comment dois-je décomposer une plateforme e-commerce en microservices ?
Résultat attendu:
- Pour une plateforme e-commerce, je recommande d'organiser les services autour des capacités métier :
- 1. **Service Commandes** - Gère le cycle de vie des commandes, le panier et l'historique des commandes
- 2. **Service Paiement** - Gère le traitement des paiements, les remboursements et les modes de paiement
- 3. **Service Inventaire** - Suit les stocks de produits, les réservations et les emplacements d'entrepôts
- 4. **Service Catalogue** - Listes de produits, recherche et gestion des catégories
- 5. **Service Utilisateur** - Authentification, profils et préférences
- 6. **Service Livraison** - Suivi de livraison, génération d'étiquettes et intégration transporteurs
- Chaque service possède sa propre base de données et communique via des API ou des événements bien définis. Le Service Commandes publie des événements OrderCreated que les services Paiement et Inventaire consomment pour traiter leurs opérations respectives de manière asynchrone.
Utilisation de "microservices-patterns". Comment gérer un échec de paiement dans ma saga de traitement de commandes ?
Résultat attendu:
- Quand l'étape de paiement échoue dans l'OrderFulfillmentSaga, l'orchestrateur de saga déclenche des actions compensatoires dans l'ordre inverse :
- 1. Paiement échoué - aucune compensation nécessaire pour le paiement
- 2. Compenser l'inventaire : Libérer la réservation en appelant InventoryService.release(reservation_id)
- 3. Compenser la commande : Annuler la commande en appelant OrderService.cancel(order_id)
- 4. Renvoyer un résultat échoué avec les détails de l'erreur au client
- La clé est de concevoir chaque action compensatoire pour être idempotente et de gérer les cas où la compensation elle-même pourrait partiellement échouer. Journaliser toutes les actions compensatoires et alerter les opérateurs pour une intervention manuelle si nécessaire.
Utilisation de "microservices-patterns". Pourquoi mon disjoncteur s'ouvre-t-il immédiatement et comment dois-je le configurer ?
Résultat attendu:
- Un disjoncteur s'ouvre lorsque les échecs dépassent le failure_threshold dans une fenêtre glissante. Causes courantes et solutions :
- **S'il s'ouvre trop facilement :**
- - Augmenter le failure_threshold (essayer 10 au lieu de 5)
- - Augmenter le recovery_timeout (essayer 60 secondes au lieu de 30)
- - Ajouter un success_threshold pour exiger plusieurs succès avant la fermeture
- **S'il reste ouvert trop longtemps :**
- - Diminuer le recovery_timeout pour des tests plus rapides
- - Utiliser des seuils adaptatifs basés sur le volume de trafic
- **Bonnes pratiques :**
- - Définir le failure_threshold basé sur le taux d'erreur normal de votre service
- - Définir le recovery_timeout plus long que la durée typique de votre panne
- - Surveiller les changements d'état du disjoncteur pour ajuster les paramètres
Audit de sécurité
SûrStatic analysis detected 36 patterns across 2 files. All findings evaluated as false positives or safe educational content. The 18 weak crypto alerts match on words like design and description in documentation. The 11 external command alerts are markdown code fences for syntax highlighting. Network patterns are legitimate example URLs for teaching microservices communication. No actual security risks identified.
Facteurs de risque
🌐 Accès réseau (7)
Score de qualité
Ce que vous pouvez construire
Migrer un monolite vers les microservices
Appliquer le patron Strangler Fig pour extraire progressivement les fonctionnalités d'un monolite existant vers des services déployables de manière indépendante tout en maintenant la stabilité du système.
Construire un traitement de commandes piloté par les événements
Concevoir un système de gestion des commandes où les services Commande, Paiement et Inventaire communiquent de manière asynchrone via des événements Kafka avec une compensation basée sur les sagas pour les transactions échouées.
Ajouter de la résilience aux appels de services
Implémenter des disjoncteurs et des nouvelles tentatives avec exponential backoff pour protéger les services des pannes en cascade et améliorer la fiabilité globale du système lors de pannes partielles.
Essayez ces prompts
Aidez-moi à décomposer mon application {application_type} en microservices. L'application a ces fonctions principales : {list_functions}. Comment dois-je définir les limites de services et quelle stratégie de décomposition dois-je utiliser ?Concevez un patron de passerelle API pour mon architecture de microservices. J'ai ces services : {list_services}. Comment la passerelle devrait-elle gérer l'authentification, la limitation de débit et l'agrégation de requêtes ?Aidez-moi à implémenter un patron saga pour un {business_process} qui implique ces étapes : {list_steps}. Quelles actions compensatoires dois-je définir pour chaque étape et comment dois-je gérer les échecs partiels ?J'ai un service {service_name} qui connaît occasionnellement des pics de latence. Comment dois-je configurer les paramètres du disjoncteur (failure_threshold, recovery_timeout, success_threshold) et l'intégrer avec mon client HTTP existant ?Bonnes pratiques
- Définir des limites de services claires alignées sur les capacités métier plutôt que sur les couches techniques pour garantir un couplage lâche et une cohésion élevée
- Utiliser une communication asynchrone pilotée par les événements pour les opérations qui peuvent tolérer une cohérence éventuelle afin d'améliorer la résilience du système et de réduire les dépendances bloquantes
- Toujours implémenter des disjoncteurs sur les appels inter-services et configurer des timeouts plus courts que le budget de timeout imposé par le client
Éviter
- Monolithe distribué - Créer des microservices qui sont fortement couplés via des bases de données partagées ou des chaînes synchrones de dépendances, perdant les bénéfices du déploiement indépendant
- Services bavards - Concevoir des services qui nécessitent des dizaines d'appels aller-retour pour compléter une seule requête utilisateur, augmentant les points de latence et de défaillance
- Tout synchrone - Utiliser une communication requête-réponse pour toute la communication inter-services, créant un couplage fort et empêchant la mise à l'échelle indépendante et l'isolation des pannes