API网关简介

一. 什么是 API 网关

API 网关是客户端和微服务之间的服务器（或 L7 代理），充当所有客户端进入系统的集中入口点。
它是一个反向代理，接受客户端 API 调用并将它们转发到适当的微服务。
其次，作为一个入口，它还可以进行认证，鉴权，限流等操作，对上游服务保护。所以说，有了API网关，就可以做到“一夫当关，万夫莫开”。

通过为每个客户端提供 API，API 网关封装了底层系统的复杂性，让客户端与其对话，而不是调用特定的服务。他们还在流量到达服务之前执行安全检查（身份验证和授权），从而让服务专注于其核心功能；

从技术设计的角度上来说，API是一种抽象，它隔离了我们的使用以及实现；从开发管理的角度上来说，API是一种契约。

API网关是一种微服务的架构解决方案，服务于API“契约”精神，并尽可能的扩大这种契约的影响力，构建一种围绕API开发的“生态”。

二. 优缺点

优点：

• 封装了应用程序的内部结构。客户端只需要同网关交互，而不必调用特定的服务。
• API网关为每一类客户端提供了特定的API。这减少了客户端与应用程序间的交互次数，还简化了客户端代码。

缺点：

• 增加了一个我们必须开发、部署和维护的高可用组件。
• 由于所有API请求都要经过网关，它很容易成为系统的性能瓶颈。

三. API网关特性

使用面向切面编程在完成一些功能时，可以让代码的侵入性更小，实现更加优雅。而在微服务架构中，API网关可以给整个微服务增加面向切面编程的能力。
API网关特性如下：

• 路由转发
  之前说了「API网关」是内部微服务的对外唯一入口，所以外面全部的请求都会先发到这个「API网关」上，然后由「API网关」来根据不同的请求去路由到不同的微服务节点上。例如可以 根据路径 来转发、也可以 根据参数 来转发。
  并且由于内部微服务实例也会随着业务调整不停的变更，增加或者删除节点，「API网关」可以与「服务注册」模块进行协同工作，保证将外部请求转发到最合适的微服务实例上面去。
• 安全认证
  「API网关」就像是微服务的大门守卫，每一个请求进来之后，都必须先在「API网关」上进行身份验证，身份验证通过后才转发给后面的服务，转发的时候一般也会带上身份信息。
  同时「API网关」也需要对每一个请求进行安全性检查，例如参数的安全性、传输的安全性等等。
• 负载均衡
  既然「API网关」是内部微服务的单一入口，所以「API网关」在收到外部请求之后，还可以根据内部微服务每个实例的负荷情况进行动态的负载均衡调节。一旦内部的某个微服务实例负载很高，甚至是不能及时响应，则「API网关」就通过负载均衡策略减少或停止向这个实例转发请求。当所有的内部微服务实例都处理不过来的时候，「API网关」还可以采用限流或熔断的形式阻止外部请求，以保障整个系统的可用性。
• 日志记录
  既然所有的请求都需要走「API网关」，那么我们就可以在「API网关」上统一集中的记录下这些行为日志。这些日志既可以作为我们后续事件查询使用，也可以作为系统的性能监控使用。
• 数据转换
  因为「API网关」对外是面向多种不同的客户端，不同的客户端所传输的数据类型可能是不一样的。因此「API网关」还需要具备数据转换的功能，将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上，这样，兼容了这些请求的多样性，保证了微服务的灵活性。

除了上面提到的关键功能外，API 网关还提供许多功能。

• 速率限制： API 网关可以根据 IP 地址或 HTTP 标头限制请求。它有助于服务避免请求过载并防止恶意攻击，例如拒绝服务 (DoS)。速率限制还有助于 API 提供商实施不同的货币化策略（例如，分层定价模型）。
• 错误处理： API网关可以对因服务器内部错误、认证失败、无效输入等导致API请求失败的错误响应进行处理和标准化。可以为使用网关的客户端自定义错误的HTTP状态码和错误信息，帮助客户端正确理解和处理/调试。
• 断路器： API 网关可以实现断路器模式，帮助后端服务避免因请求失败而过载。熔断模式将停止向失败的服务转发请求并返回适当的错误代码。它有助于防止错误级联到健康的上游服务，并使 API 基础设施具有弹性。
• 缓存： API 网关可以缓存和服务先前对客户端请求的响应。如果启用了 API 缓存，网关将根据缓存的响应检查请求并转发请求（如果存在），从而无需每次都向后端服务发出新的相同请求。这将显着降低服务负载和响应延迟，并改善 API 性能和用户体验。
• SSL 终止： API 网关可以执行 SSL 终止，这涉及代表后端服务解密来自客户端的传入 SSL 连接。卸载 SSL 终止以及 authN/Z 等其他安全功能将使服务专注于其主要职责。

API 网关提供的所有这些功能为管理分布式服务系统带来了巨大的好处。

四. 实例：API网关接收gRPC请求

以下为客户端发送gRPC请求到API网关的实例：

API网关在接收到gRPC请求后会进行如下步骤：

• 请求验证： 首先，API 网关通过检查请求方法、标头和正文来验证传入请求，以确保它符合预定义的规则。此外，根据网关的允许列表和拒绝列表将请求列入白名单或黑名单，以执行严格的访问控制。
• 认证授权（AuthN/Z）： 网关通过验证凭据，如API密钥（认证），对经过验证的请求进行认证和授权，然后实施授权策略，如RBAC（基于角色的访问控制）。API 网关还可以使用 IdP（身份提供者）的帮助进行详尽的 authN/Z 检查，例如多因素身份验证 (MFA)。
• 服务发现： API 网关使用服务发现组件为授权请求定位适当的后端服务。它通过查询服务注册表或使用动态 DNS 来实现。
• 协议转换： API 网关可以在必要时在客户端和微服务之间转换协议。在上图中，客户端发送一个 gRPC 请求，该请求被转换为 REST 以供“购物车”服务理解。此外，网关在将响应返回给客户端之前将响应转换为面向公众的协议（此处为 REST 到 gRPC 格式）。
• 动态路由： 一旦找到后端服务并根据需要转换请求协议，API 网关就会将请求路由到适当的服务实例或负载均衡器。网关通常在其配置中定义了路由规则。

API 网关完成上述步骤后，会将服务的响应返回给客户端。但是，请注意，概述的步骤可能会有所不同，具体取决于网关的配置方式和其他功能的实现。

参考：
https://baijiahao.baidu.com/s?id=1768187899596681183&wfr=spider&for=pc
https://www.cnblogs.com/thiaoqueen/p/10789458.html