我们正在尝试从单体架构转向微服务架构。我们考虑了隔离我们的服务的最佳方法，并开始一一这样做。现在我们有一个关于如何进行依赖调用的问题。让我详细解释一下。
假设我们有不同的微服务。其中一个包含有关产品的详细信息。其他微服务围绕产品展开，因此它们将成为交易、订单、报价等服务。所有微服务都使用 gRPC 进行通信。
所有这些服务都将引用具有项目详细信息的项目微服务（引用将通过 ID 完成）。因此，其他每个服务都将只有项目的 ID。
现在的问题（或者可能不是）是，当我们想要查看用户完成的交易列表时，我们还需要项目的详细信息。类似的订单列表，我们再次需要项目的详细信息。（不是所有细节，而是其中一些细节）。
我们可以考虑两种选择来处理这个问题。
一种是进行两次后续调用，一次调用交易或订单微服务，然后调用商品微服务以获取所需的部分详细信息。在这里，我们拥有自己的网关，在性能和网络方面都非常高效。
另一种是在服务本身使用事务和订单微服务所需的pub/sub复制部分数据。所以基本上类似于订单微服务中的新表并加入服务以提供数据。从而消除了进行相关调用的需要。
那么首先，服务的隔离是否恰当？
其次这两种方法中哪一种是更好的设计
注意：我们有大约 10 个服务依赖于项目数据库。同样在一个页面上，通常会调用 5-6 个微服务。好消息是我们有自己的网关，可以并行进行所有调用。因此，如果我们使用第一种方法，最多将有 2 个连续调用。
我们最近从citrix切换到HAProxy，以实现负载平衡。
问题在于，对于某些请求，HAProxy开始给出400错误（以前在citrix上正常工作）。因此，我们暂时从基于HTTP的负载平衡转向了基于TCP的负载平衡。
在进一步调查中，我们发现某些请求的HTTP标头中有多余的空间，这会导致400错误。
profileID<space>:value
vs
profileID:value
这些请求来自android应用，因此我们无法更改源代码。
我们正在尝试回到基于http的负载平衡。
是否有任何配置设置可能会让我们忽略空间。