microservices-patterns
Concevoir des architectures de microservices prêtes pour la production
Également disponible depuis: wshobson
La construction de systèmes distribués nécessite de naviguer dans des compromis complexes entre les limites de services, les modèles de communication et la cohérence des données. Cette compétence fournit des modèles éprouvés et des exemples de code pour décomposer les monolithes, implémenter une communication résiliente entre services et gérer efficacement les transactions distribuées.
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". Analysez ce monolithe e-commerce avec des modules pour les commandes, paiements, inventaire, expédition et comptes utilisateurs. Suggérez des limites de microservices.
Résultat attendu:
Sur la base des principes de domain-driven design, voici les limites de services recommandées : 1) Service Commande - possède le cycle de vie des commandes et le statut des commandes ; 2) Service Paiement - gère le traitement des paiements et les remboursements ; 3) Service Inventaire - gère les niveaux de stock et les réservations ; 4) Service Catalogue - informations produits et tarification ; 5) Service Expédition - fulfillment et suivi de livraison. Les comptes utilisateurs doivent rester dans un Service d'Identité partagé à travers le système. Chaque service doit posséder sa base de données et publier des événements de domaine pour la cohérence éventuelle.
Utilisation de "microservices-patterns". Concevez une communication pilotée par les événements pour le fulfillment de commandes. Quand dois-je utiliser des événements vs des appels directs de services ?
Résultat attendu:
Utilisez des événements quand : 1) Plusieurs services doivent réagir à la même occurrence (OrderCreated déclenche la réservation d'inventaire, la génération d'étiquette d'expédition, la notification client) ; 2) Le découplage temporel est acceptable (l'inventaire peut être réservé quelques secondes plus tard) ; 3) Vous voulez un couplage lâche entre services. Utilisez des appels synchrones directs quand : 1) Vous avez besoin d'une réponse immédiate (vérifier l'inventaire avant de passer une commande) ; 2) L'appelant ne peut pas continuer sans la réponse ; 3) Une cohérence forte est requise. Pour le fulfillment de commandes, publiez l'événement OrderCreated de manière asynchrone pour l'inventaire et l'expédition, mais utilisez un appel synchrone pour vérifier la disponibilité de l'inventaire lors du placement de commande.
Utilisation de "microservices-patterns". Montrez-moi un modèle saga pour le paiement de commande avec logique de compensation.
Résultat attendu:
Étapes OrderPaymentSaga : 1) ReserveOrder - crée une commande en attente ; Compenser : CancelOrder. 2) ProcessPayment - facture le client ; Compenser : RefundPayment. 3) ConfirmInventory - réserve les articles ; Compenser : ReleaseInventory. 4) CompleteOrder - marque la commande confirmée ; Compenser : MarkOrderFailed. Exécution : Si l'étape 2 (paiement) échoue, exécutez les actions de compensation en ordre inverse : ReleaseInventory (compensation étape 3), CancelOrder (compensation étape 1). Cela garantit que le système revient à un état cohérent après toute panne.
Audit de sécurité
SûrAll 29 static analysis findings are false positives from markdown code examples in educational documentation. The skill contains only documentation files (SKILL.md and implementation-playbook.md) with Python code samples demonstrating microservices patterns. No executable code, scripts, or actual security risks present. The 'external_commands' and 'network' patterns detected are from code block delimiters and example URLs in instructional content.
Score de qualité
Ce que vous pouvez construire
Décomposer une application monolithique
Architecte logiciel prévoyant de découper un grand monolithe Rails en services ciblés. Utilisez cette compétence pour identifier les contextes bornés, définir les limites de services et planifier une stratégie de migration strangler fig.
Concevoir une communication pilotée par les événements
Ingénieur backend implémentant une messagerie asynchrone entre services. Utilisez cette compétence pour choisir entre Kafka, RabbitMQ ou la messagerie cloud-native, concevoir des schémas d'événements et implémenter des gestionnaires d'événements avec une gestion d'erreur appropriée.
Implémenter des modèles de résilience
Ingénieur plateforme intégrant la fiabilité dans la communication service-à-service. Utilisez cette compétence pour appliquer des disjoncteurs, implémenter une logique de nouvelle tentative avec backoff exponentiel et prévenir les pannes en cascade dans votre système distribué.
Essayez ces prompts
Analysez cette application monolithique [décrire le domaine et les modules] et suggérez des limites de microservices. Groupez les fonctionnalités connexes par capacité métier et sous-domaines DDD. Expliquez le raisonnement pour chaque limite de service proposée.
J'ai besoin que [Service A] communique avec [Service B] pour [cas d'usage spécifique]. Comparez les approches synchrones REST vs asynchrones pilotées par les événements. Recommandez le meilleur modèle en tenant compte de la latence, des exigences de cohérence et de la gestion des pannes.
Concevez une orchestration saga pour [processus métier impliquant plusieurs services]. Identifiez chaque étape de transaction, définissez les actions de compensation pour les pannes et montrez le flux d'exécution avec la gestion d'erreur.
Mon service appelle [service externe/dépendance] et rencontre des pannes intermittentes. Concevez une implémentation de disjoncteur avec un seuil de panne approprié, un délai de récupération et un comportement de repli. Montrez le code dans [votre langage préféré].
Bonnes pratiques
- Commencez avec un monolithe modulaire et extrayez des services uniquement lorsque vous avez une limite métier claire et un besoin opérationnel
- Concevez les services autour des capacités métier et des contextes bornés du domain-driven design, pas des couches techniques
- Préférez la communication asynchrone pilotée par les événements au REST synchrone pour un couplage lâche et une meilleure résilience
- Implémentez des disjoncteurs, des nouvelles tentatives avec backoff exponentiel et des timeouts pour tous les appels inter-services
- Appliquez le modèle database-per-service pour éviter le couplage par base de données partagée et permettre des déploiements indépendants
- Utilisez le tracing distribué et le logging structuré pour observer les requêtes à travers les limites de services
Éviter
- Monolithe distribué - services qui doivent être déployés ensemble et partagent des bases de données, annulant les avantages des microservices
- Services bavards - appels synchrones excessifs entre services qui créent un couplage serré et de la latence
- Bases de données partagées - plusieurs services accédant à la même base de données créent un verrouillage de schéma et des dépendances de déploiement
- Ignorer les modes de défaillance - supposer que les réseaux sont fiables, que les services sont toujours disponibles ou que les messages sont garantis d'être livrés
- Microservices prématurés - démarrer un nouveau projet avec des microservices avant de comprendre le domaine et la charge opérationnelle