软件体系架构阅读笔记十四

在服务化系统或者微服务架构中，咱们如何拆分服务才是最合理的？服务拆分到什么样的粒度最合适？

按照微服务的初衷，服务要按照业务的功能进行拆分，直到每一个服务的功能和职责单一，甚至不可再拆分为止，以致于每一个服务都能独立部署，扩容和缩容方便，可以有效地提升利用率。拆得越细，服务的耦合度越小，内聚性越好，越适合敏捷发布和上线。

然而，拆得太细会致使系统的服务数量较多，相互依赖的关系较复杂，更重要的是根据康威定律，团队要响应系统的架构，每一个微服务都要有相应的独立、自治的团队来维护，这也是一个不切实际的想法。

所以，这里倡导对微服务的拆分适可而止，原则是拆分到可让使用方自由地编排底层的子服务来得到相应的组合服务便可，同时要考虑团队的建设及人员的数量和分配等。

有的公司把每一个接口包装成一个工程，或者把每一次JDBC调用包装成一个工程，而后号称是“微服务”，最后有成百上千的微服务项目，这是不合理的。固然，有的公司把一套接口完成的一个粗粒度的流程耦合在一个项目中，致使上层服务想要使用这套接口中某个单独的服务时，因为这个服务与其余逻辑耦合在一块儿，因此须要在流程中作定制化才能实现使用方使用部分服务的需求，这也是不合理的，缘由是服务粒度太粗。

总之，拆分的粒度太细和太粗都是不合理的，根据业务须要，可以知足上层服务对底层服务自由编排并得到更多的业务功能便可，并须要适合团队的建设和布局。

 转载博客：https://blog.csdn.net/kwame211/article/details/78015601