API网关基础概念与作用

说起API网关,我脑子里第一反应是:它就像整个微服务架构的「总门卫」。

刚接触微服务那会儿,我总觉得网关是个可有可无的东西。直到有一次,线上服务直接暴露在外,安全策略散落在各个业务代码里,改一次认证逻辑要通知五六个团队……那种混乱的感觉,我至今记得。

这一章,我们把API网关的基本功打扎实。你想想看,没有地基的房子,能住人吗?

API网关到底是什么?

说白了,API网关就是一个统一的入口。所有客户端请求——不管是手机App、网页还是第三方系统——都先打到网关这里,再由网关转发给背后的微服务。

我习惯把它比作机场的航站楼。旅客(请求)到航站楼,先过安检(认证鉴权),查登机牌(身份校验),去指定登机口(路由转发)。没有航站楼,每个航班都得自己处理安检,那不乱套了?

核心定义:API网关是位于客户端与后端服务之间的中间层,负责请求路由、协议转换、安全管控、流量治理等公共逻辑。

API网关的核心功能

网关不是简单转发。我整理了一张表,把最核心的几项功能列出来——这些也是后面章节会反复用到的。

功能模块 具体作用 我遇到过的场景
路由转发 根据请求路径、Header、参数,把请求分发到对应后端服务 版本路由、灰度发布时特别好用
认证鉴权 验证请求方身份,校验、、签名 统一OAuth2.0接入,不用每个服务写一遍
流量控制 限制单位时间内的请求次数,保护后端不被冲垮 双十一活动时,限流阈值调低了好几次
熔断降级 后端服务异常时,快速返回降级响应,避免雪崩 有一次依赖的支付服务挂了,网关直接返回"服务繁忙"
日志监控 统一记录请求日志,上报调用链数据 排查问题时,网关日志是第一个要看的
协议转换 HTTP转gRPC、WebSocket透传等 老旧系统用HTTP,新服务用gRPC,网关当翻译器

为什么需要API网关?

没有网关行不行?坦白说,小型单体应用确实可以不要。但一旦服务拆到10个以上,你马上就会撞上一堆问题。

  • 安全策略重复——每个服务都要写认证代码,漏一个就出漏洞
  • 流量管理混乱——突发流量直接把数据库打满,没人知道该限谁的流
  • 监控割裂——查一次请求要翻五个服务的日志,效率极低
  • 客户端耦合——后端接口改了,App也得跟着改版本

我建议你记住一个原则:网关做通用的事,服务做业务的事。这样一来,业务团队只关心代码逻辑,网关团队负责安全与稳定。职责清晰,事半功倍。

API网关的常见架构模式

网关的部署方式有几种。我用一张图来表达最常见的架构——这也是本课程实战部分的主线。

API网关核心功能结构图 API网关核心功能结构图 客户端 iOS / Android / Web API 网关 路由转发 认证鉴权 流量控制 日志监控 熔断降级 服务A 用户服务 服务B 订单服务 服务C 支付服务 说明: 所有客户端请求统一经过网关,网关完成路由、认证、限流、监控后,再分发到不同后端服务。

实战案例:从零理解网关

讲个真事。几年前我接手一个电商系统,那时候订单服务、支付服务、用户服务都各自维护一份校验代码。结果有个服务忘了更新密钥,线上直接暴露了用户数据。

后来我们把API网关架上去,做了这几件事:

  1. 统一认证——所有请求先过网关的JWT校验,不通过就直接拒绝
  2. 集中限流——对每个AppKey设置每秒500次的阈值,超了就返回429
  3. 路由隔离——/api/v1/* 走老服务,/api/v2/* 走新服务,平滑迁移

效果很明显——安全漏洞一次性堵住,流量峰值时后端再没有被打爆过。

特别注意:网关不是万能的。它本身也可能成为瓶颈。我曾经压测时发现网关单点QPS到不了1万,不得不分成多节点部署+前置负载均衡。记住:网关要设计成无状态的,方便水平扩展。

网关与反向代理的区别

有同学会问:Nginx不就是反向代理吗?跟API网关有什么区别?

对比维度 反向代理 API网关
核心能力 请求转发、负载均衡 转发 + 认证 + 限流 + 熔断 + 监控
协议支持 HTTP/HTTPS为主 HTTP/gRPC/WebSocket/TCP等
配置方式 静态配置文件 动态路由 + 管理控制台
扩展性 通过Lua/模块扩展 插件体系,开箱即用

你看,反向代理是「老黄牛」,只管转发。API网关是「总管家」,活更细、能力更全。实际项目中,我经常把Nginx放在网关前面做TLS卸载和基础负载,网关专注做业务策略。

我个人习惯的环境:Nginx(4层/7层转发)→ Kong/APISIX(API网关)→ 后端微服务。这套组合用了好几年,稳定且灵活。

网关注重什么?

最后聊几点价值观层面的东西。API网关承载了整个系统的入口流量,它的设计和运维,跟普通业务服务有本质区别。

  • 高可用是第一优先级——网关挂了,所有服务都不可用。我建议至少部署2节点,配上健康检查。
  • 变更要谨慎——路由规则、限流策略的改动,直接影响线上流量。最好有灰度验证机制。
  • 可观测性必须强——网关层的请求日志、延迟、错误码,是排查问题的一手数据。我见过不少团队只关注业务日志,忽略了网关日志,结果一出事两眼一抹黑。

嗯,这一章的内容到这里。API网关是后面所有课程的基础,你把它理解透了,后面学权限隔离和流量管控就会很顺畅。