Microservices Architecture
本介绍依据技能资料中的原文整理，仅涵盖资料明确提供的内容。资料未提及具体收费、价格、平台绑定或商业化信息。
用途
该技能是一份用于设计与实现微服务架构的综合指南，资料说明其使用场景为：设计分布式系统、将单体应用拆分为微服务，或实现服务之间的通信。它面向架构与工程实践，提供模式说明、对比与建议，而不是某个具体框架的 API 文档。
主要能力（资料覆盖的主题）
资料按以下模块组织内容：
- 微服务基础：定义微服务为「只做好一件事、可独立部署的服务」，并列出其特征（单一职责、拥有自己的数据、可独立部署、通过 API 通信、技术无关、由小团队负责）。给出单体与微服务的结构对比，以及适用与不适用场景的清单。
- 服务设计：领域驱动设计中的限界上下文（每个上下文有自己的通用语言、数据模型与业务规则）、服务边界的划分原则（按业务能力、子域、单一职责），以及服务规模的经验性指导（如「两个披萨团队可负责」、必要时 2 至 4 周可重写、单一业务目的、最小外部依赖、完全拥有自己的数据）。
- 通信模式：同步通信（REST、gRPC、GraphQL）与异步通信（消息队列如 RabbitMQ、SQS；事件流如 Kafka），并给出模式对比表，列出各自用例与权衡。
- 数据管理：每服务独立数据库的收益与挑战（无跨服务 join、最终一致性、数据重复）；数据一致性模式，包括 Saga 的编排式（choreography）与协调式（orchestration），以及事件溯源（存储全部事件而非仅当前状态，收益包括完整审计轨迹、时间点查询、事件回放、与 CQRS 天然契合）。
- API 网关与 BFF：网关承担请求路由、认证授权、限流、负载均衡、请求/响应转换、缓存、监控等职责；BFF 为不同客户端分别优化并聚合多个服务。
- 服务发现：客户端发现（客户端查询注册中心如 Consul、etcd 后直连服务并自行负载均衡）与服务端发现（由负载均衡器处理发现与路由，对客户端更简单）。
- 弹性模式：熔断器（CLOSED / OPEN / HALF-OPEN 状态与实现要点）、重试（含指数退避与抖动的 TypeScript 示例）、舱壁（隔离线程池防止级联故障）、超时（资料给出 withTimeout 的 TypeScript 示例，并建议外部调用始终设置超时）。
- 可观测性：日志、指标、追踪三大支柱，分布式追踪的上下文传播（如 X-Trace-ID）与工具举例（Jaeger、Zipkin、AWS X-Ray、Datadog），以及存活探针与就绪探针的 TypeScript 示例。
- 部署：容器化的 Dockerfile 示例（Node 18 alpine 镜像、只安装生产依赖、以非 root 的 node 用户运行）与 Kubernetes Deployment 基础 YAML（副本数、资源限制、livenessProbe 与 readinessProbe）。
- 测试策略：微服务测试金字塔（大量快速的单元测试、集成测试、契约测试、少量 E2E），并给出契约测试的消费者侧示例代码结构。
- 最佳实践与迁移清单：DO 清单（先单体后抽取、清晰边界、尽量异步、熔断、集中日志与监控、自动化、为失败而设计、API 版本化）与 DON'T 清单（服务过多过小、共享数据库、同步链路过深、忽视分布式复杂度、通过共享库耦合、跳过契约测试、无监控部署）；迁移清单从映射领域边界、识别候选服务、为新服务建立 CI/CD（资料注明新建流水线需用户批准）、实现网关、服务发现、分布式追踪、熔断，到用绞杀者模式（strangler fig）抽取第一个服务，并在切换流量前验证与单体路径一致，最后监控与迭代。
使用方式
资料本身为架构指南性质，未提供安装命令或运行命令。上述能力以结构化说明、ASCII 示意图、对比表格与少量代码片段（TypeScript、Dockerfile、Kubernetes YAML、契约测试）的形式呈现，可作为设计评审与落地时的参考依据。
适用场景与限制
资料明确建议在以下情况使用微服务：领域大而复杂、需要独立扩缩容、多个团队并行开发、各服务技术栈需求不同、故障隔离关键、需要频繁独立部署。不建议使用的情况包括：小团队或小应用、简单领域、严格延迟要求、DevOps 成熟度有限、领域边界不清晰。
限制方面：资料指出分布式系统本身存在复杂度，迁移需要 CI/CD、服务发现、追踪与熔断等配套能力；共享数据库、过深同步调用链、过细服务粒度均被视为反模式。具体实现框架、云厂商与成本相关信息本次资料未提供。