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

EN

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

如果吞吐量成为一个问题，网关是非常可伸缩的。您可以添加更多的网关并负载平衡它们。

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

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

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

在代理中实现所有这些特性并不容易。有几个API网关提供了所有这些功能，更像Netflix、Spring或Akana网关。

此外，为了避免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)。

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

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

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

3.网关服务器是否易受单点过度请求导致的崩溃/故障的影响？我相信现在的负载是巨大的(记住Netflix正在做这样的事情)。如果我理解错了，请纠正我。

​

​

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

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

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