AgentSkillsCN

darwin-microservice-patterns

在基础设施与API设计中运用微服务技术模式。当您需要规划服务变更、审查API契约，或评估部署策略时，可使用此功能。

SKILL.md
--- frontmatter
name: darwin-microservice-patterns
description: Microservice technical patterns for infrastructure and API design. Use when planning service changes, reviewing API contracts, or evaluating deployment strategies.

Microservice Technical Patterns

Deployment & Independence

  • •Independently deployable: Each service MUST deploy without coordinating with others. If a plan requires simultaneous deployment, redesign with backward-compatible contracts first.
  • •Feature flags over deploy coordination: Use feature flags for progressive enablement rather than synchronized rollouts.

API & Data Contracts

  • •Backward-compatible API changes: Always additive. New fields are optional. Old fields never removed in the same release.
  • •API versioning: If breaking changes are unavoidable, version the API (/v1/, /v2/).
  • •API contracts first: Specify the contract (REST endpoint, event schema) before implementation details.
  • •Database schema independence: Each service owns its data store. No shared databases. Migrations must be backward-compatible.

Resilience

  • •Circuit breakers: Any inter-service call should have timeout + retry + fallback. Flag plans missing resilience patterns.
  • •Idempotency: Any state-modifying operation must be safe to retry. Specify how duplicate calls are handled.
  • •Health endpoints: Every service must expose /health (liveness) and /ready (readiness) with meaningful checks.

Operational Hygiene

  • •Observability: Plans must include how changes will be monitored (metrics, logs, alerts).
  • •Configuration via environment: No hardcoded URLs, credentials, or feature flags in code. Everything via env vars or ConfigMaps.
  • •Stateless services: Flag any in-process state that breaks horizontal scaling (caches without TTL, sessions, in-memory queues). Externalize to Redis/DB.