在服务化系统或者微服务架构中，我们如何拆分服务才是最合理的？服务拆分到什么样的粒度最合适？
按照微服务的初衷，服务要按照业务的功能进行拆分，直到每个服务的功能和职责单一，甚至不可再拆分为止，以至于每个服务都能独立部署，扩容和缩容方便，能够有效地提高利用率。拆得越细，服务的耦合度越小，内聚性越好，越适合敏捷发布和上线。
然而，拆得太细会导致系统的服务数量较多，相互依赖的关系较复杂，更重要的是根据康威定律，团队要响应系统的架构，每个微服务都要有相应的独立、自治的团队来维护，这也是一个不切实际的想法。
因此，这里倡导对微服务的拆分适可而止，原则是拆分到可以让使用方自由地编排底层的子服务来获得相应的组合服务即可，同时要考虑团队的建设及人员的数量和分配等。
有的公司把每个接口包装成一个工程，或者把每一次JDBC调用包装成一个工程，然后号称是“微服务”，最后有成百上千的微服务项目，这是不合理的。当然，有的公司把一套接口完成的一个粗粒度的流程耦合在一个项目中，导致上层服务想要使用这套接口中某个单独的服务时，由于这个服务与其他逻辑耦合在一起，所以需要在流程中做定制化才能实现使用方使用部分服务的需求，这也是不合理的，原因是服务粒度太粗。
总之，拆分的粒度太细和太粗都是不合理的，根据业务需要，能够满足上层服务对底层服务自由编排并获得更多的业务功能即可，并需要适合团队的建设和布局。
转载博客：https://blog.csdn.net/kwame211/article/details/78015601