Published on

「或许是」史上最全的 API 网关调研

Authors
  • avatar
    Name
    Qun Peng
    Twitter

对大部分业务开发同学来说,API 网关都是一个既熟悉而又陌生的存在:说它熟悉,是因为无论你是后端还是前端,日常开发时都免不了要跟它打交道;但若要深入聊聊它的价值、架构和底层原理,我想大部分同学可能还得去问 ChatGPT——也合理,毕竟集团内部早就沉淀了大量成熟的 API 网关基础设施(比如阿里云 POP、淘宝 MTOP),作为用户我们只需点开控制台,简单配置一下就能用起来。

没错,我们并不需要成为 API 网关方面的专家,也能快速接入和享受它能带来的收益。这也是所有与 API 网关性质类似的基础设施,比如 Kubernetes、Service Mesh、分布式数据库等,它们一直以来追求的目标:屏蔽底层复杂性,降低使用门槛,让接入尽可能简单——最好简单到用户都完全感知不到它们的存在,润物细如声,助人似雷锋,那就最好不过了。

然而,这种便利性并不意味着我们可以完全忽视它们的存在。作为开发者,我们需要对 API 网关有更深入的了解,才能更好地使用它,比如:做系统架构设计时,能合理判断是否需要 API 网关,以及如何选型;排查相关问题时,能从全链路角度定位问题原因,以及优化性能瓶颈。为此,笔者总结了这篇关于 API 网关的调研文章,希望能帮你更好地学习、理解和使用 API 网关。

什么是 API 网关?

要理解 API 网关,首先需要理解:什么是「API」?按照 Wikipedia 的定义,API 是计算机程序用来向操作系统、软件库或计算机上运行的任何其他服务提供者,请求服务的一组函数、过程、方法或类。按照 API 调用时物理链路,可以将 API 分为本地 API 和 远程 API;前者在单个操作系统内部就可闭环完成,后者则需要走网络调用。网关嘛,突出一个"网"字,所以显然是服务于远程 API 的,例如最常见的基于 HTTP 协议的 Web API。

