microservices-patterns
Projetar Arquiteturas de Microsserviços Prontos para Produção
こちらからも入手できます: wshobson
A construção de sistemas distribuídos requer navegar por复杂trade-offs entre limites de serviços, padrões de comunicação e consistência de dados. Esta skill fornece padrões comprovados e exemplos de código para decompor monolitos, implementar comunicação inter-serviços resiliente e gerenciar transações distribuídas de forma eficaz.
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「microservices-patterns」を使用しています。 Analise este monolito de e-commerce com módulos para pedidos, pagamentos, inventário, envio e contas de usuário. Sugira limites de microsserviços.
期待される結果:
Baseado nos princípios de design orientado a domínio, aqui estão os limites de serviço recomendados: 1) Serviço de Pedidos - gerencia ciclo de vida e status do pedido; 2) Serviço de Pagamentos - processa pagamentos e reembolsos; 3) Serviço de Inventário - gerencia níveis de estoque e reservas; 4) Serviço de Catálogo - informações de produtos e preços; 5) Serviço de Envio - fulfillment e rastreamento de entrega. Contas de usuário devem permanecer parte de um Serviço de Identidade compartilhado em todo o sistema. Cada serviço deve possuir seu próprio banco de dados e publicar eventos de domínio para consistência eventual.
「microservices-patterns」を使用しています。 Projete comunicação orientada a eventos para fulfillment de pedidos. Quando devo usar eventos vs chamadas diretas de serviço?
期待される結果:
Use eventos quando: 1) Múltiplos serviços precisam reagir à mesma ocorrência (OrderCreated dispara reserva de inventário, geração de etiqueta de envio, notificação do cliente); 2) Desacoplamento temporal é aceitável (inventário pode ser reservado segundos depois); 3) Você quer acoplamento frouxo entre serviços. Use chamadas síncronas diretas quando: 1) Você precisa de resposta imediata (verificando inventário antes de fazer o pedido); 2) O chamador não pode prosseguir sem a resposta; 3) Consistência forte é necessária. Para fulfillment de pedidos, publique evento OrderCreated assincronamente para inventário e envio, mas use chamada síncrona para verificar disponibilidade de inventário durante o pedido.
「microservices-patterns」を使用しています。 Mostre-me um padrão saga para pagamento de pedidos com lógica de compensação.
期待される結果:
Passos do OrderPaymentSaga: 1) ReserveOrder - cria pedido pendente; Compensate: CancelOrder. 2) ProcessPayment - cobra cliente; Compensate: RefundPayment. 3) ConfirmInventory - reserva itens; Compensate: ReleaseInventory. 4) CompleteOrder - marca pedido confirmado; Compensate: MarkOrderFailed. Execução: Se o passo 2 (pagamento) falhar, execute ações de compensação na ordem reversa: ReleaseInventory (compensação do passo 3), CancelOrder (compensação do passo 1). Isso garante que o sistema reverta para um estado consistente após qualquer falha.
セキュリティ監査
安全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.
品質スコア
作れるもの
Decompor uma Aplicação Monolítica
Arquiteto de software planejando quebrar um grande monolito Rails em serviços focados. Use esta skill para identificar contextos delimitados, definir limites de serviços e planejar uma estratégia de migração strangler fig.
Projetar Comunicação Orientada a Eventos
Engenheiro de backend implementando mensagens assíncronas entre serviços. Use esta skill para escolher entre Kafka, RabbitMQ ou mensagens nativas da nuvem, projetar esquemas de eventos e implementar manipuladores de eventos com tratamento adequado de erros.
Implementar Padrões de Resiliência
Engenheiro de plataforma construindo confiabilidade na comunicação serviço-a-serviço. Use esta skill para aplicar circuit breakers, implementar lógica de retry com backoff exponencial e evitar falhas em cascata no seu sistema distribuído.
これらのプロンプトを試す
Analise esta aplicação monolítica [descreva o domínio e módulos] e sugira limites de microsserviços. Agrupe funcionalidades relacionadas por capacidade de negócio e subdomínios de DDD. Explique o raciocínio para cada limite de serviço proposto.
Preciso que [Serviço A] se comunique com [Serviço B] para [caso de uso específico]. Compare abordagens síncronas REST vs orientadas a eventos assíncronas. Recomende o melhor padrão considerando latência, requisitos de consistência e tratamento de falhas.
Projete uma orquestração saga para [processo de negócio envolvendo múltiplos serviços]. Identifique cada etapa da transação, defina ações de compensação para falhas e mostre o fluxo de execução com tratamento de erros.
Meu serviço chama [serviço dependência/externo] e experimenta falhas intermitentes. Projete uma implementação de circuit breaker com limite de falha apropriado, timeout de recuperação e comportamento de fallback. Mostre código em [sua linguagem preferida].
ベストプラクティス
- Comece com um monólito modular e extraia serviços apenas quando você tiver um limite de negócio claro e necessidade operacional
- Projete serviços em torno de capacidades de negócio e contextos delimitados de design orientado a domínio, não camadas técnicas
- Prefira comunicação assíncrona orientada a eventos sobre REST síncrono para melhor acoplamento e resiliência
- Implemente circuit breakers, retries com backoff exponencial e timeouts para todas as chamadas inter-serviços
- Aplique o padrão banco-de-dados-por-serviço para evitar acoplamento de banco de dados compartilhado e permitir implantações independentes
- Use rastreamento distribuído e日志 estruturado para observar requisições através de limites de serviço
回避
- Monolito distribuído - serviços que devem ser implantados juntos e compartilham bancos de dados, derrotando os benefícios de microsserviços
- Serviços barulhentos - chamadas síncronas excessivas entre serviços que criam acoplamento apertado e latência
- Bancos de dados compartilhados - múltiplos serviços acessando o mesmo banco de dados cria lockstep de schema e dependências de implantação
- Ignorar modos de falha - assumir que redes são confiáveis, serviços estão sempre disponíveis, ou mensagens têm entrega garantida
- Microsserviços prematuros - iniciar um novo projeto com microsserviços antes de entender o domínio e a carga operacional