微服务调用多个函数与自定义客户端特定函数

Posted 2023-03-08

【中文标题】微服务调用多个函数与自定义客户端特定函数

【英文标题】：Microservice calling multiple functions vs custom client specific function

【发布时间】：2018-07-25 02:09:14

【问题描述】：

我有一个微服务，它公开了一些 gRPC 功能。每个 gRPC 函数只是从表中获取数据作为单个记录（使用 id 参数）或所有记录。客户端是一个后端数据管理系统，它需要构建一个需要来自多个服务功能的数据的报表。

现在在使用微服务时，一个明显的想法是客户端应该进行多次服务调用，并根据需要在其末端组合数据。

优点 - 客户端和微服务将相互独立

缺点 - 多个 gRPC 调用（考虑每条记录 5 个 * 30 条记录）

但不知何故，这感觉不对劲（可能是它的单体架构思想），为了显示 30 条记录，我们必须进行 150 次 gRPC 调用。因此，替代方案可能是创建一个新的 gRPC 函数，该函数将服务本身的所有数据组合在一起。

优点 - 只有 1 个 gRPC 调用

缺点 - 客户端和微服务相互依赖，这违背了微服务的目的。

我更倾向于第一种方法，但想确认其他人对这种情况的看法。

【参考方案1】：

如果我正确理解您的陈述，则后端客户端正在汇总来自您的多个服务/功能的数据以构建报告。所以我认为这是只读的，因为它是用于报告的。报告本身是一个不同的有界上下文或子域。它具有与读写/CRUD 模型不同的行为特征。这就是 CQRS 模式的意义所在——您可以使用与用于读取信息的模型不同的模型来更新信息的概念。

因此，在您的情况下，在将数据返回给消费客户端之前创建一个已经组合数据的不同服务/功能是实用、高效和最佳的。这些组合数据模型可以直接来自您的数据层（通过选择查询或存储过程）。

另一方面，对我来说，即使使用微服务，分发对象的主要规则仍然适用，即“不要分发对象。如果可能。（Martin Fowler，企业集成模式）”。

【讨论】：

这真的不会违背拥有微服务的目的吗？下次需要更改报告时，客户必须将请求发送给服务所有者

既然您拥有这些服务/功能的域，那么您就是记录系统。要么您将这些报告数据作为单独的子域和单独的微服务提供。如果需要更改并且不中断，那么您可以添加一个新字段作为响应。如果是重大更改，则添加新的 v2 响应或新端点。最后，API 是为您的客户服务的，它是为他们设计的。如果数据不经常更改，那么您的客户可以选择将其缓存在最后并创建他们的自定义报告。