Fähigkeiten microservices-patterns
📦

microservices-patterns

Sicher

Entwicklung produktionsreifer Microservices-Architekturen

Auch verfügbar von: wshobson

Der Aufbau verteilter Systeme erfordert die Navigation komplexer Abwägungen zwischen Service-Grenzen, Kommunikationsmustern und Datenkonsistenz. Diese Fähigkeit bietet bewährte Muster und Codebeispiele für die Zerlegung von Monolithen, die Implementierung robuster serviceübergreifender Kommunikation und das effektive Management verteilter Transaktionen.

Unterstützt: Claude Codex Code(CC)
🥉 72 Bronze
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "microservices-patterns". Analysieren Sie diesen E-Commerce-Monolithen mit Modulen für Bestellungen, Zahlungen, Inventar, Versand und Benutzerkonten. Schlagen Sie Microservice-Grenzen vor.

Erwartetes Ergebnis:

Basierend auf Domain-Driven-Design-Prinzipien sind hier empfohlene Service-Grenzen: 1) Order Service - besitzt den Bestelllebenszyklus und Bestellstatus; 2) Payment Service - verarbeitet Zahlungsabwicklung und Rückerstattungen; 3) Inventory Service - verwaltet Lagerbestände und Reservierungen; 4) Catalog Service - Produktinformationen und Preisgestaltung; 5) Shipping Service - Erfüllung und Lieferverfolgung. Benutzerkonten sollten Teil eines Identity Service bleiben, der systemweit geteilt wird. Jeder Service sollte seine eigene Datenbank besitzen und Domain-Events für eventual consistency veröffentlichen.

Verwendung von "microservices-patterns". Entwerfen Sie ereignisgesteuerte Kommunikation für die Auftragsabwicklung. Wann sollte ich Events vs. direkte Service-Aufrufe verwenden?

Erwartetes Ergebnis:

Verwenden Sie Events, wenn: 1) Mehrere Services auf dasselbe Ereignis reagieren müssen (OrderCreated löst Inventarreservierung, Versandetikett-Erstellung, Kundenbenachrichtigung aus); 2) Zeitliche Entkopplung akzeptabel ist (Inventar kann Sekunden später reserviert werden); 3) Sie lose Kopplung zwischen Services wünschen. Verwenden Sie direkte synchrone Aufrufe, wenn: 1) Sie eine sofortige Antwort benötigen (Inventarprüfung vor Bestellung); 2) Der Aufrufer ohne die Antwort nicht fortfahren kann; 3) Starke Konsistenz erforderlich ist. Für die Auftragsabwicklung veröffentlichen Sie OrderCreated-Events asynchron für Inventar und Versand, verwenden Sie aber synchrone Aufrufe zur Inventarverfügbarkeitsprüfung während der Bestellplatzierung.

Verwendung von "microservices-patterns". Zeigen Sie mir ein Saga-Muster für Order Payment mit Kompensationslogik.

Erwartetes Ergebnis:

OrderPaymentSaga-Schritte: 1) ReserveOrder - erstellt ausstehende Bestellung; Kompensieren: CancelOrder. 2) ProcessPayment - belastet Kunden; Kompensieren: RefundPayment. 3) ConfirmInventory - reserviert Artikel; Kompensieren: ReleaseInventory. 4) CompleteOrder - markiert Bestellung als bestätigt; Kompensieren: MarkOrderFailed. Ausführung: Wenn Schritt 2 (Zahlung) fehlschlägt, führen Sie kompensierende Aktionen in umgekehrter Reihenfolge aus: ReleaseInventory (Schritt 3 Kompensation), CancelOrder (Schritt 1 Kompensation). Dies stellt sicher, dass das System nach jedem Fehler in einen konsistenten Zustand zurückrollt.

Sicherheitsaudit

Sicher
v1 • 2/25/2026

All 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.

2
Gescannte Dateien
646
Analysierte Zeilen
0
befunde
1
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
32
Community
100
Sicherheit
100
Spezifikationskonformität

Was du bauen kannst

Zerlegung einer monolithischen Anwendung

Softwarearchitekt plant die Aufschlüsselung eines großen Rails-Monolithen in fokussierte Services. Nutzen Sie diese Fähigkeit, um Bounded Contexts zu identifizieren, Service-Grenzen zu definieren und eine Strangler-Fig-Migrationsstrategie zu planen.

Ereignisgesteuerte Kommunikation entwerfen

Backend-Entwickler implementiert asynchrone Nachrichtenübermittlung zwischen Services. Nutzen Sie diese Fähigkeit, um zwischen Kafka, RabbitMQ oder Cloud-native Messaging zu wählen, Event-Schemas zu entwerfen und Event-Handler mit angemessener Fehlerbehandlung zu implementieren.

Resilienz-Muster implementieren

Platform Engineer baut Zuverlässigkeit in die serviceübergreifende Kommunikation ein. Nutzen Sie diese Fähigkeit, um Circuit Breakers anzuwenden, Retry-Logik mit exponentiellem Backoff zu implementieren und Kaskadenausfälle in Ihrem verteilten System zu verhindern.

Probiere diese Prompts

