为什么微服务推荐使用API网关？

Question

对于微服务，常用的设计模式是API-Gateway。我对它的实现和含义有点困惑。我的问题/顾虑如下：

1. 为什么没有普遍讨论微服务的其他模式？如果是，那么我错过了吗？
2. 如果我们部署网关服务器，不是瓶颈吗？
3. 网关服务器是否容易因单点请求过多而崩溃/失败？我相信此时负载会很大（请记住Netflix正在做这样的事情）。如果我理解错误，请纠正我。
4. 流/下载/上传数据（如文件、视频、图像）也将与其他中间件服务一起通过网关服务器？
5. 为什么我们不能使用代理模式而不是网关？

据我所知，在理想的环境中，网关服务器将接收来自客户端的请求，并在微服务完成相应任务后做出响应。

另外，我在看Spring Cloud Gateway。这似乎是我在网关服务器中寻找的东西，但如果它只是一个路由（重定向）服务，而微服务将直接负责对客户端的响应，那么它的路由功能让我感到困惑。

Answer 1

1.为什么不讨论微服务的其他模式？如果是，那我错过了吗？在数据库、服务等不同类别下，有许多微服务模式。这是一篇很好的文章https://microservices.io/patterns/index.html

2.如果我们部署网关服务器，这不是一个瓶颈吗？

在某种程度上是的。第三季度的答案图片将回答这个问题。

3.网关服务器是否容易因单点请求过多而发生崩溃/故障？我相信在这一点上，负载将是巨大的（请记住，Netflix正在做类似的事情）。如果我理解错误，请纠正我。

4.流/下载/上传数据（如文件、视频、图像）也将与其他中间件服务一起通过网关服务器？为什么我们不能使用代理模式而不是网关？

API代理与API网关的使用情况取决于您需要什么样的功能以及您在API生命周期中的位置。如果您已经有了一个不需要API网关提供的高级功能的现有API，那么推荐使用API代理。

您可以节省宝贵的工程带宽，因为代理更容易维护，并且您不会遭受任何可忽略不计的性能损失。如果您需要代理无法提供的特定功能，您还可以开发一个内部层来适应您的用例。如果您处于API生命周期的早期或需要API网关可以提供的额外功能，那么投资一个会有回报。

Answer 2

在微服务领域，API网关是一种经过验证的模式。它有几个优点，例如：

• 它封装了几个边缘功能（如身份验证、授权、路由、监视等）

在代理中实现所有这些功能并非易事。有几个API网关提供所有这些功能，更像Netflix Zuul、Spring网关或Akana网关。

此外，为了避免API网关成为瓶颈，您可以：

• 扩展API网关并对其进行负载平衡（如Arran_Duff所述）

Answer 3

网关模式用于为一系列不同的微服务提供单一接口。如果你有多个微服务为你的API提供数据，你就不想把所有这些都暴露给你的客户。对他们来说，最好只有一个入口点，而不必考虑为哪个数据投票哪个服务。能够集中处理诸如身份验证之类的常见处理也是件好事。与任何设计模式一样，它可以很好地应用于某些解决方案，但对其他解决方案并不适用。

如果吞吐量成为一个问题，网关是非常可扩展的。您只需添加更多网关并对其进行负载平衡

代理模式和API网关模式之间有一些细微的区别。我推荐本文给出一个非常简单的解释https://blog.akana.com/api-proxy-or-gateway/