(图片来源:What is an API | API for beginners?

Amazon 的创始人 Jeff Bezos,早在 2002 年就在公司内部约定了著名的 API Mandate :"所有团队必须通过网络服务 API 暴露其数据和功能,使得服务之间可以通过这些定义良好的接口进行通信,而不是通过内部集成。" 在接下来的二十多年里,API 逐渐成为了软件开发和集成中最重要的设计产物之一,甚至很多时候比花里胡哨的 UI 还重要。而为了让 API 的提供与消费更加规范、具备互操作性,业界也诞生了许多 API 标准,比如 RESTful API 定义的事实标准 OpenAPI、专用于异步 API(事件、消息)定义的 AsyncAPI ,以及最近几年流行开的 GraphQLgRPC

回到 API 网关。在微软 Azure 的架构中心文档中,对API网关是这么定义的:API 网关位于客户端和服务之间。它充当反向代理,将请求从客户端路由到服务。它还可以执行各种横切任务,例如身份验证、SSL 终止和速率限制。

(图片来源:API gateways - Azure Architecture Center | Microsoft Learn

在上述定义中,API 网关被作为了一种基础设施;这也确实符合大部分人对 API 网关的主要认知。事实上,API 网关也可以被看作是一种现代化的"架构模式"(Architecture Pattern)。例如,在《Microservice Architecture》一书中,就专门囊括了「API Gateway Pattern」:

(图片来源:Pattern: API Gateway / Backends for Frontends

作者将 API 网关模式定义为:一种通过单一入口点集中处理所有客户端请求的架构模式。它解决了微服务架构中客户端如何高效访问不同服务的问题,尤其是在面对细粒度API、不同客户端数据需求、不同网络性能要求以及后端服务动态变化的情况下。

为什么需要 API 网关?

"计算机科学中的所有问题,都可以通过增加一个中间层来解决" — David Wheeler

API 网关作为额外增加的一个中间层,可以带来如下一些好处:

  • 统一接入点
    • 安全性提升:无需暴露内部所有服务;门禁,入口处统一做安全加固、流量控制、访问控制
    • 易于观测:流量汇聚点;可注入全链路 traceID;提高 API 调用的可见性
    • 简化服务端配置:在网关处统一配置安全策略、部署防火墙等,维护成本更低
    • 简化前端接入:只需与单个网关打交道(不用连接多个域名、处理不同的 CORS 和认证方式);后端服务对前端隐藏,可以轻易变更位置,前端不感知(Location-transparency)
  • 集中 API 管理
    • API 全生命周期管理:设计 -> 开发 -> 测试 -> 发布 -> 管理 -> 下线
    • 安全合规策略、数据分析、运营
  • 通用能力复用
    • 横向切面职责:协议转换、认证、安全、日志、统计、容错、服务发现等
    • 统一下沉到网关,减少建设维护成本,提高业务响应速度
  • 前后端解耦
    • 作为「Adapter」:独立变化、兼容旧接口、易于替换、互操作性
    • 作为「Facade」:聚合/编排 API 请求、协议转换,简化前端工作
    • 可支持 Mock / Stub 能力:方便 API 测试
  • 形成API生态
    • API 服务目录:可发现、可消费、可复用;接入支持(文档 / portal)
    • API 商业变现:账号管理、计量计费、支付管理

功能特性

  • 请求路由(Request-routing)
    • 规则匹配:支持各种规则匹配模式,常见包括
      • 基于"协议字段"匹配,e.g.
        • HTTP:method/host/header/path/queryString
        • TCP:sourceIp/destinationIp
        • HTTPS/TLS:SNI
        • gRPC:host/header/path
      • 基于"会话绑定":Session Affinity / Sticky Session
      • 其它:条件表达式、TTL、优先级
    • 流量调度:灰度(金丝雀)、蓝绿;A/B Test
    • 流量镜像(Traffic Mirroring)
  • 负载均衡(Load Balancing)
    • 基于注册中心 - 服务地址来源包括:
      • 手工维护:add / remove接口、IP 地址列表配置)
      • 基于服务发现,自动维护地址列表
    • 基于 DNS
      • 后端服务的host使用域名来配置时,且该域名会解析到多个ip地址,则会自动使用DNS负载均衡
      • DNS记录的TTL值大小决定了刷新速度;越小更新越及时,但性能影响越大
    • LB 算法支持
      • 标准算法:包括 Weighted Round-Robin, hash
      • 自定义算法
  • 健康检查(Health Check)
    • 主动检查:通过注册健康检查endpoint,定期检查
    • 被动检查:基于普通请求的响应情况,判断target的健康状况
    • 自动过滤不健康节点
  • 服务发现(Service Discovery)
    • DNS、K8s Service
    • Nacos、Consul、Eureka、ZK、etcd
  • 协议支持(Network Protocols)
    • HTTP(s) 1.1, HTTP/2, HTTP/3(QUIC)
    • RPC:Dubbo、gRPC(包括 gRPC-web
    • TCP / UDP:4层通用代理
    • TLS:可以卸载证书,也可以不卸载(passthrough模式,基于SNI来匹配路由)
    • WebSocket
    • Proxy Protocol
    • MQ:MQTT、RocketMQ、Kafka
  • 协议转换(Protocol Converter)
    • TLS Termination:相反方向也有(但不常见),e.g. HTTP -> HTTPs
    • HTTP to dubbo / gRPC
    • HTTP to Kafka
  • 规范支持(API Specifications)
    • OAS / Swagger (REST风格)
    • GraphQL
    • AsyncAPI
  • 认证鉴权(Authn & Authz)
    • BASIC、JWT、HMAC签名;包括调用上游接口的认证鉴权
    • SSO / 三方认证相关:OAuth 2.0, OIDC, SAML, LDAP
    • mTLS;证书管理
    • 动态拦截规则:e.g. 基于参数表达式
  • 安全防护(Security)
    • 限流:QPS / 并发;参数 / API / App 级别
    • 黑白名单:一般基于 IP(包括 CIDR 段)
    • 请求防重放、防篡改、跨域策略(CORS)配置
    • 攻击检测与防护:DDoS防护、CSRF防护
  • 容错/韧性(Resilience)
    • 超时:连接超时 / 写超时 / 读超时
    • 重试:重试策略配置:
      • 触发条件,e.g. non-200、GET请求、超时报错
      • 重试次数
      • 重试间隔
    • 熔断/降级:
      • 降级策略:直接报错 / fallback路由
  • 请求校验(Request Verification)
    • 校验类型;是否必填;数值范围
    • 描述方式:可视化配置;JSON Schema
  • 请求转换(Request Transformation)
    • 路径重写(Path Rewrite)
    • 参数映射:e.g. HTTP method/host/uri/header/body
  • 响应生成(Response Generation)
    • 响应 Mock:固定内容;动态规则
    • 响应缓存:缓存策略配置 -
      • method:一般是GET
      • code:e.g. 200
      • TTL
    • 静态响应:直接返回本地文件资源,e.g. HTML、JS/CSS、图片
  • 响应转换(Response Transformation)
    • 压缩(如GZip)
    • 参数映射:e.g. HTTP header/body/status code;业务错误码
  • 扩展能力(Extensions)
    • 插件机制
    • 扩展点:上下游协议、LB算法、路由规则、请求处理、响应处理
      • 场景:认证鉴权、安全过滤、可观测性、协议支持
      • 内置功能也尽量用插件实现
    • 动态插件:支持运行时动态加载和执行插件
    • 多语言:Java、Go、Lua、Wasm
    • 插件编排:"低代码 API 网关"
  • 可观测性(Observability)
    • 日志:SLS;访问日志、错误日志
    • 监控报警:指标:RPS/RT/错误率;仪表盘;Prometheus / Skywalking
    • 分布式追踪:入口处注入全链路 TraceID
    • APM:性能
  • 数据分析(Analytics)
    • API调用量
    • 统计报表:RT、错误率
  • API 管理(API Manangement)
    • 管理方式:配置文件;API;GUI界面;
    • 热更新能力:配置、插件更新;对长连接更友好,不会引起连接中断
    • API 设计:定义、分组、模型管理(JSON Schema / Swagger Model),生成SDK时也会用到
    • API 编排:如 BFF 场景
    • API 发布:上线、下线;回滚;灰度;环境管理(包括环境变量);版本管理;证书管理(证书轮转、透明更新、通配符证书支持)
    • API 测试:调试、mock
    • SDK 生成:多语言
    • API 文档
  • 集成能力(Integrations)
    • K8s 集成:支持以 K8s 原生(基于 CR 声明式配置、云信息存储在 etcd)的方式来管理网关
      • K8s Ingress Controller
      • K8s Gateway API(Ingress V2)
    • Istio 集成
      • Istio Gateway
    • 认证和鉴权集成
      • e.g. 开源 Keycloak 集成;商业 IAM 集成(如 Okta)
  • 部署选项(Deployment Options)
    • Embedded
    • Docker
    • Helm
    • Operator
  • API 生态(API EcoSystems)
    • 开发者门户
    • API 目录

开源项目

Java 原生网关

Zuul

项目地址:https://github.com/Netflix/zuul

  • 简介
    • Netflix 开源的 API 网关
  • 功能
    • 协议支持(注:一个实例只支持同时配置一种协议;根据"SERVER_TYPE"配置)
      • HTTP/1:假定前置的SLB已卸载TLS
      • HTTP/2 (requires TLS):前置SLB使用TCP(可能不支持HTTP/2);需要配置SSL证书和开启代理协议(考虑到XFF头)
      • HTTP - Mutual TLS:同上 + 还需要配置一个 trust store,用于存储客户端证书
      • WebSocket / SSE
      • gRPC
    • 服务发现
      • Eureka / 静态服务器列表 / 其他服务发现机制
      • Eureka与Ribbon客户端天然集成
    • 负载均衡
      • 基于Ribbon提供的 ZoneAwareLoadBalancer (对AZ感知)
    • 消息推送
      • 支持两种协议:WebSockets、Server Sent Events (SSE)
      • 连接认证:每个入连接都必须认证;实现 PushAuthHandler
      • 客户端端注册和查找:默认基于内存;如果集群部署,支持第二级的全局存储,e.g. Redis, Cassandra, Amazon DynamoDB
      • 解决连接被LB关闭问题:最新版的7层代理 or 4层TCP代理;增加LB的IDLE超时
    • 其他特性
      • 状态码类别:比HTTP状态码更细
      • 请求通行证:请求经历的各个时间节点
      • 请求尝试:记录发出的各个请求
      • 静态请求响应:直接在边缘返回,无需转发到内部集群
      • 多区域韧性(Multiregion Resiliency)
      • 压力测试支持
  • 架构
    • 2.0 版本(基于 Netty):https://github.com/Netflix/zuul/wiki/How-It-Works-2.0
      • pre-filters (inbound filters):认证、路由、装饰请求等
      • endpoint-filter:返回静态请求 or 默认的 ProxyEndpoint
      • post-filters (outbound filters):metrics、装饰响应等
    • 1.0 版本(基于 Servlet)
  • 参考

Spring Cloud Gateway

项目地址:https://github.com/spring-cloud/spring-cloud-gateway

  • 简介
    • 作为 Spring Cloud 生态系统中的网关,目标是替代 Zuul
    • 比 Zuul 2 更早使用 Netty 实现异步 IO
  • 概念
    • Route(路由):由ID、目标URI、一组谓词和过滤器组成;当谓词为真时,路由被匹配
    • Predicate(谓词):Java 8 Function Predicate;基于HTTP请求的任意内容匹配
    • Filter(过滤器):可以修改请求和响应
  • 功能
    • Route Predicate Factories:路由规则配置(参考文章
    • Route Filter35+ filters):对某个路由下的请求/响应进行修改
      • 熔断 - CircuitBreaker:基于 Resilience4J
      • 限速 - RequestRateLimiter:基于 KeyResolver 实现可插拔的策略;支持Redis实现
      • 重试 - Retry:默认针对GET/5xx/IO异常/超时异常,重试3次 & 不指数回退
      • 重写路径 - RewritePath:支持正则表达式替换
      • 添加头部 - SecureHeaders:添加一些推荐的安全头部
      • 修改请求/响应体 - ModifyRequestBody / ModifyResponseBody:只能用Java DSL来配置
      • 修改响应体中的字段 - RemoveJsonAttributesResponseBody
      • OAuth传递 - Token Relay:转发 OAuth2 token 到下游服务
      • 请求体缓存 - CacheRequestBody:用于需要读取多次body的场景
      • GRPC协议转换 - JSONToGRPCFilter:需要输入 proto文件、service/method名
    • Global Filter:按条件应用到全部的路由
      • 外部路由 - NettyRouting / NettyWriteRespone:实际转发请求和返回响应的filter
      • 内部路由 - ForwardRoutingFilter:根据URI模式,转发给 DispatcherHandler
      • 负载均衡 - ReactiveLoadBalancerClientFilter:基于 ReactorLoadBalancer 进行负载均衡
      • WebSocket路由 - WebsocketRoutingFilterr:基于 Spring Websocket 转发 webscoket 请求
      • Metrics监控 - Gateway Metrics:基于 Spring Actuator;可与 prometheus/grafana 集成
    • HttpHeaders Filter:在 NettyRoutingFilter 转发请求之前应用生效
      • HTTP头部处理:Forwarded、RemoveHopByHop、XForwarded
    • 配置:基于 RouteDefinitionLocator;默认从Spring配置文件加载,可改为基于DB等外部数据源加载
      • Route Metadata:为路由增加额外参数;可在 exchange 对象中获取到
      • HTTP超时配置:全局、按路由
      • 基于 Spring Cloud DiscoveryClient 自动创建路由:默认规则、自定义
      • 多实例共享路由:基于 RedisRouteDefinitionRepository
    • 管控:基于Actuator
      • 能力:路由缓存刷新;路由创建和删除
  • 架构
  • 参考

ShenYu

项目地址:https://github.com/apache/shenyu

  • 简介
    • 一个异步的,高性能的,跨语言的,响应式的 API 网关;国产的 Apache 基金会项目
  • 功能
    • 前端协议:WebSocket、MQTT
    • 后端协议:Dubbo、gRPC、TARS、SOFA
    • API治理:Hystrix、RateLimiter插件(Lua Token Bucket 算法)、Sentinel
    • 仪表板:动态流量控制,用户菜单权限的可视化后端
    • 扩展:插件热插拔,动态加载
    • 服务注册:提供.NET,Python,Go,Java客户端用于API注册

Go 原生网关

Traefik

项目地址:https://github.com/traefik/traefik

  • 简介
    • 一个现代 HTTP 反向代理和负载均衡器,可以轻松部署微服务
    • GitHub Stars:47 K

Tyk

项目地址:https://github.com/TykTechnologies/tyk

简介

  • 一个云原生 API 网关,支持 REST, GraphQL, TCP 和 gRPC 协议
  • 自称为全球性能最快的网关

Lura

项目地址:https://github.com/luraproject/lura

  • 简介
    • 支持中间件的超高性能 API 网关; Linux 基金会托管的项目
    • 前身为 KrakenD framework,是 KrakenD API 网关的核心服务

Easegress

项目地址:https://github.com/easegress-io/easegress

  • 简介
    • 一个云原生流量编排系统
    • 不仅仅只是一个 7 层的 API Gateway,也可以是一个 Service Mesh 的 Sidecar

Nginx 衍生网关

Kong

项目地址:https://github.com/kong/kong

  • 简介
    • 云原生、平台无关、可扩展的 API 网关,具备高性能和插件可扩展性
    • 「据说是」生产环境使用最广泛的 API 网关
    • 背后有一个商业公司(成立于 2009 年,2015年开源),提供托管版网关和相关服务
  • 概念
    • Services:表示一个外部的上游API或微服务;需指定URL
      • 多个Route可指向同一个Service,并挂载不同Policy(e.g. 区分内外访问限速)
    • Routes:确定一个请求如何(或是否)发送到对应的Services;支持重写URL
    • Upstreams:表示一个虚拟的主机名,可用于健康检查、断路器、多服务负载均衡
      • Service可以指向一个Upstream(而不是写死host)
    • Plugins:提供高级功能 + 扩展网关能力;
    • Consumer:向Kong发起请求的实体;代表一个用户或外部服务
    • Creadential:consumer关联的API key
  • 插件
  • 架构
    • 基于 OpenResty(a Lua application running in NGINX)
    • 元数据存储:PostgreSQL / Cassandra(已废弃)
    • 集群架构:Gossip 协议;依赖前置LB做负载均衡
    • 支持混合(DP / CP 分离)模式部署
  • 参考

APISIX

项目地址:https://github.com/apache/apisix

3scale

项目地址:https://github.com/3scale/apicast

Envoy 衍生网关

Gloo

项目地址:https://github.com/solo-io/gloo

Higress

项目地址:https://github.com/alibaba/higress

  • 简介
    • 基于阿里内部两年多的 Envoy Gateway 实践沉淀,以开源 Istio 与 Envoy 为核心构建的下一代云原生网关。
    • 实现了安全防护网关、流量网关、微服务网关三层网关合一,可以显著降低网关的部署和运维成本。
  • vs. Nginx
    • gRPC 支持更完善
    • Reload 访问无损
      • Nginx:reload 会引起长连接抖动,导致流量短暂中断
      • Envoy:通过 xDS 支持配置热更新;秒级生效、业务无感知
    • 性能可接受:比 Nginx 差,但在同一个量级上
    • 统一技术栈:与 Service Mesh 整合,同时调度 南北向外部流量 和 东西向内部流量
  • 功能
    • 扩展能力
      • 多语言插件:WASM / Lua / 进程外 (跟 Envoy 一致?)
      • 自带插件:WAF防护、多K8s集群、多注册中心、灰度
      • 生效粒度:全局级、域名级,路由级
    • 生态集成
      • Nacos / ZooKeeper / Consul 服务发现
      • Sentinel 限流
      • Skywalking / Prometheus 监控
      • OpenTelemetry 追踪
      • 支持 OpenKruise(阿里开源的K8s扩展组件) 灰度发布
  • 参考

Contour

项目地址:https://github.com/projectcontour/contour

  • 简介
    • 一个 Kubernetes Ingress,为 Envoy 边缘和服务代理提供控制平面

Emissary

项目地址:https://github.com/emissary-ingress/emissary

  • 简介
    • 基于 Envoy Proxy 构建的开源 Kubernetes 原生 API 网关 + 第 7 层负载均衡器 + Kubernetes Ingress;CNCF 孵化项目
    • 最早的名字是 Ambassador API Gateway

选型对比

商业产品

相关资源

AWS API Gateway

官网:https://aws.amazon.com/api-gateway/

Google Apigee

官网:https://cloud.google.com/apigee

除了 Apigee,Google Cloud 自身也有一些网关产品:

Azure API Management

官网:https://azure.microsoft.com/en-us/products/api-management

  • 简介
    • 微软 Azure 上的一个混合多云 API 管理平台,适用于所有环境中的 API;支持完整的 API 生命周期。
    • 由 API 网关、管理平面和开发者门户组成
    • 属于 Azure Integration Services 的一部分
  • 特性
    • 混合多云部署:可与 Azure、其他云和本地托管的 API 并行部署
  • 参考

MuleSoft Anypoint Platform

官网:https://www.mulesoft.com/platform/anypoint-platform-features

  • 简介
    • MuleSoft 是 iPaaS 领域的 Leader 之一(已被 SalesForce 于 2018 年收购),其 Anypoint Platform 由一系列子产品组成,共同提供了 API 管理 + 企业集成能力
  • 特性
    • 支持 多种 API 规范:RAML, OAS, AsyncAPI, GraphQL
    • Anypoint Mule Gateway:在 Mule Runtime 引擎中包含的嵌入式 API 网关
    • Anypoint Flex Gateway:可独立部署的、基于 Envoy 的轻量级 API 网关
    • Anypoint API Manager:API 安全策略、访问控制;将多个API组合为产品
    • Anypoint API Designer:支持可视化或代码编辑;设计、文档、测试、mock
    • Anypoint API Governance:API 治理 - 确保标准质量和安全合规,减少评审开销
    • Anypoint API Community Manager:基于自带的主题,快速构建门户;个性化API消费需求;自动填充交互式的文档
    • Anypoint Catalog CLI:发现、归类 API,包括关联的元数据和文档
    • Anypoint DataGraph:基于 GraphQL API;统一 schema 管理
    • Anypoint Exchange:API 和集成资产分享
  • 参考

Kong 商业版

官网:https://konghq.com/

  • 简介
    • 成立于 2009 年,2015年开源了核心的 Gateway 组件(见上文介绍)
  • 版本
    • 开源版本、免费版本(+ Manager)、Plus版本(+ 额外插件)、Enterprise版本(+ Dev Portal、Vitals、RBAC、企业插件)
  • 特性
    • Kong Gateway
      • Kong Admin API:REST风格管理接口;单端的端口暴露(默认8001)
      • Kong Manager:GUI界面;底层基于 Admin API;dashboard支持
      • Kong Vitals:提供节点的健康状态、性能监控、API 使用情况的 metrics
    • Kong AI Gateway:Multi-LLM AI Gateway to run, secure, and govern AI traffic
    • Konnect:API全生命周期管理平台
      • 管控平面由 Kong 在云端提供,运行时引擎/数据平面(Gateway)由用户在自己的环境里管理
      • Service Hub:让内部API 可发现、可消费、可复用;服务目录/仓库,加速开发
        • 管理员可以将服务从 Service Hub 直接发布到 Dev Portal,让开发者可以去搜索、发现和消费
      • Runtime Manager:管理运行时和服务;可以创建多个控制面(基于 Runtime Group),彼此配置隔离;插件安装
      • Dev Portal:可定制的开发者门户;让开发者浏览API、查看API文档、测试API、管理他们自己的API访问凭证;可以减轻API创建者的负担,让API使用者自助管理凭证
      • Analytics:健康状态/性能监控;服务、路由、应用
    • Kong Plugin Hub:通过 Manager 或 Admin API 来开启
    • Kong Ingress Controller:配套 helm chart + operator
    • Insomnia:基于 spec 的 REST / GraphQL 服务开发;类似Postman;自动化测试、Git 同步
    • decK:声明式配置支持;YAML格式
  • 部署选项
    • 混合部署:控制面(CP)/ 数据面(DP) 分离,降低攻击面
      • 运行的bin程序都一样,通过 KONG_ROLE 切换角色
      • 数据面(网关实例) vs. 管控面(Runtime Manager)
        • 数据面可以部署在任意环境,包括公共云/本地机房、K8s/VM
        • 连接方式:数据面主动向管控面发起建连请求;双向TLS握手;长连接+心跳+自动重连
        • 传输数据:配置、遥测数据(统计/计费)
        • 故障隔离:管控面挂了,不影响数据面;数据面本地有配置缓存文件,重启也不影响
    • 传统(数据库)模式:PostgreSQL 10+ / Cassandra 3.11.x
      • 部分插件依赖数据库模式,e.g. 限速(集群策略)、OAuth2
      • 缺点:网关节点既是DP也是CP,安全风险更高;使用Mangager时,性能更差
    • 无数据库模式:配置存储在节点内存中,通过声明式配置文件提供
      • 此模式下,Admin API 是只读的
      • K8s部署时(基于K8s Ingress Controller),配置持久化存储在etcd中
  • 三方组件

阿里云 API 网关

官网:https://www.aliyun.com/product/apigateway

  • 简介
  • 特性
    • API 全生命周期管理:设计、开发、测试、发布、售卖、运维监测、安全管控、下线
    • 集成能力:与阿里云多款云产品深度集成 - 数据服务总线;AI能力输出;数据大屏
    • 插件机制:插件策略和API分别是独立管理的;插件的绑定、解绑、更新会实时生效,不需要重新发布API
  • 参考

阿里云 MSE 云原生网关

官网:https://www.aliyun.com/product/aliware/mse

标准规范

Kubernetes Ingress

Link: https://kubernetes.io/docs/concepts/services-networking/ingress/

  • 定义:一个API对象,用于管理外部用户访问运行在 Kubernetes 集群中的服务
    • 路由规则(rules):只支持路由 HTTP(S) 流量
    • 配置项:host(可选)、paths、backend(service + port)
  • 实现Ingress Controllers,其中官方支持的有以下三个
    • AWS Load Balancer Controller:通过 ALB支持 Ingress,通过 NLB 支持Service
    • Ingress NGINX Controller
    • GCE L7 load balancer controller(GLBC)

K8s Gateway API

Link: https://gateway-api.sigs.k8s.io/

Istio Gateway

Link: https://istio.io/latest/docs/reference/config/networking/gateway/

  • 定义:描述了在 Mesh 边缘运行的负载均衡器,用于接收传入或传出的 HTTP/TCP 连接。该规范描述了应暴露的端口集、使用的协议类型、负载平衡器的 SNI 配置等。

FAQ

1. API 网关」 跟传统的「反向代理(Reverse proxy)」 和 「负载均衡器(Load Balancer)」,有什么区别?

API 网关 = 反向代理 + 负载均衡器 + 更多偏上层的能力与职责(例如:多个后端服务代理、跨服务的聚合请求、认证鉴权、协议转换、API 版本管理 等)。在实际的部署架构中,很多 API 网关虽然内置了反向代理和负载均衡能力,但出于性能、可扩展性和职责分离等角度考虑,往往会前置部署一个 4 层负载均衡,甚至再加一个 7 层反向代理。

例如,在《Using Zuul in production》一文介绍的 Zuul 生产部署案例中,每个 Zuul 实例都前置部署了一个 Nginx 反向代理,负责静态资源缓存、TLS 终止、连接保持、Gzip 压缩等任务;同时,Zuul 集群前面还有一层 HAProxy,用于在多个 Zuul 节点之间实现 4 层负载均衡。

2.「API 网关」跟「服务网格(Service Mesh)」,又有什么联系和区别呢?

《相爱相杀:Servicemesh和API Gateway关系深度探讨 》这篇文章对两者关系做了深入探讨,总结一下就是:

  • API网关:负责 南北向流量(North-South Traffic),即 对外提供服务访问
    • 典型API网关是负责处理入流量(Ingress);少数场景也会用于管理出流量(Egress
    • API网关不只是面向纯粹的外部访问,也可以面向内部的二方服务端调用
  • 服务网格:负责 东西向流量(East-West Traffic),即 服务间的相互访问(Service-to-Service)
    • 由于服务网格底层所使用的服务代理(Service Proxy)软件提供的功能与与 API 网关很相似,因此业界也经常将其用于 API 网关场景,例如 Envoy Gateway

结语

内容持续更新中... 可点击左侧「👍🏻」按钮,获得更新加速体验。