Agent Skills
› NeverSight/learn-skills.dev
› microservices-architect
microservices-architect
GitHub专注于微服务架构设计、服务分解、通信模式及分布式系统挑战的专家技能。适用于单体拆分、服务边界定义、服务网格实施及Saga事务处理等场景。
Trigger Scenarios
microservices
service mesh
service decomposition
distributed systems
API gateway
event-driven
Install
npx skills add NeverSight/learn-skills.dev --skill microservices-architect -g -y
SKILL.md
Frontmatter
{
"name": "microservices-architect",
"description": "Distributed systems expert specializing in service decomposition, orchestration, and microservices architecture patterns. Use when designing microservices, defining service boundaries, implementing service mesh, or handling distributed system challenges. Triggers include \"microservices\", \"service mesh\", \"service decomposition\", \"distributed systems\", \"API gateway\", \"event-driven\"."
}
Microservices Architect
Purpose
Provides expertise in designing and implementing microservices architectures. Specializes in service decomposition, inter-service communication patterns, service mesh implementation, and solving distributed systems challenges.
When to Use
- Decomposing monoliths into microservices
- Defining service boundaries and APIs
- Implementing service mesh (Istio, Linkerd)
- Designing API gateway patterns
- Handling distributed transactions (Saga pattern)
- Implementing event-driven communication
- Setting up service discovery and load balancing
- Designing for resilience (circuit breakers, retries)
Quick Start
Invoke this skill when:
- Designing microservices from scratch
- Decomposing existing monoliths
- Implementing service-to-service communication
- Setting up service mesh or API gateway
- Solving distributed system challenges
Do NOT invoke when:
- Migrating legacy systems incrementally → use
/legacy-modernizer - Event streaming architecture → use
/event-driven-architect - Kubernetes operations → use
/kubernetes-specialist - Single service API design → use
/api-designer
Decision Framework
Communication Pattern?
├── Synchronous
│ ├── Simple calls → REST/gRPC
│ └── Complex routing → API Gateway
├── Asynchronous
│ ├── Events → Kafka/RabbitMQ
│ └── Commands → Message queues
└── Distributed Transaction
├── Strong consistency → Saga (orchestration)
└── Eventual consistency → Saga (choreography)
Core Workflows
1. Service Decomposition
- Identify bounded contexts from domain model
- Define service responsibilities (single purpose)
- Design APIs for each service
- Determine data ownership per service
- Plan inter-service communication
- Define deployment strategy
2. Service Mesh Implementation
- Select mesh (Istio, Linkerd, Consul)
- Deploy sidecar proxies
- Configure traffic management
- Implement mTLS for security
- Set up observability (tracing, metrics)
- Define retry and circuit breaker policies
3. Saga Pattern Implementation
- Identify distributed transaction boundaries
- Choose orchestration vs choreography
- Define compensating transactions
- Implement saga coordinator (if orchestrated)
- Handle failure scenarios
- Add monitoring for saga status
Best Practices
- Design services around business capabilities, not technical layers
- Own your data—each service manages its own database
- Use asynchronous communication for loose coupling
- Implement circuit breakers for fault tolerance
- Design for failure—everything will fail eventually
- Use correlation IDs for distributed tracing
Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Distributed monolith | Coupled services, worst of both | True bounded contexts |
| Shared database | Tight coupling | Database per service |
| Synchronous chains | Cascading failures | Async where possible |
| No circuit breakers | Cascading failures | Implement Hystrix/Resilience4j |
| Nano-services | Operational overhead | Right-sized services |
Version History
- e0220ca Current 2026-07-05 21:15
