微服务拆分之道
在做微服务的路上，拆分服务是个很热的话题。我们应该按照什么原则将现有的业务进行拆分？是否拆分得越细就越好？
拆分目的
单体架构中代码和项目集中式管理，给开发和运维带来了很大的便捷。 但是随着项目功能越来越多，开发团队扩大，单体架构的研发成本、研发效率和运维效率都会大幅降低。
拆分时机
- 业务规模：业务模式得到市场验证，需要进一步加速占领市场
- 团队规模：团队达到一定规模
拆分原则
- 单一服务内部功能高内聚、低耦合 & 闭包原则 & 服务自治 & 接口隔离
- 持续演进原则：拆分并非一蹴而就，要逐步进行；拆分之后，也可以权衡事宜进行合并或者二次拆分，最主要是持续演进！
- 拆分过程尽量避免影响日常功能迭代
- 避免环形依赖与双向依赖
拆分粒度
综合考虑业务复杂度和每个服务团队规模
拆分策略
综合考虑功能纬度和非功能纬度。
功能纬度
- 利用 DDD 划分清楚业务边界
非功能纬度
- 扩展性
- 复用性
- 性能
- 可用性
- 安全性
拆分方式
- 先按业务领域拆分
- 再按功能定位拆分
- 按重要程度拆分