在微服务架构中如何和在哪里执行响应合成？
-
null
最终产品将是列表
，它将具有图像、描述、评分（满分为5分）和许多评论。
在微服务架构中，应该在什么位置组合多个微服务的响应？
大约1：
- MVC/REST API接近APIGateway
- API网关对所有微服务进行异步调用
- 响应将返回到MVC/WebAPI。在这里可以执行响应的合成。
大约2：
- MVC/REST API接近Apigateway
- API网关对产品微服务进行异步调用。
- Products微服务将调用其他微服务并执行组合，返回
List
共有1个答案
在这种情况下，我会采用方法1，因为你可以下载你需要的产品列表，并运行2个其他请求并行下载价格和评论。
在收到所有3个请求的响应后，构建模型并返回它。
我认为网关API应该足够聪明，可以对不同服务进行调用，并构建需要返回的结果。
-
我们最近开始将一个巨大的整体拆分为微服务。我们遇到的挑战之一是如何以及在哪里解析外键。 给你一个更好的视角。我们正计划构建以下微服务。这些服务中的每一个都有自己的专用数据库，以便使服务独立。 价格报价服务，主要负责管理基于变量和城市的价格 CarData Service，此微服务中存在三个问题。品牌、型号、变型 位置服务、州、城市和区域集中在单个微服务中 请帮助我解决以下问题 > 这是设计微服务的
-
我读了一些文章，看了一些视频，但在为这些微服务提供服务方面，没有找到具体的建议。我的理解是，他们应该使用自己的应用程序服务器。 我的问题是它们应该部署在不同的服务器上，还是没关系。 当它们在同一台服务器（计算机）上提供服务时，不会有端口冲突吗？
-
假设有两个微服务:订单和库存。order service中有一个API，它接受< code>ProductId 、< code>Qty等并下订单。 理想情况下，只有在库存服务中存在库存时才允许下订单。人们建议使用Saga模式或任何其他分布式事务。这很好，最终将利用一致性。 但是如果有人想滥用这个系统。他可以使用无效或缺货的产品(< code>ProductId)推送订单。系统将接受所有这些订单，并
-
让我们讨论一下微服务环境的体系结构。我们正在公司内部进行讨论，我想得到一些反馈。我认真考虑的是编排层（代码复制、更多移动部件改变api）。 网络应用- 原料药- 在这种情况下，服务不允许相互对话。业务流程层中的聚合服务 网络应用- 原料药- 这里允许服务相互对话，这里存在聚合服务。 账单属于哪里
-
我缓慢而坚定地采用了微服务方法。所以我创建了一些总是返回JSON的微服务。
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr