后端完整解析Service boundary design

微服务应该如何结合限界上下文、聚合与非功能需求划分服务边界？

服务边界应围绕业务能力与一致性不变量形成高内聚自治单元，再用性能、安全和团队因素校验。

系统设计微服务领域驱动设计system-design核心题完整解析编辑精选

直接结论

微服务不应按数据库表或技术层机械拆分。先做领域分析，识别子域、限界上下文、聚合和关键业务不变量，让一个服务拥有一组高内聚能力及其数据；再用独立伸缩、可用性、安全隔离、发布节奏、团队认知负荷等非功能需求调整边界。理想边界使服务能自治部署，并通过清晰契约协作。边界过大会形成分布式单体中的“巨石”，过小则带来大量同步调用和跨服务事务。

原理与步骤

限界上下文定义模型和术语在哪个范围内一致，同一个词在不同上下文可以有不同含义。聚合定义需要在一个事务内保持一致的不变量，通常不应被随意拆到多个服务。上下文映射明确上下游关系和集成方式。随后检查候选服务是否需要独立扩缩、是否含敏感数据、故障是否应隔离、团队能否端到端负责。跨边界协作尽量通过稳定 API 或事件，避免共享数据库和跨服务 join 把自治性重新耦合。

工程场景

电商中商品目录、定价、订单、支付和履约可能是不同上下文，但“订单”在销售与履约中的模型并不必相同。订单聚合负责下单时必须原子成立的不变量，库存预留通过明确命令或事件协作，失败走补偿而非跨库事务。若搜索读流量远高于写入，可把搜索投影作为独立可伸缩组件；若一个小团队维护低流量后台，过早拆成十几个服务反而会增加部署和排障成本。

验证与边界

领域边界不是一次性架构图，应通过事件风暴、代码变更耦合、调用链、故障数据和团队反馈迭代。共享语言相似不代表必须合并，技术栈不同也不构成拆分理由。服务自治不等于禁止所有同步调用，而是要控制级联延迟和故障。验证候选边界时可用“能否独立部署、是否拥有数据、失败是否局部、事务是否频繁跨界”四类问题；若答案持续否定，应先保留模块化单体。

答题练习

1先领域能力后技术拆分
2聚合保护事务不变量
3非功能需求用于校验和调整

常见错误

按表一表一服务
把拆得越小视为越微服务

可能追问

何时保留模块化单体
跨边界一致性如何设计

来源记录

原始来源: Microsoft Learn
来源页面: Identify microservice boundaries
最近收录: 2026-07-14
官方复核: Microsoft Learn