关于 architecture-paradigm-microservices
面向评估和采用微服务的团队提供架构指导，涵盖服务边界、运营前提、弹性设计、治理和采用检查。
主要功能
- 01判断何时采用或避免微服务
- 02定义服务边界与数据所有权的步骤
- 03平台、弹性与治理建议
- 04架构交付物和退出标准
适用场景
- 01评估系统是否适合微服务
- 02规划服务边界和独立数据存储
- 03部署前准备平台及运营实践
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/architecture-paradigm-microservices确认已加载。
详细介绍
微服务架构范式
何时采用此范式
- 当组织结构要求团队拥有高度自主权并能够独立发布时。
- 当不同业务能力（限界上下文）有不同的扩展需求，或适合采用不同的技术栈时。
- 当组织明确承诺投入资源提升 DevOps 和 SRE 成熟度，包括先进的可观测性、CI/CD 和事件响应能力时。
何时不应采用此范式
- 当团队规模较小且组织复杂度较低时
- 当 DevOps 成熟度不足或平台工程资源有限时
- 当系统要求操作之间具有强事务一致性时
- 当处于需求快速变化的初创早期阶段时
- 当监管限制导致分布式数据管理充满挑战时
采用步骤
- 定义限界上下文：将每个微服务映射到明确的业务能力，并明确数据所有权。
- 验证服务数据自治性：每个服务必须拥有并控制自己的数据库或持久化机制。服务之间的所有数据共享都必须通过 API 或事件进行，而不是共享表。
- 构建可用于生产的基础平台：部署服务前，建立服务发现、分布式追踪、集中式日志记录、CI/CD 模板和自动化契约测试所需的基础设施。
- 为弹性而设计：为所有服务间通信实现超时、重试、断路器和舱壁等弹性模式。正式记录服务级别指标（SLI）和服务级别目标（SLO）。
- 自动化治理：实施自动化流程，确保所有服务都遵循安全扫描、依赖管理策略和一致的版本控制策略。
关键交付成果
- 一份架构决策记录（ADR），列出所有服务边界、对应的数据存储以及通信模式（例如，同步 API 与异步事件）。
- 一套“黄金路径”模板和操作手册，用于在平台上创建和运行新服务。
- 一份详细的测试策略，涵盖单元测试、契约测试、集成测试和混沌／弹性测试。
技术指南
API 通信：
- REST API：Spring Boot（Java）、Express.js（Node.js）、FastAPI（Python）
- GraphQL：Apollo Server（Node.js）、Hasura（PostgreSQL）
- gRPC：用于高性能内部通信的 gRPC 框架
服务发现与配置：
- 服务注册表：Consul、Eureka、etcd
- 配置：Spring Cloud Config、HashiCorp Vault、AWS Parameter Store
消息代理与事件：
- 消息代理：Apache Kafka、RabbitMQ、AWS SQS/SNS
- 事件流：Apache Kafka、Apache Pulsar、AWS Kinesis
可观测性：
- 分布式追踪：Jaeger、Zipkin、AWS X-Ray
- 指标：Prometheus、Datadog、CloudWatch
- 日志记录：ELK Stack、Fluentd、Splunk
真实案例
Netflix：视频流媒体平台，拥有数百个微服务，分别处理播放、推荐、计费和用户身份验证等不同方面。每个团队都能独立部署，不影响其他团队。
Amazon：电子商务平台，设有商品目录、订单处理、支付、库存和配送等独立服务。在 Prime Day 等流量高峰活动期间，可实现独立扩展。
Uber：网约车平台，通过微服务处理乘客匹配、司机派单、定价、支付处理和通知，从而能够快速开发和部署功能。
风险与缓解措施
- 分布式系统的复杂性：
- 缓解措施：微服务架构的运维开销很大。应组建专门的平台团队，并提供共享工具，以管理这种复杂性并为各服务团队提供支持。
- 数据一致性挑战：
- 缓解措施：在服务之间保持数据一致性是一项主要挑战。应采用 Saga 等模式来编排事务，验证基于消息的通信是否具备幂等性，并使用协调任务处理最终一致性。
- 服务粒度不当（“过度拆分”）：
- 缓解措施：如果服务过小，通信开销可能会超过分布式架构带来的收益。应验证每个服务是否拥有有意义且规模足够的功能。监控服务之间的变更耦合情况，以识别可合并的服务。
具体组件
此范式的实现通常会涉及的工具和抽象的词汇表。
这些不是依赖项，也不是 tools: frontmatter。
service-boundary-analyzer：通过调用图和数据所有权分析，找出候选服务边界api-contract-generator：为新的服务边界生成 OpenAPI/protobuf 脚手架resilience-patterns：重试、断路器、舱壁和超时库
退出标准
- 在任何服务独立部署之前，ADR 会列出所有服务边界及其数据存储和通信模式 （同步 API 与异步事件）。
- 每个服务都拥有自己的数据库或持久化机制；没有服务会直接读取其他服务的表 （通过数据所有权审查验证）。
- 在服务投入生产之前，已为每次服务间调用记录并实现弹性模式（超时、重试、断路器、舱壁）。
- 在第二个团队开始采用该架构之前，已准备好用于创建和运维新服务的“黄金路径”操作手册。
评论
支持 Markdown