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

对于微服务，常用的设计模式是API网关。我对它的实施和影响有点困惑。我的问题/关注如下：

为什么微服务的其他模式没有被广泛讨论？如果是，那么我是否错过了它们

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

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

流/下载/上传数据（如文件、视频、图像）也将与其他中间件服务一起通过网关服务器

为什么我们不能使用代理模式而不是网关

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

---

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

网关模式用于为一组不同的微服务提供单一接口。如果您有多个微服务为您的API提供数据，那么您不希望将所有这些都公开给您的客户端。对他们来说，最好只有一个入口点，而不必考虑为哪种数据轮询哪种服务。能够集中处理诸如身份验证之类的公共处理也是件好事。与任何设计模式一样，它可以很好地应用于某些解决方案，而不适用于其他解决方案

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

代理模式和API网关模式之间有一些细微的区别。我推荐这篇文章作一个非常简单的解释

---

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

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

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

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

• 扩展API网关并对其进行负载平衡（如Arran_Duff所述）
• 您的API网关不应为所有客户机提供单一的一刀切的API。如果请求量很大（或需要下载/上传的文件很大），那么这样做肯定会遇到问题3和问题4中提到的问题。因此，为了缓解这种情况，您的网关可以为每个客户端提供特定于客户端的API（API网关实例仅服务于特定的客户端类型或业务领域）。这正是Netflix为解决此问题所做的工作（请参阅）

---

1.为什么不讨论微服务的其他模式？如果是，那么我是否错过了它们？ 在不同的类别下有许多微服务模式，例如数据库、服务等。这是一篇非常好的文章

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

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

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

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

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

---

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

“API网关”就是这样一个通用术语。甚至代理也是一种网关，API网关也是一种代理