归档微服务:如何组织业务功能

Mic*_*zyk 0 architecture soa microservices

我正在创建一个微服务,负责处理zip和tar文件的归档和解压缩.

我知道微服务应该专注于一个业务功能(BF).但是,当我想到业务功能时,我应该意味着存档和取消归档(1个BF),归档和单独的归档(2个BF)或压缩,去皮,解压缩,解压(4个BF)?

是否有理由更喜欢其中一种选择呢?

zde*_*ine 6

微服务的质量总是一个问题,并没有一般的好答案.即使有时最终与整体结合也是合理的.这真的取决于你想要实现的目标.

对于您的问题,微服务通常旨在分组域的单个部分(例如计费,运输......).在你的例子中,我会说微服务可以负责压缩,因此归档和解除存储都可以在这个单一的微服务中.

从我的角度来看,将微服务视为单一功能(例如解开)的思路过于细微.它带来了更多"缺点"而不是"专业人士" - 通常更多的网络流量.想象一下您的微服务通过HTTP(这些天非常常见的情况)相互通信的情况,并且您希望创建tar.gz存档.一个微服务会做tar和另一个gzip,并且会有不必要的网络流量,这将耗费你的时间/带宽......