为什么微服务需要 API 网关？

API 网关在微服务架构中正变得越来越流行。最近，谷歌也发布了自己的API 网关。现在正是探讨微服务架构为何需要 API 网关，以及在没有 API 网关的情况下微服务架构现状的好时机。

我们来看一个没有 API 网关的微服务架构。

除了核心功能之外，每个微服务传统上也都在执行这些操作。

• 基于 OAuth 或 JWT 令牌或简单的基于密钥的身份验证来验证请求。（此身份验证用于验证其他服务或用户是否有权访问此服务，而不是基于应用程序数据的典型用户身份验证。）
• 允许来自其他微服务的CORS 请求
• 根据其入侵防御系统 (IPS) 允许/拒绝请求。

• 速率限制——仅允许一定数量的请求。超过指定限制的请求将返回状态码 429（请求过多）。这些规则还可以保护微服务免受应用层DDoS 攻击。

• 监控 - 从请求/响应中收集指标，以获取有价值的洞察。例如：每分钟请求数、每个 API 的请求数、特定用户超出速率限制的请求数。

• 告警——这是监控的一个子集，用于针对特定事件生成告警。例如：当 1000 个请求的响应时间超过 500 毫秒时生成告警。使用 Prometheus 等可观测性工具有助于监控和告警。

• 日志记录 - 记录向服务器发出的所有请求。

• 请求终止 - 暂时禁用某些 API 的请求或在服务停机期间禁用该服务。

好的，以上列举了一些。可能还有更多。

这种方法的主要缺点：

• 当一个新的微服务出现时，所有这些功能都需要复制。
• 对一项功能的任何更改都应在所有服务中重复进行。例如：将请求日志记录从 Loggly 迁移到 StatsD。
• 从逻辑上看，所有这些功能都不是底层应用程序所特有的。它们可以与应用程序本身解耦。

API网关：

API 网关现在无需过多介绍。您可以将 API 网关视为架构中的另一个微服务，它负责执行上述所有功能。

• 它是微服务的入口点，充当守门人的角色，在将请求传递给相应的微服务之前执行所有基本功能。
• 所有功能现在都集中在一个地方，便于维护和分析。
• 当一个新的微服务启动时，它只需要处理请求并将响应发送回网关。API网关会处理其余的事情。
• 有了 API 网关，请求/响应转换、推出金丝雀部署等功能也成为可能。

我列举了一些API网关可以解决的问题。话虽如此，API网关究竟是必需的还是锦上添花，最终取决于架构本身。尤其是在架构中包含大量微服务的情况下，API网关就显得尤为重要。

无论是否绝对需要 API 网关，只要仔细观察 API 网关出现之前的设计，就会发现它明显违反了单一职责原则、不要重复自己以及高内聚低耦合原则。