微服务体系结构中具有多个客户端的聚合器模式有效吗？

Question

假设两个微服务为一个产品提供信息，一个提供一般信息(A)，一个提供产品图像(B)。类似于网关聚合模式中描述的体系结构，我想在这些服务之间创建一个聚合网关。

现在，如果多个应用程序访问聚集网关(如下图所示)，这会与微服务体系结构发生冲突吗？

Answer 1

我认为我们在一个小的格式中看到了很多这种模式，“前端后端”之类的东西。但我认为这是一种反模式。

我所看到的问题是，聚合器可能会变得超薄。没有添加无法直接在应用程序或前端实现的额外功能。

但是您不能删除聚合添加的额外约束、额外的框、网络、额外的瓶颈和额外的代码。

例如，在您的示例中，微型服务方法的好处之一可能是，如果无法获取图像，仍然可以获得产品列表，如果某个部分出现故障，应用程序不会完全崩溃。

或者，如果我们发现图像速度慢，我们可以横向缩放图像服务。

虽然他的聚合器并没有使这些事情变得不可能，但是从‘服务有它自己的逻辑/数据但依赖于其他微服务’到'Gateway‘只是传递消息的一个模糊的过渡。我的感觉是，您正在反对在MicroService和它的使用者之间引入元素的流程。

Answer 2

我不认为层次化服务有什么问题，只要它们不形成循环依赖或其他讨厌的反模式。

我只想分析一下，在每个客户端上使用它，保存服务器CPU还是在服务器上使用它是否更方便，并简化了升级和测试。