微服务是不是应该具有仅将操作转发到另一个微服务的操作？

Posted 2023-03-08

【中文标题】微服务是不是应该具有仅将操作转发到另一个微服务的操作？

【英文标题】：Should microserivce has operations that only forward operation to another microservice?微服务是否应该具有仅将操作转发到另一个微服务的操作？

【发布时间】：2020-03-10 04:25:05

【问题描述】：

假设我们有两个微服务info-manage 和file-service，如果我们的用户想要上传头像。请求应该由网关直接路由到file-service 还是info-manage？从内聚的角度来看，所有其他信息都由info-manage 服务处理，info-manage 处理上传请求并将请求转发给file-service 更有意义。从性能的角度来看，那完全是在浪费带宽和 CPU。

【参考方案1】：

据我了解，您的信息服务负责管理用户信息，对此有一些逻辑并将其存储。然后你有一个文件服务，其中包含处理文件的逻辑（你在信息服务中没有）。

所以这是我对你的情况的感觉：

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

其次选择哪个服务来处理请求取决于逻辑：

用户是否随文件内容发送信息？在这种情况下，您将在信息服务中应用一些逻辑，我建议您调用它，应用逻辑，然后它将向文件服务发出请求以存储文件（此时它可能与考虑将用户信息文件存储在通用文件存储服务中还是将其保存在信息数据库中以避免这种内部调用对您来说是否有趣）

如果您只是发送一个文件并且不希望该信息服务应用逻辑，例如跟踪添加了哪个用户信息文件，然后直接调用文件服务。

正如我所说，如果我从与服务合作到现在的感受，我希望你能得到更多的答案来帮助你澄清这一点。

【参考方案2】：

这取决于您是否使用orchestrated approach or a choreographed one。 在任何一种情况下，我都看不到网络带宽或 CPU 使用率之间存在很大差异，因为正在执行的工作量基本相同。除非您将客户端用作协调器，在这种情况下，您可能会通过来自客户端->服务器

的潜在额外往返造成更多开销

在编排方法中，网关上 Avatar 操作的端点是工作流的编排器，因此它基本上会运行流程

与info-manage 服务对话，然后

与file-service交谈

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

在精心设计的方法中，您的网关涉及较少，它仅作为进入整个系统的入口点，并且不编排任何工作流程，它只是将消息发送给对某某感兴趣的任何人东西是需要的。因此，例如，它可能会将消息发送到队列中，例如

"user":"johndoe" ,"avatarName":"batman", "avatarImage":"[binary data]"

info-manage 和file-service 都在侦听此类消息，并且在收到此类消息后，他们正在使用该信息（或他们关心的该信息的子集）执行任何操作。 这是一种真正可扩展的运行方式，当您拥有一个甚至从客户端的角度想要完全异步的系统时非常棒，即我 POST 到 Avatar 端点，稍后我会检查或等待消息告诉我 OK/FAIL。 请记住，在这种情况下，错误处理和回滚会变得更加成问题。

我个人更喜欢默认的编排方法，因为它使最初的开发变得更简单；但编舞也是一种很好的方法。

【讨论】：

很好的答案，但我最初的选择是：1. 网关与file-service 通话以上传文件。 2.网关与info-manage通话，info-manage与file-service通话上传文件。 .