我有一个微服务，它暴露了一些gRPC功能。每个gRPC函数只是将表中的数据作为单个记录（使用id参数）或所有记录获取。客户端是一个后端数据管理系统，它需要构建一个需要来自多个服务功能的数据的报告。
现在，在使用微服务时，显而易见的想法是客户端应该进行多次服务调用，并根据需求在最后组合数据。
优点 - 客户端和微服务将彼此独立
缺点 - 多个gRPC调用（每个记录考虑5个* 30个记录）
但不知怎的，这感觉不对（也许是它的单片架构思考），只是为了显示30条记录，我们必须进行150次gRPC调用。因此，替代方案可以是创建一个新的gRPC功能，它结合了服务本身的所有数据。
优点 - 只有1个gRPC电话
缺点 - 客户端和微服务器彼此依赖哪种类型会破坏微服务的目的。
我更偏向于第一种方法，但想要确认其他人对这种情况的看法。
答案 0 :(得分：1)
如果我正确理解您的陈述，后端客户端将聚合来自您的多个服务/功能的数据以构建报告。所以我认为这是只读的，因为它是用于报告的。报告本身是一个不同的有界上下文或子域。它具有与读写/ CRUD模型不同的行为特征。这就是CQRS模式的含义 - 您可以使用不同的模型来更新信息而不是用于读取信息的模型。
因此，在您的情况下，在将数据返回到使用客户端之前创建已经组合数据的不同服务/功能是实用，高效和最佳的。这些组合数据模型可以直接来自您的数据层（通过选择查询或存储过程）。
另一方面，对我来说，即使使用微服务，分发对象的主要规则仍然适用，即“不要分发对象。如果可能的话。（Martin Fowler，企业集成模式）”。