在API世界中进行服务组合的正确位置？

Question

我在API正在成为默认标准的环境中工作，我们有很多可用的微服务......但仍然无法满足客户的要求......

我的客户要求通过撰写新作品并将其作为服务进一步托管来提供我需要提供的数据混合和匹配....

1）在专用的paas实例上进行此组合，网关或托管它们的正确平台是什么？

2）当我开始进行合成时，与直接从数据库中获取数据相比，我最终支付了http开销

任何帮助都会有所帮助

Answer 1

1. 正如许多微服务从业者所说，您可以使用api网关作为客户的入口点并在那里进行服务组合。更多信息 here
2. 是http有开销但有时它会被分解超重

Answer 2

如建议here所述，建议不要在网关层实现服务组合/业务流程，但最好使用单独的手工编码外观层。

其背后的原因是可伸缩性。每当需要扩展服务时，API网关也将不必要地扩展。

所以这里的选项是：

1. 手编码门面层
2. 用于编排的ESB api。网关将调用ESB api，后者随后会进行协调。

Answer 3

在寻找了将近两年之后，我在GraphQL中找到了答案，它可以进行汇总和视图选择，而工作量极小。

它是来自Apollo，Facebook等多家公司的开源实现，并且支持多种语言。