为什么建议微服务使用API​​网关？

Question

对于微服务，常用的设计模式是API-网关。我对它的实现和含​​义感到困惑。我的问题/疑虑如下：

1. 为什么一般不讨论其他微服务模式？如果是，那我想念他们了吗？
2. 如果我们部署网关服务器，这不是瓶颈吗？
3. 网关服务器难道由于单点请求过多而导致崩溃/故障吗？我相信，此时的负担将是巨大的（并记住Netflix正在做这样的事情）。如果我理解错误，请纠正我。
4. 流/下载/上传数据（例如文件，视频，图像）是否还将与其他中间件服​​务一起通过网关服务器传递？
5. 为什么我们不能使用代理模式而不是网关？

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

此外，我正在查看Spring Cloud Gateway。我似乎正在网关服务器中寻找某种东西，但是如果它只是路由（重定向）服务而微服务将直接负责对客户端的响应，则其路由功能会使我感到困惑。

Answer 1

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

如果吞吐量成为问题，则网关可扩展性强。您可以添加更多网关并对它们进行负载均衡

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

Answer 2

在微服务领域，API-网关是一种行之有效的模式。它具有几个优点，例如：

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

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

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

• 扩展API网关并对其进行负载平衡（如Arran_Duff所述）
• 您的API网关不应该为所有客户提供单一规格全能 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。流/下载/上传数据（例如文件，视频，图像）也将与其他中间件服​​务一起通过网关服务器传递吗？ 为什么我们不能使用代理模式而不是网关？

API代理与API网关的用例取决于所需的功能类型以及API生命周期中的位置。如果您现有的API不需要API网关可以提供的高级功能，那么建议您使用API​​代理。

您可以节省宝贵的工程带宽，因为代理易于维护，并且性能不会受到任何损失。如果您需要代理不提供的特定功能，则还可以开发一个内部层来适应您的用例。如果您处于API生命周期的早期，或者需要API网关可以提供的其他功能，那么投资其中一项将带来很多好处。