问个微服务调用问题。

[Hanggi]

假设有三个服务，订单服务，商品服务和用户服务。

三个服务均独立部署，有独立数据库。

现在要调用订单列表接口，获取订单数组，每个订单要带着对应订单的商品信息，每个商品信息又要带着对应的用户信息（可能是卖家信息）。服务间均可以通过 Id 获取想要的数据。

这种场景下，最佳实践要怎么实现？

[dzdh]

服务设计问题.

比如 调用订单服务获取的数据 是否能直接包含商品数据?(订单服务自己去调用商品服务)

[86091566]

用 key-value 数据库，记录商品信息 id 和用户信息 id 就行

[Hanggi]

@dzdh 对，如果现在要获取假设 50 个订单信息，但不想调用 50 个服务详情，也不想直接调用 50 个详情再整合呢？

[Hanggi]

@86091566 订单信息里已经存了商品 id，商品信息里也存了用户 ID 。有没有简单的调用整合方法？减少开销。

[linauror]

先调用订单列表，订单列表中包含了商品 id 和用户 id，订单服务再分别用 id 集合去商品服务和用户服务查询信息，最后再组装起来。就是商品服务和用户服务搞个批量查询的接口

[Hanggi]

@linauror 对，这是正常调用逻辑，但是都要增加服务内调用接口，没有更简单的方法了是吗？

[SachinBeyond]

@Hanggi
增加服务内调用接口是什么意思？

搞个批量调用，调一次订单服务穿 50 个订单 id，就拿到订单和商品 id 的关系

再调商品服务传多个商品 id，拿到商品卖家信息不就可以了吗

每个服务都是调一次，只不过有多个数据 id 。

[kop1989]

事前进行字段冗余。
即把订单列表所需要的商品、用户信息冗余进订单中。
当然，这要你来抉择是否划算。因为还有冗余信息更新的问题

[Leigg]

批量查询

[optional]

根据 id 获取 根据 id 列表批量获取。

[Bazingal]

订单必须冗余商品信息，因为商品信息可以修改，但是生成了订单时候的商品是不能改的

[wudaye]

我们目前是五楼的做法，但我看到过更优雅的实现是用一个服务专门用来写 bff 接口，聚合后端的领域接口

[xuanbg]

一个是交互的问题，列表就是列表，详情是点击进入详情页面再去获取。
二是数据结构的设计问题，订单需要有个快照，里面包含订单中商品和其他相关信息在下单时的快照数据，这样做的目的是为了你修改商品信息不会导致客户查看订单的内容与下单时不一致。所以，订单详情是一个完整的快照对象，不需要实时去获取其他的信息。

[xuanbg]

通过合理的交互设计，和合理安排 UI，就能避免这种批量接口调用。如果实在是不能避免，那就捏着鼻子上一个支持批量查询的接口吧。

[blessyou]

批量查询接口 + BFF 数据聚合

BFF 层去调用服务组装数据。

[leopod1995]

上 BFF

[xuanbg]

总之，在产品设计的时候，对需求进行严格约束，千万别把查询做成了统计。

统计是报表干的事，怎么能整合在管理页面里面呢？但我所见的业务，都想让业务管理页面的列表，在提供对业务的管理功能的同时，也提供统计功能。这种模棱两可的需求，一定要厘清，万万不可稀里糊涂地被带偏，否则查询变慢还是你的锅。

[libook]

Backends For Frontends，简称 BFF 。

简单来将就是一个专门面向 Client 端的服务，Client 只和它通信，涉及到调用微服务的情况由 BFF 来发起请求调用，然后把返回的数据进行整合、格式化再返回给 Client 端。

[zarte]

@libook 按这个例子 bff 查个列表也是要一个个去商品和用户服务获取信息再组装？

[death00]

十分同意 17 楼的观点，但奈何产品也认为这样是对的，所以开发也不能当人了。