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

Question

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

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

据我了解，在理想的环境中，网关服务器会处理来自客户端的请求，并在微服务完成应有的任务后做出响应。

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

Answer 1

网关模式用于为一堆不同的微服务提供单一接口。如果您有多个微服务为您的 API 提供数据，您不希望将所有这些都暴露给您的客户端。对他们来说只有一个入口点要好得多，而不必考虑轮询哪个服务来获取哪些数据。能够集中身份验证等常见处理也很不错。像任何设计模式一样，它可以很好地应用于某些解决方案，但不适用于其他解决方案。

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

代理模式和 API 网关模式之间存在一些细微差别。我推荐这篇文章以获得非常简单的解释 https://blog.akana.com/api-proxy-or-gateway/

Answer 2

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

• 它封装了几个边缘功能（如身份验证、授权、路由、监控......）
• 它隐藏了您的所有微服务并控制对它们的访问（我认为您不希望您的客户应该能够直接访问您的微服务）。
• 它可以封装您的微服务请求的通信协议（有时该服务可能在内部混合了多种协议，甚至只允许在防火墙内使用）。
• API 网关还可以提供“API 组合”（编排对多个服务的调用并将它们的结果合并为一个）。不建议在微服务中实现这样的组合。
• 等等

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

此外，为了避免您的 API-Gateway 成为瓶颈，您可以：

• 扩展您的 API 网关并对其进行负载平衡（如上所述，Arran_Duff）
• 您的 API-Gateway 不应为您的所有客户端提供单一的万能 API。这样做，在请求量很大（或要下载/上传的大文件）的情况下，您肯定会遇到您在问题 3 和 4 中提到的问题。因此，为了减轻这种情况，您的网关（例如）可能会为每个客户端提供使用特定于客户端的 API（API-Gateway 实例仅服务于特定的客户端类型或业务领域..）。这正是 Netflix 为解决此问题所做的工作（请参阅 https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d）

Answer 3

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

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

在某种程度上是的。Q3 的答案图片会回答这个问题。

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

4.Stream/download/upload 数据（如文件、视频、图像）也会通过网关服务器与其他中间件服​​务一起传递吗？ 为什么我们不能使用代理模式而不是网关？

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

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