微服务划分

2020-07-05 • 2 minutes to read

前言

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

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

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

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

  • 量力而行
  • 依赖清晰
  • 同类同频

简单划分了以上的规则。

量力而行

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

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

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

依赖清晰

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

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

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

同类同频

相似的业务尽量放在一起,相同的负载,相同的更新频率尽量放在一起。

其实就是根据业务划分,如果这样的话,有时自然而然的就成为一个微服务了。相关的功能都聚合在一起,便于资源的整合。

同频的也尽量放在一起,比如负载,更新频率。如果A和B都是高并发的,那么尽量把这些聚合在一起。横向扩展的时候也能够一同扩展。更新频率相同的模块也尽量放在一起,特别是一小低频率的模块。很多功能上线以后不怎么修改,但是这些又和一些高频的功能在一个模块。这个时候可以考虑将这些低频模块拆分出来。毕竟不动的话,出现问题的概率最小不是么?

devmicroServices

wentao

写点代码,解决点问题。

PowerShell Tips

干了这碗毒鸡汤🥣