微服务拆分原则

业务

根据业务主要可以采用DDD的战略分析的方式，通过分析子域，划分界限上下文的方式划分微服务。

但注意，DDD其实也是一种工具或方法，而且不是银弹，DDD适合于“业务”流程多的场景，富领域模型的核心域开始。典型的场景就是“状态流转”多的场景，比如审核流程，创建审核、审核过程会有多个业务状态的变化。而在查询非常多，或者数据分析的场景下，DDD并不能发挥优势。而且可能适得其反，使用简单的三层模型的方式更简单、高效。

非业务

性能

典型的，打点接口，吞吐量很大，一个或几个接口可以放在一个微服务内。而且基本没有什么领域模型，直接贫血三层可能更合适。

架构

如业务网关、日志服务、注册发现中心等都是一个单独的微服务。

发部更新频率

典型的就是活动服务，可以先从api层进行拆分，单独一个微服务。

技术异构

对于一些场景如用户关注设计师，是个多对多的关系，典型的大数据的场景可以单独进行服务的拆分。技术异构往往也与性能相关，往往使用不同的技术栈的服务对于吞吐量、延迟的要求也不一样。

根据团队

根据团队有两层理解，一是从微服务的个数上，如果一个7人团队20多个维护的服务就可能会吃力。

二是根据康威定律，组织的建设要和沟通保持一致，如果一个团队分割两地，那么这两个团队维护的服务要做到高内聚、低耦合。

PS

• 在微服务内，也需要考虑模块的合理划分，而不是做个小泥球。根据聚合去划分模块是个不错的方式。
• 微服务可以看成模块的服务化，前期合理划分的模块，模块内高内聚之间松耦合，比“微服务化”更重要。模块合理划分（或者聚合的合理划分）是微服务演进的一个重要前提
• 微服务是有消耗的，线程的隔离、RPC的调用等