微服务下跨服务的数据查询如何处理?

通过 rpc 调用取用户服务拉昵称之类的拼装到一起，这应该有个胶水层来做，我们公司是前端用 node 做的。

通过 openfeign 之类的远程调用查一下呗

@zjyl1994 #1 感谢回复，胶水层是不是不做业务逻辑就只作为数据的处理呢

@RainCats #2 感谢回复，远程调用懂得，调用后不久得到了两份数据，并不是想要的数据格式，demo 尝试过手动去合并成一份数据，但是想了解下有没有更高级的方式

user_id 对应的 name 这种一般不要求试试的,都是可以加载到缓存中的,比如 redis 集群中,这样服务就直接读了.
其他的数据,就直接到其他服务查了

不矛盾啊，先查排行榜，再按照 user_id 批量拉取用户头像昵称，前端自己组装数据即可，任何情况都不推荐 join 查询

@Canon1014 对，只负责去各个服务拉数据然后变形成前端要的样式

@ikas 感谢回复，所以还是需要手动合并一下

@keepeye 了解了，感谢

@zjyl1994 了解

@keepeye #6 任何情况不推荐 join+1

我们都是查了业务数据 带上用户 id 一次性批量查出用户数据，然后组装

@a href="/member/nodododo">nodododo #12 了解了 感谢回复

业界各种方案都有用的；以排行榜服务和用户服务为例：

1. 客户端自己根据 user_id 再查，这样排行榜业务不需要依赖和调用用户服务；不过这种如果追求极致的客户端体验的话可能不会用，毕竟如果数据查询多客户端查会体验差
2. 排行榜微服务接口在接口层依赖用户服务，调用用户服务接口，封装到排行榜接口之后返回；（微服务的一大优势就是用户服务可以把相关接口优化到极致，即使服务器端同步调用性能也够）
3. 排行榜和用户服务之上再来个胶水层，专门做数据组装，常用 nodejs 之类的做
4. 还有一种也是微服务中常用的，冗余；比如排行榜可以把自己依赖的用户名做一份冗余存到自己数据库中；但是此时要注意和用户服务的同步问题；一种做法是不敏感的数据本地缓存定时更新；另外更标准的做法是使用消息队列来监听用户服务发布的事件做本地实时更新

@Canon1014

确实微服务都是需要从不同服务去获取到数据，然后再组装到一起的。

我司涉及到搜索的才走 ES，mysql binlog 同步延迟的问题一般都能接受，因为是商品搜索的场景 延迟 1 秒还是能接收的。

我司就是 Java spring cloud 做的微服务，拆分很多模块（商品、订单、支付、权限、账户（财务）、用户中心），方便起见可以自己封装一个 CopyUtil，进行数据的 Copy，可以简化到处都是 vo.setXXXXX( dto.getXXXX ) 的问题。

然后是组装数据的性能损耗，因为都已经微服务化了，所以机器的横向扩展还是很容易的。不行就部署多个服务。

不得不说 spring 还是太吃内存了，吃机器怪兽。

@anonydmer #14 感谢回复，老哥有心了，讲解的很到位

@telan233 #15 感谢回复，大致了解了，我目前最担心的确实在数据组装的性能上

@Canon1014 其实还好，因为本来很多业务逻辑都靠数据库分担了（ join ），这会造成数据库的压力。但是微服务的查询一般都是直接查 id （主键），包括 = id 、in ( id,id,id ) 大部分都是这种场景，所以我个人感觉数据库的压力反而没这么大了。总之 利大于弊 吧

@Canon1014 性能问题不大，比如用户服务完全可以把根据 id 查的接口通过一系列手段如缓存优化到极致；实际应用中排行榜服务还可以使用并行调用、本地缓存等手段进一步提升获取数据的性能

那如果需要对用户信息进行搜索怎么做比较好呢

@Kyle18Tang #20 我这边想的是：假设按照用户名搜索，先带着用户名的条件去用户服务查找符合的数据（叫他 A 好了），然后再查询排行榜服务（ B ），排行榜服务里有 `user_id` 然后在 B 数据中查找 `user_id` 在 A 中的数据。就是感觉性能很差，必须搭配缓存

您好, Graphql

@stanjia #22 感谢回复，有看到类似的文章正在研究

跨服务不联查，只能正常批量查。需要联查不要拆数据库。

按用户名搜索一般会走两步，第一步放在客户端，比方说搜索张三。要支持模糊搜索，输入个三，此时调用用户模块服务，通过模糊查询返回给客户端用户信息，包括用户名字、id 。此时通过 id 精准查询排行榜服务。

当然如果能做用户信息缓存到 redis 那就没必要这么麻烦了。

上层应该有个聚合服务的包一下数据给到前端