微服务应该如何拆分？服务拆分有哪些原则？
简化版
微服务拆分应该围绕业务能力和领域边界，而不是简单按技术层或数据库表拆。好的拆分要做到高内聚、低耦合、数据归属清晰、接口稳定，并尽量让一个需求主要落在少数服务内完成。
详细版
常见拆分原则包括：
- 按业务能力拆，例如用户、商品、订单、支付、库存。
- 按领域模型拆，参考 DDD 的限界上下文。
- 保证服务内部高内聚，相关业务规则尽量放在同一个服务里。
- 减少跨服务强依赖，避免一个简单需求改动多个服务。
- 数据归属清晰，一个服务拥有自己的核心数据，其他服务通过接口或事件获取。
- 接口稳定，对外暴露业务能力，不暴露内部表结构。
- 先粗后细，避免早期过度拆分。
不推荐按 Controller、Service、DAO 这种技术层拆，也不推荐一张表一个服务。那样会制造大量远程调用和分布式事务，系统很容易变成“分布式单体”。
完整版教学
一、服务拆分为什么是微服务里最难的题
微服务最难的不是会不会用 Spring Cloud、Dubbo、Kubernetes，而是边界怎么切。边界切对了，服务之间协作自然；边界切错了，后面所有治理组件都只能帮你给复杂度止血。
拆分本质上是在回答三个问题：
这个服务负责什么业务能力？
这个服务拥有哪些数据？
这个服务和其他服务通过什么协议协作？如果这三个问题答不清，服务就容易变成“名字独立、逻辑互相缠绕”的假微服务。
二、优先按业务能力拆，而不是按技术层拆
一个典型错误是按技术层拆：
用户 Controller 服务
用户业务 Service 服务
用户 DAO 服务这种拆法没有业务意义，只是把原来的进程内调用改成远程调用。一次请求可能连续跨多个服务，每个服务都很薄，任何小改动都要联动发布。
更合理的是按业务能力拆：
用户服务：注册、登录、用户资料
商品服务：商品发布、商品查询、类目属性
订单服务：下单、订单状态流转、订单查询
库存服务：库存扣减、库存冻结、库存回滚
支付服务：支付单、支付回调、退款这样每个服务都有完整业务职责，而不是只有技术分层职责。
三、用限界上下文理解服务边界
DDD 里的限界上下文可以帮助判断边界。一个词在不同上下文中可能含义不同，例如“用户”：
| 上下文 | 用户的含义 |
|---|---|
| 账号上下文 | 登录名、密码、手机号、认证状态 |
| 订单上下文 | 下单人、收货信息、会员等级快照 |
| 营销上下文 | 人群标签、优惠资格、活动参与记录 |
如果强行让所有服务共享同一个“用户大模型”，模型会越来越胖，服务之间也会互相绑死。更好的做法是每个上下文维护自己需要的用户视图，通过接口或事件同步必要信息。
四、判断拆分是否合理的几个信号
可以用需求变更来反推服务边界是否健康。
如果一个普通需求，比如“订单取消后恢复优惠券”，需要同时改订单、支付、库存、优惠券、用户、通知六个服务，并且每个服务都要同步发布，这通常说明边界或协作方式有问题。
健康的拆分通常满足：
- 服务内部可以独立完成一类业务规则。
- 跨服务调用是业务协作，不是细碎的数据查询。
- 服务之间通过稳定接口或事件交互。
- 数据写入责任只有一个权威服务。
- 一个服务故障时，不会无差别拖垮所有核心链路。
五、服务拆太细会有什么后果
过度拆分会带来明显副作用。
第一，网络调用暴增。原来一个方法调用变成一次 RPC，请求延迟、失败率、排查难度都会上升。
第二，事务边界被打碎。本地事务能解决的问题，拆开后可能需要可靠消息、TCC、Saga 或补偿。
第三，团队协作成本上升。一个需求涉及多个服务，就要协调多个负责人、多个发布时间窗口。
第四，监控和运维复杂度上升。服务越多，实例、配置、日志、告警、容量评估都越复杂。
所以服务拆分不是越细越好，而是“细到能独立演进，粗到能保持业务完整”。
六、实战里的拆分步骤
比较稳的拆分方式是渐进式：
- 先梳理业务流程，画出核心链路，比如下单、支付、发货、退款。
- 找出业务名词和规则聚集点，比如订单、库存、支付单、优惠券。
- 判断哪些数据应该由哪个业务能力拥有。
- 先在单体内部做模块隔离，禁止跨模块直接访问内部表。
- 等边界稳定后，把调用频率可控、职责清楚的模块拆成服务。
- 拆出去后补齐超时、重试、熔断、监控、灰度发布。
七、常见误区与追问
这道题要紧扣「服务拆分原则」本身回答，不能把它混成泛泛的微服务架构套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖服务边界、通信方式、网关/BFF、数据归属、版本兼容和部署治理。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 服务拆分应围绕业务能力、领域边界、数据所有权和团队自治，不是按表或代码行数机械切割 | 不要停在名词解释 |
| 流程机制 | 识别业务能力 -> 划定领域边界 -> 确定数据归属 -> 评估调用频率 -> 设计接口契约 -> 逐步拆分验证 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 订单、库存、支付是不同业务能力，但订单主表和订单明细通常属于同一聚合，不应随便拆远程调用 | 微服务提升团队自治和独立演进能力，但会带来分布式调用、数据一致性、依赖治理和运维复杂度 |
服务拆分原则 面试拆解：
1. 识别业务能力
2. 划定领域边界
3. 确定数据归属
4. 评估调用频率
5. 设计接口契约
6. 逐步拆分验证记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「服务拆分原则」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：服务拆得越细越好。 过细会增加网络调用、事务和运维成本。
- 误区：按数据库表拆服务最简单。 表结构不等于业务边界，可能拆出大量贫血服务。
- 误区：拆完就不用管边界了。 边界需要通过 API、数据所有权和团队职责持续维护。
- 追问：DDD 在拆分中有什么用？ 帮助识别限界上下文和聚合边界。
- 追问：什么时候不该拆？ 业务变化不清、团队很小、调用强耦合或数据强一致要求极高时。
- 追问：如何渐进拆分？ 先模块化单体，抽接口和数据边界，再按高价值服务迁移。
八、加强记忆
服务拆分的关键不是“拆得多”，而是“边界准”：围绕业务能力和数据归属切服务，让服务内部高内聚、服务之间低耦合；如果拆完以后一个需求到处改、一次调用到处跳，那大概率不是微服务，而是被网络放大的单体。