Service-Grenzen identifizieren 
Analysieren Sie diese monolithische Anwendung [Domain und Module beschreiben] und schlagen Sie Microservice-Grenzen vor. Gruppieren Sie zusammengehörige Funktionalitäten nach Geschäftsfähigkeiten und DDD-Subdomains. Erklären Sie die Begründung für jede vorgeschlagene Service-Grenze.
Kommunikationsmuster wählen 
Ich benötige, dass [Service A] mit [Service B] für [spezifischer Use Case] kommuniziert. Vergleichen Sie synchrone REST- vs. asynchrone ereignisgesteuerte Ansätze. Empfehlen Sie das beste Muster unter Berücksichtigung von Latenz, Konsistenzanforderungen und Fehlerbehandlung.
Saga für verteilte Transaktion entwerfen 
Entwerfen Sie eine Saga-Orchestrierung für [Geschäftsprozess mit mehreren Services]. Identifizieren Sie jeden Transaktionsschritt, definieren Sie kompensierende Aktionen für Fehler und zeigen Sie den Ausführungsfluss mit Fehlerbehandlung.
Circuit Breaker-Muster anwenden 
Mein Service ruft [externer Service/Dependency] auf und erlebt intermittierende Fehler. Entwerfen Sie eine Circuit Breaker-Implementierung mit angemessenem Fehlerschwellenwert, Wiederherstellungs-Timeout und Fallback-Verhalten. Zeigen Sie Code in [Ihre bevorzugte Sprache].

Bewährte Verfahren

  • Beginnen Sie mit einem modularen Monolithen und extrahieren Sie Services nur, wenn Sie eine klare Geschäftsgrenze und operativen Bedarf haben
  • Entwerfen Sie Services um Geschäftsfähigkeiten und Bounded Contexts aus Domain-Driven Design, nicht um technische Schichten
  • Bevorzugen Sie asynchrone ereignisgesteuerte Kommunikation gegenüber synchronem REST für lose Kopplung und bessere Resilienz
  • Implementieren Sie Circuit Breakers, Retries mit exponentiellem Backoff und Timeouts für alle serviceübergreifenden Aufrufe
  • Wenden Sie Database-per-Service-Muster an, um Shared-Database-Kopplung zu vermeiden und unabhängige Deployments zu ermöglichen
  • Verwenden Sie verteiltes Tracing und strukturierte Protokollierung, um Anfragen über Service-Grenzen hinweg zu beobachten

Vermeiden

  • Distributed Monolith - Services, die zusammen deployed werden müssen und Datenbanken teilen, was Microservices-Vorteile zunichte macht
  • Gesprächige Services - übermäßige synchrone Aufrufe zwischen Services, die enge Kopplung und Latenz erzeugen
  • Gemeinsame Datenbanken - mehrere Services, die auf dieselbe Datenbank zugreifen, erzeugen Schema-Abhängigkeiten und Deployment-Abhängigkeiten
  • Ignorieren von Fehlermodi - Annahme, dass Netzwerke zuverlässig sind, Services immer verfügbar sind oder Nachrichten garantiert zugestellt werden
  • Vorzeitige Microservices - Start eines neuen Projekts mit Microservices, bevor die Domain und die operative Belastung verstanden werden

Häufig gestellte Fragen

Wann sollte ich Microservices anstelle eines Monolithen verwenden?
Verwenden Sie Microservices, wenn Sie klare Domänengrenzen haben, mehrere Teams unabhängige Deployments benötigen und operative Reife zur Handhabung verteilter Komplexität besitzen. Bleiben Sie bei einem Monolithen für kleine Teams, einfache Domänen oder beim Start eines neuen Produkts.
Wie handle ich Transaktionen über mehrere Services hinweg?
Verwenden Sie das Saga-Muster für verteilte Transaktionen. Jeder Service führt eine lokale Transaktion durch und veröffentlicht ein Event. Wenn ein Schritt fehlschlägt, führen Sie kompensierende Transaktionen in umgekehrter Reihenfolge aus, um zurückzurollen. Akzeptieren Sie eventual consistency anstelle von ACID-Garantien über Services hinweg.
Sollte ich REST oder Messaging für die Service-Kommunikation verwenden?
Verwenden Sie synchrone REST, wenn Sie eine sofortige Antwort und starke Konsistenz benötigen. Verwenden Sie asynchrone Nachrichtenübermittlung (Events), wenn mehrere Services auf Änderungen reagieren müssen und Sie eventual consistency akzeptieren können. Bevorzugen Sie Messaging für lose Kopplung und bessere Resilienz.
Wie verhindere ich Kaskadenausfälle in Microservices?
Implementieren Sie Circuit Breakers, die nach einem Schwellenwert aufhören, fehlschlagende Services aufzurufen, Retry-Logik mit exponentiellem Backoff für vorübergehende Fehler, Anfrage-Timeouts und Bulkhead-Muster zur Isolation von Ressourcenpools. Entwerfen Sie immer für graceful Degradation, wenn Dependencies nicht verfügbar sind.
Was ist der größte Fehler, den Teams mit Microservices machen?
Start mit Microservices ohne Verständnis der Domain oder operative Bereitschaft. Dies erzeugt Distributed Monoliths mit всей Komplexität verteilter Systeme und keinen der Vorteile. Beginnen Sie mit einem gut strukturierten modularen Monolithen und extrahieren Sie Services, wenn Sie klare Grenzen haben.
Wie debugge ich Probleme über mehrere Services hinweg?
Implementieren Sie verteiltes Tracing (OpenTelemetry, Jaeger, Zipkin), um Anfragen über Service-Grenzen hinweg zu verfolgen. Verwenden Sie Korrelations-IDs in allen Logs und Events. Zentralisieren Sie Logs mit strukturierter Protokollierung. Richten Sie angemessene Observability mit Metriken und Dashboards ein, bevor Sie sie benötigen.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/microservices-patterns

Ref

main

Dateistruktur

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md