architecture-paradigm-service-based

基于服务的架构范式

适用场景

• 具有按领域划分服务的多团队组织
• 需要独立部署各组件的系统

不适用场景

• 足以采用单体架构的小型单团队项目
• 服务间调用代价过高的延迟敏感型系统

何时采用此范式

• 当团队需要一定程度的部署独立性，但尚未准备好应对管理大量微服务的复杂性时。
• 当共享数据库或大型系统（如 ERP）使完全的服务自治不切实际时。
• 当需要为合作团队或外部使用方建立清晰的服务契约时。

采用步骤

1. 划分能力：将相关业务功能组合成少量定义明确的服务，并为每项服务指定负责人。
2. 定义服务契约：使用 OpenAPI 或 AsyncAPI 等标准发布正式规范，其中包括服务等级协议（SLA）和明确的版本控制策略。
3. 管理数据库架构：即使服务共享数据库，也要为每个架构或表指定明确的所有者。所有破坏性变更都必须经过正式审核流程。
4. 建立服务中介：使用服务注册中心或 API 网关处理路由、身份验证和可观测性。
5. 规划演进：识别可能在未来拆分为更细粒度服务的架构“热点”。

关键交付物

• 一份架构决策记录（ADR），概述服务边界、数据所有权规则和协调机制。
• 一套针对每项服务的契约测试和消费者驱动契约测试，用于验证稳定性。
• 描述部署流程、回滚计划和服务依赖关系的操作手册。

风险与缓解措施

• 通过共享数据库产生耦合：
  • 缓解措施：共享数据库的变更可能会对各项服务产生连锁影响。可使用数据库视图、复制或正式的架构弃用计划来管理变更，从而降低这种风险。
• 架构退化：
  • 缓解措施：缺乏严格治理时，此架构可能会退化为“分布式单体”：在单体架构的基础上增加了网络跳转的复杂性。密切跟踪耦合指标，并严格执行服务和数据的所有权划分，以防止这种情况。

具体组件

描述此范式实现通常会包含的工具和抽象的术语。它们不是依赖项，也不是 tools: frontmatter。

• api-gateway：单一入口，负责将请求路由到粗粒度服务，并集中处理横切关注点
• service-registry：包含可用服务、健康状态和契约的目录
• schema-management：用于管理跨服务边界类型的共享架构仓库

退出标准

• 在任何服务独立部署之前，ADR 已概述服务边界、每个架构或表的明确数据所有权，以及协调机制（服务注册中心或 API 网关）。
• 每个服务间交互点都有正式的服务契约（OpenAPI 或 AsyncAPI），其中包含版本控制和 SLA 声明。
• 每项服务都有消费者驱动契约测试，并且在服务负责人合并破坏性接口变更前通过 CI。
• 已记录共享数据库耦合热点及其架构弃用计划；任何未通过视图或复制层便读取其他服务表的服务，都会被标记为架构违规。