Initial commit

2025-11-30 09:05:07 +08:00
commit 160c5a21b3
20 changed files with 4953 additions and 0 deletions
--- a/skills/references/microservices.md
+++ b/skills/references/microservices.md
@@ -0,0 +1,355 @@
+# Microservices Architecture Patterns
+
+## Table of Contents
+- Core Principles
+- Service Design Patterns
+- Communication Patterns
+- Data Management
+- Deployment Patterns
+- Observability
+
+## Core Principles
+
+### Single Responsibility
+Each service owns one business capability and does it well.
+
+### Decentralized Data
+Each service has its own database (database-per-service pattern).
+
+### Independence
+Services can be developed, deployed, and scaled independently.
+
+### Resilience
+Services must handle failures gracefully (circuit breakers, retries).
+
+## Service Design Patterns
+
+### Service Boundaries
+Define services around business capabilities, not technical layers:
+- ✅ User Service, Order Service, Payment Service
+- ❌ Database Service, Email Service (too technical)
+
+### Service Size
+Guideline: A service should be maintainable by a small team (2-pizza team).
+
+### API Design
+- Use RESTful APIs for synchronous communication
+- Use gRPC for high-performance internal communication
+- Use message queues for asynchronous communication
+- Version APIs (v1, v2) to support backward compatibility
+
+## Communication Patterns
+
+### Synchronous (Request-Response)
+
+**REST APIs:**
+```
+Service A --HTTP--> Service B
+          <-JSON---
+```
+
+**When to use:**
+- Need immediate response
+- Simple request-response flow
+- External-facing APIs
+
+**gRPC:**
+```
+Service A --Protocol Buffer--> Service B
+          <--Binary Response---
+```
+
+**When to use:**
+- Internal service communication
+- Need high performance
+- Strong typing required
+
+### Asynchronous (Event-Driven)
+
+**Message Queue:**
+```
+Service A --publish--> Queue --consume--> Service B
+```
+
+**When to use:**
+- Don't need immediate response
+- Decouple services
+- Handle bursts of traffic
+- Background processing
+
+**Event Bus/Broker:**
+```
+Service A --emit event--> Event Bus --subscribe--> Service B, C, D
+```
+
+**When to use:**
+- Multiple services need same event
+- Event sourcing patterns
+- Complex event processing
+
+**Popular Tools:**
+- Kafka: High-throughput, event streaming
+- RabbitMQ: Traditional message broker
+- AWS SQS/SNS: Cloud-native messaging
+- NATS: Lightweight messaging
+
+### API Gateway Pattern
+
+Centralized entry point for all client requests.
+
+**Responsibilities:**
+- Request routing
+- Authentication/Authorization
+- Rate limiting
+- Request/Response transformation
+- Caching
+- Load balancing
+
+**Tools:**
+- Kong
+- AWS API Gateway
+- Nginx
+- Spring Cloud Gateway
+- Traefik
+
+### Service Mesh Pattern
+
+Infrastructure layer for service-to-service communication.
+
+**Features:**
+- Traffic management
+- Security (mTLS)
+- Observability
+- Circuit breaking
+- Retry logic
+
+**Tools:**
+- Istio
+- Linkerd
+- Consul Connect
+
+## Data Management
+
+### Database Per Service
+
+Each service owns its database. No shared databases.
+
+**Benefits:**
+- Service independence
+- Technology flexibility
+- Scalability
+
+**Challenges:**
+- Data consistency
+- Joins across services
+- Transactions
+
+### Saga Pattern
+
+Manage transactions across multiple services.
+
+**Choreography:**
+```
+Order Service --creates order-->
+    |--event--> Payment Service --processes payment-->
+    |--event--> Inventory Service --reserves items-->
+    |--event--> Shipping Service --ships order-->
+```
+
+Each service listens to events and publishes new events.
+
+**Orchestration:**
+```
+Order Orchestrator
+    |--call--> Payment Service
+    |--call--> Inventory Service
+    |--call--> Shipping Service
+```
+
+Central orchestrator coordinates the saga.
+
+### CQRS (Command Query Responsibility Segregation)
+
+Separate read and write models.
+
+**Pattern:**
+- Write: Command Model (normalized, transactional)
+- Read: Query Model (denormalized, optimized for reads)
+- Sync via events or batch processes
+
+**When to use:**
+- Complex domains
+- Different read/write patterns
+- Need to scale reads separately
+
+### Event Sourcing
+
+Store state changes as events rather than current state.
+
+**Benefits:**
+- Complete audit log
+- Temporal queries
+- Event replay for debugging
+- Derive new models from events
+
+**Challenges:**
+- Complexity
+- Event versioning
+- Storage requirements
+
+## Deployment Patterns
+
+### Containerization
+
+**Docker:**
+```
+Each service → Docker image → Container
+```
+
+**Benefits:**
+- Consistency across environments
+- Isolation
+- Resource efficiency
+
+### Container Orchestration
+
+**Kubernetes:**
+```
+Cluster
+├── Namespace: production
+│   ├── Deployment: user-service
+│   ├── Deployment: order-service
+│   └── Deployment: payment-service
+└── Namespace: staging
+```
+
+**Features:**
+- Automated deployment
+- Scaling
+- Self-healing
+- Service discovery
+- Load balancing
+- Rolling updates
+
+### Service Discovery
+
+**Pattern:**
+Services register themselves and discover other services dynamically.
+
+**Client-side:**
+- Service queries registry
+- Service makes direct call
+- Tools: Eureka, Consul
+
+**Server-side:**
+- Load balancer queries registry
+- Routes request to service
+- Tools: Kubernetes, AWS ELB
+
+### Configuration Management
+
+**External Configuration:**
+- Spring Cloud Config
+- Consul
+- etcd
+- Kubernetes ConfigMaps/Secrets
+
+**Pattern:**
+- Store config separately from code
+- Environment-specific configs
+- Runtime configuration changes
+
+## Observability
+
+### Distributed Tracing
+
+Track requests across multiple services.
+
+**Tools:**
+- Jaeger
+- Zipkin
+- AWS X-Ray
+- Datadog APM
+
+**Pattern:**
+```
+Request ID: abc123
+User Service (10ms) --> Order Service (50ms) --> Payment Service (100ms)
+Total: 160ms
+```
+
+### Centralized Logging
+
+Aggregate logs from all services.
+
+**Tools:**
+- ELK Stack (Elasticsearch, Logstash, Kibana)
+- Splunk
+- CloudWatch Logs
+- Datadog
+
+**Pattern:**
+- Structured logging (JSON)
+- Correlation IDs
+- Log levels
+- Searchable aggregation
+
+### Metrics and Monitoring
+
+**Metrics to track:**
+- Request rate
+- Error rate
+- Response time (latency)
+- Resource usage (CPU, memory)
+
+**Tools:**
+- Prometheus + Grafana
+- CloudWatch
+- Datadog
+- New Relic
+
+### Health Checks
+
+**Types:**
+- Liveness: Is service alive?
+- Readiness: Can service handle requests?
+- Startup: Has service started?
+
+**Implementation:**
+```
+/health/live    → 200 OK
+/health/ready   → 200 OK (or 503 if not ready)
+```
+
+## Common Challenges
+
+### Network Latency
+**Solution:** Async communication, caching, service mesh
+
+### Data Consistency
+**Solution:** Eventual consistency, saga pattern, CQRS
+
+### Testing
+**Solution:** Contract testing, integration tests, chaos engineering
+
+### Debugging
+**Solution:** Distributed tracing, centralized logging, correlation IDs
+
+### Security
+**Solution:** API gateway, service mesh mTLS, OAuth2/JWT
+
+### Service Proliferation
+**Solution:** Clear service boundaries, API standards, governance
+
+## Best Practices
+
+1. **Start with a Monolith:** Don't start with microservices
+2. **Define Clear Boundaries:** Use Domain-Driven Design
+3. **Automate Everything:** CI/CD, testing, deployment
+4. **Monitor from Day One:** Logging, metrics, tracing
+5. **Design for Failure:** Circuit breakers, retries, timeouts
+6. **Version APIs:** Support backward compatibility
+7. **Document APIs:** OpenAPI/Swagger
+8. **Use Async for Non-Critical Paths:** Message queues
+9. **Implement Health Checks:** For orchestration
+10. **Security at Every Layer:** Gateway, service mesh, code