拆分时机
- 业务规模
- 团队规模
- 技术储备
- 人才储备
- 研发效率
拆分原则
- 闭包原则（CCP）
- 服务自治、接口隔离原则
- 持续演进原则
- 避免影响产品的日常功能迭代
- 服务接口的定义要具备可扩展性
- 避免环形依赖与双向依赖
- 阶段性合并
- 自动化驱动
拆分策略
拆分后的服务由相对独立的团队负责
- 功能维度拆分策略（基于业务复杂度）
- 基于数据驱动（业务复杂度较低）： 自下而上的架构设计方法，通过分析需求，确定整体数据结构，根据表之间的关系拆分服务
- 基于领域驱动（业务复杂度足够高）： 自上而下的架构设计方法，通过和领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文
- 从已有单体架构中逐步拆分：前后端分离，提取公共基础服务（如授权服务，分布式ID服务），不断从老系统抽取服务，垂直划分优先，适当水平切分
- 非功能维度拆分策略：扩展性、复用性、高性能、高可用、安全性、异构性
拆分风险
- 开发团队是否具备足够的经验
- 不断纠正
- 要做行动派，而不是理论派：在具体怎么拆分上，也不要太纠结于是否合适，如果拆了之后发现真的不合适，在重新调整就好了。
- 服务拆合
- 拆相当于我们开发代码，合相当于重构代码
- 人员和服务数量的不匹配
- 微服务数量过多和资源不匹配。合并后的服务包内的服务依然要满足微服务定义，以便在未来某一天要重新拆开的时候可以很快就分离
