【发布时间】：2015-11-21 19:22:57
【问题描述】：
我正在创建一个微服务，它将负责处理 zip 和 tar 文件的归档和取消归档。
我知道微服务应该专注于一个业务功能 (BF)。但是当我想到业务功能时，我应该是指归档和取消归档（1 个 BF）、归档和单独取消归档（2 个 BF）还是压缩、去皮、解压缩、去皮（4 个 BF）？
有什么理由比其他选项更喜欢其中一个选项吗？
【问题讨论】：
标签： architecture soa microservices
【发布时间】：2015-11-21 19:22:57
【问题描述】：
微服务的粒度始终是一个问题，没有普遍的好答案。即使有时最终选择单体应用也是合理的。这真的取决于你想要达到什么目标。
对于您的问题，微服务通常旨在对域的单个部分进行分组（例如计费、运输......）。在您的示例中，我会说微服务可以负责压缩，因此归档和取消归档都可以在这个单一的微服务中进行。
在我看来，将微服务视为单一功能（例如去皮）过于细化。它带来的“缺点”多于“优点”——通常是更多的网络流量。想象一下您的微服务通过 HTTP 相互通信的情况（这些天非常常见的场景）并且您想要创建 tar.gz 存档。一个微服务会执行 tar，另一个会执行 gzip，并且会产生不必要的网络流量，这会花费您的时间/带宽......
【讨论】：
-
应该考虑的另一件事是独立扩展功能的能力。例如，出于某种原因，对归档的需求很大，但对取消归档的需求就更少了。我们希望为归档工作增加更多功能，但不是取消归档工作。如果归档服务与取消归档分开构建，我们可以通过赋予更多权力或启动更多归档服务实例来做到这一点
我不认为 zip/unzip/etc 应该被视为业务功能。这些是实现特定业务功能所需的单独技术功能。
对我而言，业务功能是“归档此数据”，其中可能包括压缩数据、将其粘贴到某种归档存储系统中，以及为将来检索编制索引。
【讨论】：