选择合适的 API 网关模式,实现有效的 API 交付

语言: CN / TW / HK

原文作者:Elle Poole Sidell of F5

原文链接:选择合适的 API 网关模式,实现有效的 API 交付

转载来源:NGINX 官方网站


NGINX 唯一中文官方社区 ,尽在 nginx.org.cn

ProgrammableWeb 的 API 目录自 2005 年以来一直在跟踪外部可用的 API,这个数字在 2019 年 6 月突破了 22,000 大关。在此之前的 4 年里,发布的 API 数量增长了近 60%,这表明 API 经济不仅增长强劲,而且还将持续下去。

API 是许多业务的核心,能够创造巨大的价值和收入。现在,IT 组织要想保持领先,就必须找到一种管理和控制 API 访问的方法,而且这一需求比以往任何时候都迫切。

API 管理的重要性

随着企业开始从单体应用过渡到基于微服务的应用,他们还意识到 API 不仅可以促进高效的数字化通信,还可以成为新的收入来源。例如,Salesforce.com 有一半以上的年收入来自其 API,而 Expedia.com 有近 90% 的收入依赖于 API 经济。

兹事体大,企业不能容忍其 API 架构出现任何闪失,他们必须要确保 API 具备出色的性能、可控性和安全性。

API 网关 ≠ API 管理

虽然“API 网关”和“API 管理”这两个词语有时被互换使用,但要注意其中的区别。

API 网关是 API 访问权限的“门卫”,负责保护和管理 API 使用者与暴露这些 API 的应用之间的流量。API 网关通常负责处理身份验证和授权、请求路由、速率限制以避免系统过载、防护 DDoS 攻击、卸载 SSL/TLS 流量以提高性能以及处理错误或异常。

 API 管理是指在 API 的整个生命周期内管理 API 的过程,包括定义和发布 API、监控 API 性能、分析使用模式以创造最大业务价值等。

常见的 API 网关部署模式

那么,如何才能有效交付 API 呢?

作为全球首屈一指的 API 网关,NGINX 交付了当今网络上超过一半的 API 流量。虽然模式没有对错之分,但有一些 API 网关模式是最常用的,我们在此进行了总结。

集中式边缘网关

这是最常见的 API 网关模式,采用了传统的应用交付控制器 (ADC) 架构。在这种模式下,网关几乎可以处理所有事情,包括:

  • SSL/TLS 卸载
  • 身份验证
  • 授权
  • 请求路由
  • 速率限制
  • 请求/响应操作
  • Facade 路由

当从集中治理的单体应用暴露应用服务时,这种方法非常合适,但对于微服务架构或是总有频繁更改的情况就差点意思了 —— 传统边缘网关都是针对南北向流量进行优化,并不能高效处理分布式微服务环境中产生的大量东西向流量。

双层网关

随着服务逐渐变得小型化和分散化,许多企业转向了双层(多层)网关模式,将多个网关的角色分离开来。

这种方法将安全网关作为第一层,以管理:

  • SSL/TLS 卸载
  • 身份验证
  • 集中式连接和请求日志记录
  • 跟踪注入

将路由网关作为第二层,以处理:

  • 授权
  • 服务发现
  • 负载均衡

在一些情况下,我们需要考虑分散的 service 的灵活性和功能独立扩展的需求。双层网关模式最适合这样的情况。但是,当有多个团队管理不同的环境和应用时,这种方法可能会带来问题,因为它不支持分布式控制。

微网关

微网关模式建立在双层网关方法之上,为各个 DevOps 团队提供了专用网关,这不仅可以帮助他们管理 service 之间的流量(东西向流量),而且还支持在不影响其他应用的情况下进行变更。

此模式在边缘提供了以下功能:

  • SSL/TLS 卸载
  • 路由
  • 速率限制

然后企业再为每个 service 添加独立的微网关,以管理:

  • 负载均衡
  • 服务发现
  • 每个 API 的身份验证

尽管微网关的设计初衷是与微服务协同工作,但它们也为实现一致性和可控性增加了阻力。每个微网关可能都有一组不同的策略和安全规则,并且需要整合多个 service 的监控信息和指标。微网关很容易适得其反 —— 原本是为了尽量“小”,结果却往往需要根据业务目标实施全量的 API 配置。

per-pod 网关

per-pod 网关模式将代理网关嵌入到了各个 pod 或容器中,从而完善了微网关模式。网关负责管理到 pod 的入向流量,应用了身份验证和速率限制等策略,然后将请求传递到本地微服务。

per-pod 网关模式不执行任何路由或负载均衡,因此通常与上文提到的任一模式结合部署。具体来说,您可能会使用 per-pod 网关执行以下部分或全部功能:

  • pod 中应用的 SSL/TLS 卸载
  • 跟踪和指标生成
  • 身份验证
  • 速率限制和队列
  • 错误处理,包括断路器式的错误消息

per-pod 网关通常是轻量级的,并且其配置是静态的。它仅将流量转发到本地微服务实例,因此当应用拓扑发生变化时不需要进行重新配置。如果需要更改其中一项策略,则可以使用新的代理配置重新部署微服务 pod。

Sidecar(边车)网关和 service mesh(服务网格)

Sidecar 网关模式将网关部署为微服务的出入向代理,这允许 service 直接进行相互通信,sidecar 代理则负责处理和路由入站和出站的通信。

此模式使用边缘网关管理:

如欲了解本文后续内容,请点击《选择合适的 API 网关模式,实现有效的 API 交付》查看后续内容。


NGINX 唯一中文官方社区 ,尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源: