微服务划分

前言

微服务，毕竟是由许多的服务组合在一起的。其实我也给不出一个很好的划分方法。这个事情本来就是没有正确答案的。各种因素吧，组织结构，管理，技术等等。这些元素中可能技术反而是最弱的一个因素了。更多的时候可能还是需要临时发挥了。

如果想搞微服务的话，可以先从大粒度搞起来。然后大刀阔斧的拆分。最后再细细的琢磨下如何将服务的粒度变小。重构是一个很重要的次，小到函数的重构，到达服务的重构。都是相通的。

很多时候微服务化感觉有点像给奔驰的火车换轮子的过程。在各种限制条件中妥协，最后拿出一个可用的方案。

不过总还是有些条件不得不遵守的：

简单划分了以上的规则。

有多少人干多少活，有多少机器干多少活……没有足够的人，你分的太细碎以后，只能给自己增加苦恼。没有足够的资源，你分的那么琐碎，部署都没有地方……后期的维护更是噩梦。

很多时候人的精力是有限的，即使同一个项目中，也不是所有人都项目的整体都有很清晰的把握的。这个如果再拆的很细碎，那么就更是无奈了。

即使微服务目前有了如k8s之类的技术，但是还是要有一个最小部署的底线在。不依赖这些技术，如何让系统能够在以最少的物理条件的基础上运行起来。如果运行不起来的话，放心上云了，上k8s也是一样的挂掉。

模块之间的调用关系清晰，调用链尽量简单。如果调用的链路过于复杂，那么就应该考虑优化业务了。避免出现嵌套服务调用的出现。

服务之间的依赖关系清晰明了，如果一个服务和多个服务有依赖，可以根据这些依赖关系把有相关性的整合到一起。

服务之内的结构也应该清晰，服务内的耦合也尽量减轻。便于服务的拆分。