比如我有一个用户服务, 一个订单服务.
当我查询订单列表的时候要带出 创建订单的用户名 但是我只有用户的 id, 这个时候就需要转换了。
想了一下有两个办法
1.直接远程调用户服务接口 一个一个的转换 但是这样效率也太低了
2.还是远程调用户服务接口,不同的是传一批要转换的 id ,这样只用调一次就够了, 不过在大数据量下就不太好了
有没有好的解决办法.
还有一个问题 当我想跟据 用户名 模糊查询 相关订单的时候 好像处理起来好麻烦, 本来一条 sql 搞定的事.
具体到主的例子，比如你获取了一个 1w 条记录订单列表，需要获取每个订单的用户信息，那你就发起 1w 个并发请求到用户信息服务里去查不就完了吗？
以前我们 join 完了再返回数据是因为数据库 IO 是性能瓶颈，所以要减少查询请求次数。但当你有 1w 台服务器同时为你服务，每台服务器只查一条数据的时候，这还是瓶颈吗？
当然，超大型服务可能还是要考虑服务器数量限制问题，毕竟服务器不是真的无限。但对一般的互联网企业来说，云平台的服务器跟无限的差不多。而且你只需为使用的时间付费，1 台服务器用 1w 秒与 1w 台服务器用 1 秒的价格是一样的。
而且用户再多也是那么快，反正是横向扩展的，用户多少与我无关。无需考虑这些问题可以有效减少开发时间。
当然实际应用不会有 1w 个并发，一般也就几十个。我说 1w 的例子是为了让事情变得更明显，传统思路是时候改变一下了。
好吧，真有这种需求的话，聚合查询才是正道。
仅仅考虑 lz 提出的 case，个人建议用户 id 可以作为数组参数一次性请求当前页面所有用户的用户名，或者使用具有唯一性的名称（ tb 订单似乎就是这么搞的）
用户名模糊查询问题, 用户名变动少可直接冗余，考虑到匹配用户相当多时，不建议先查模糊用户服务的到大量用户 id 。
如果后续订单查询中增加了大量用户相关的查询条件，可考虑使用 es 等数据聚合仓库，冗余了多个服务的数据
我的观点总结起来就一句话——Microservice 依赖于 Serverless 。
不过系统设计最核心的一句话是“一切设计都是妥协”，没有什么绝对正确的方案，就看你的案例适不适合。所以我希望你的观点是在充分了解 Serverless 的原理及其计费方式的情况下产生的，那样至少你明白我方案的利弊，否则咱俩的对话就毫无意义了
首先呢，主是确定使用了微服务架构，这是基本前提。
其次呢，我认为用户和订单分在两个服务里是合理设计，至少是一种常见设计。
有了以上两个前提，我才说，这种场景应该使用 Serverless 云计算。因为云计算可以无限横向扩展，让成千上万台服务器同时为你服务，从而抵消微服务带来的性能损耗，并且不增加服务器成本。
大体就是这样吧，如果还有没说清楚的欢迎帮我细化。
微服务的好处是解耦，并不是追求性能。
Serverless 的好处除了无限横向扩展，还可以降低开发难度，因为程序员基本不用考虑性能瓶颈了。