用途：为设计、构建和运维微服务系统提供模式、权衡与实用指导，帮助判断何时采用微服务、何时保留单体。
主要能力：
- 采用判断：多团队独立部署、不同伸缩需求、领域边界清晰、具备 DevOps 自动化时适合微服务；团队小（少于 8-10 人）、领域未明、初期开发速度优先、缺乏成熟 DevOps 时更适合单体。建议先构建结构良好的单体，有明确理由再拆分，避免过早拆分形成分布式单体。
- 服务边界：以业务领域而非技术分层划分，每个微服务对应一个限界上下文；依据业务能力、数据所有权、自治性、内聚与松耦合；上下文映射包括共享内核、客户-供应商、防腐层、遵奉者。
- 通信模式：同步用 REST（HTTP/JSON，适合 CRUD 与简单请求响应，可通过 URL 路径或请求头版本化）或 gRPC（二进制协议、.proto 强类型契约、支持流式，适合低延迟内部通信）；异步用消息队列（点对点，如 RabbitMQ、SQS）或事件（发布订阅，如 Kafka、SNS）。调用方无需即时结果、需时间解耦、缓冲峰值或多消费者响应同一事件时选异步。
- API 网关：负责路由、认证授权、限流、响应聚合、协议转换、SSL 终止，实现有 Kong、NGINX、AWS API Gateway、Envoy、Traefik；BFF 为每种客户端提供定制网关。
- 服务发现：客户端发现与服务端发现，实现有 Consul、Eureka、Kubernetes DNS、AWS Cloud Map；Kubernetes 环境常可直接用 DNS 发现。
- 事件驱动：事件溯源存储事件序列并重放推导状态，收益是完整审计、时间查询、重建读模型，代价是存储增加、查询复杂、最终一致与事件模式演进；CQRS 分离写模型与读模型，常与事件溯源搭配但相互独立。
- 数据管理：每服务独立数据库，避免共享数据库耦合，挑战是跨服务查询与分布式事务；Saga 用本地事务加补偿动作，分编排（事件驱动）与协调（编排器）两种；接受最终一致性，使用幂等操作安全重试。
- 容错：断路器状态为 CLOSED、OPEN、HALF-OPEN；配合指数退避重试、超时（每次外部调用都要设置，上游超时应长于下游）、降级策略（缓存数据、默认响应、排队、明确报错）；库有 Resilience4j、Polly、Hystrix（已过时）。
- 可观测性：日志（结构化 JSON、含关联/追踪 ID，集中到 ELK、Loki、Splunk）、指标（RED 与 USE 方法，Prometheus+Grafana、Datadog、CloudWatch）、追踪（传播 W3C Trace Context 或 B3，工具 Jaeger、Zipkin、AWS X-Ray、OpenTelemetry）；每个服务应暴露存活与就绪健康检查。
- 服务网格：以边车代理提供 mTLS、流量管理、可观测性、金丝雀流量切分与访问控制，实现有 Istio、Linkerd、AWS App Mesh；服务数量少于 5-10 个时不宜引入。
- 部署：蓝绿（两套环境、即时回滚、成本高）、金丝雀（小比例流量、逐步放量、风险低但较慢）、滚动（逐批替换、无额外成本、需向后兼容、回滚较慢）。容器编排以 Kubernetes 为主，核心概念包括 Pod、Deployment、Service、ConfigMap/Secret、HPA、Namespace；替代方案有 AWS ECS/Fargate、Docker Swarm、Nomad。
- 测试：测试金字塔为单元、组件、契约、集成、端到端；契约测试用 Pact、Spring Cloud Contract 在 CI 早期发现破坏性 API 变更；集成测试昂贵应少用，聚焦关键路径与失败模式；端到端最慢最脆弱。
使用方式：资料为技能说明文档，未提供安装命令或调用步骤，暂未提供。
适用场景：服务拆分决策、通信与数据一致性方案选型、容错与可观测性建设、部署策略与测试策略制定。
限制：资料未说明具体收费、价格、平台支持范围与效果保证，暂未提供；部分内容（如端到端测试段落）在原文中被截断。