Design patterns microserivce是否应该只将操作转发给另一个microservice？

假设我们有两个微服务

信息管理

和

文件服务

，如果我们的用户想要上传化身。请求是否应通过网关直接路由到

文件服务

或

信息管理

？从内聚性的角度来看，所有其他信息都是由

info manage

服务处理的，更合理的做法是

info manage

处理上传请求并将请求转发到

文件服务。从性能角度看，这完全是对带宽和cpu的浪费
 据我所知，您的信息服务负责管理用户信息，对此有一定的逻辑并进行存储。还有一个文件服务，它包含处理文件的逻辑（在信息服务中没有）

以下是我对你的情况的感受：

首先，因为您有一个网关，所以您的选择应该对用户透明，因此用户只需调用特定的端点即可上载此文件

第二，处理请求的服务取决于逻辑：

用户是否沿文件内容发送信息？在本例中，您将在信息服务中应用一些逻辑，我建议您调用它，应用该逻辑，然后它将向文件服务发出存储文件的请求（此时，考虑将用户信息文件存储在通用文件存储服务中或将其保存在信息数据库中以避免此内部调用对您来说是否有意义可能是相关的）

如果您只是发送一个文件，而不希望信息服务应用逻辑，例如跟踪添加了哪个用户信息文件，那么直接调用文件服务即可

正如我所说的，如果我的感觉是从服务工作到现在，我希望你能得到更多的答案来帮助你澄清这一点。
这取决于你是否使用了一个。
在这两种情况下，我看不出网络带宽和cpu使用率之间有太大的差异，因为执行的工作量基本上是相同的。但如果您将客户端用作编排器，则在这种情况下，您可能会通过从客户端->服务器的额外往返而导致更多的开销

在协调方法中，网关上化身操作的端点是工作流的协调器，因此它基本上通过

与
信息管理
服务交谈，然后
与
文件服务交谈


这种方法的一个优点是，您可以使用某种事务语义（即，如果任何一个子操作失败，则整个操作都会失败）相对轻松地管理此操作
因此，从客户端的角度来看，当您需要同步操作时，这是一种很好的方法。例如，我发布到Avatar端点，我希望得到同步的OK/FAIL响应
您也可以将客户端用作编排器，而不是网关，但这会带来一系列问题，我不推荐这样做，因为这会有效地使后端抽象泄漏，并迫使客户端了解您的内部工作流。此外，这意味着更多的客户端-服务器往返，从而增加带宽

在精心设计的方法中，您的网关很少涉及，它只作为您整个系统的入口点，并且它不协调任何工作流，它只向感兴趣的人发送消息，表示需要这样或那样的东西

{“用户”：“约翰多”、“化身名称”：“蝙蝠侠”、“化身年龄”：“[二进制数据]”}


信息管理
和
文件服务
都在监听这样的消息，在收到这些消息后，它们会对这些信息（或它们关心的信息子集）执行任何操作
这是一种真正可扩展的运行方式，当您有一个系统，即使从客户端的角度来看，您也希望它完全同步时，这是一种很好的方式，即，我将发布到化身端点，稍后检查或等待消息告诉我OK/FAIL
请记住，在这种情况下，错误处理和回滚变得更加困难

就我个人而言，默认情况下我更喜欢编排方法，因为它使最初的开发更简单；但编排也是一种很好的方法。
回答得很好，但我最初的选择是：1.网关与
文件服务
通话以上载文件。2.网关与
信息管理
通话，以及
信息管理
通话s到
文件服务
上传文件。