微服务拆分方法四种维度（可组合）：业务逻辑、可扩展、可靠性、性能

[[三个火枪手原则：微服务粒度应按团队规模而非业务边界确定]]确定了大致该拆出多少个服务，但具体按什么维度拆，不是只能按业务这一条路，而是可以按不同目的灵活选择甚至组合。基于业务逻辑拆分是最常见的方式，按职责范围识别业务模块、每个模块独立成一个服务；但实践中最大的坑是团队对”职责范围”该划多细经常争执不下（比如电商系统拆成”商品、交易、用户”3个服务还是”商品、订单、支付、发货、买家、卖家”6个服务，业务角度看粗细都说得通，谁也说服不了谁）——根源在于业务逻辑本身既支持粗粒度也支持细粒度划分，判断粒度不该从业务逻辑本身出发，而该先按”三个火枪手”原则算出大致的服务数量范围，再据此反推合适的”职责范围”：团队10人，大约拆4个服务，”登录、注册、用户信息管理”可以合并进一个”用户服务”；团队100人，能支撑到40个服务，”用户登录”本身就能独立成一个服务；团队1000人，”用户连接管理”这种更细的点都可能独立成服务。基于可扩展拆分是按稳定性排序：已经成熟、改动很少的模块拆成”稳定服务”（粒度可以粗一点，甚至逻辑上没强关联的服务也能塞进同一个子系统，比如”日志服务”和”升级服务”放一起），经常变化迭代的模块拆成”变动服务”（粒度可以细一点，但也不能无节制细分，要始终盯住服务总数），目的是让快速迭代的部分不至于不小心影响到已经稳定的成熟功能。基于可靠性拆分是按优先级把可靠性要求高的核心服务和要求低的非核心服务分开，重点保证核心服务的高可用，好处有三层：避免非核心服务故障拖累核心服务（比如日志上报量激增不会影响到核心业务）；核心服务本身逻辑更简单、数据更少、依赖组件更少，高可用方案设计起来也更简单；核心服务独立后占用的机器带宽等资源比不拆分时少很多，高可用成本自然也降下来了。基于性能拆分思路类似基于可靠性拆分，把性能要求高或压力大的模块单独拆出来，避免它拖累其他服务，比如电商抢购场景里压力最大的入口排队功能，就适合独立成一个服务。这四种拆分方式不是互斥的单选题，完全可以自由组合——比如基于可靠性拆出服务A、基于性能拆出服务B、基于可扩展拆出C/D/F三个服务，再加上原有服务X，最终一共形成A/B/C/D/F/X六个服务。

结构图：

flowchart TB
  A["微服务拆分的四种维度(可组合)"]
  A --> B["基于业务逻辑：按职责范围拆分<br/>先按三个火枪手算服务数量<br/>再反推职责范围粒度，而非从业务本身判断"]
  A --> C["基于可扩展：按稳定性排序<br/>稳定服务粗粒度/变动服务细粒度<br/>目的：迭代不影响已稳定功能"]
  A --> D["基于可靠性：核心与非核心分离<br/>好处：故障隔离+简化核心高可用设计+降低高可用成本"]
  A --> E["基于性能：拆出压力大的模块<br/>如抢购排队功能独立成服务"]
  B --> F["四种维度可自由组合叠加使用"]
  C --> F
  D --> F
  E --> F