微服务合并拆分原则

几个要素

• 人数:同一个服务维护的人员过多

• 业务：对不同业务进行拆分，防止相互影响

• 性能：一个功能消耗的性能过大，可以独立出来。分库分表也是这种体现。

• 组织结构：不同团队间代码需要进行拆分，减少相互干扰

• 安全：对于核心代码需要进行权限隔离，防止核心代码泄露

• 替代性：通用性的功能需要进行独立，可以减少重复开发和不一致性。

• 交付性/复杂度：对于需要快速交付的项目需要独立，防止项目过于复杂，导致回归测试过于复杂，影响交付速度。

• 技术栈：不同技术实现不同功能，需要根据技术栈进行拆分

• 业务需求：根据也许提出如高性能、高可用或快速伸缩等需求，对项目进行相应的拆分，增加相应的指标。

拆分原则

1. 单一职责：高内聚，低耦合，实现单一功能，如单表操作。
2. 颗粒度适当：100个接口不能拆100个服务，适当的分组。
3. 团队结构：1个系统不能由2个团队维护，需要根据团队负责内容进行拆分。
4. 业务模型：不同的业务模型进行独立项目。
5. 演进拆分：项目起步时可以不需要太拆分过细，根据项目规模逐步拆分
6. 避免环形和双向依赖：拆分后的项目避免相互依赖或者循环依赖。

合并原则

减少服务间调用的性能损耗