第1章 API网关概述

一、API网关概述：什么是API网关、为什么需要API网关、API网关在PaaS中的定位

好，咱们直接进入正题。API网关这个词，这几年在云原生圈子里几乎成了标配。但说实话，很多人对它的理解还停留在「反向代理」或者「负载均衡」的层面。我个人觉得，这有点可惜。

API网关，说白了就是系统对外的「总入口」。你想想看，微服务架构下，后端可能有几十上百个服务。每个服务都有自己的地址、端口、认证方式。如果让客户端直接去调用这些服务，那场面得多混乱？

API网关就是来解决这个问题的。它站在客户端和后端服务之间，统一接收所有请求，然后根据路由规则转发到对应的服务上。

我习惯这样定义：API网关是一个位于客户端和后端服务之间的中间层。它负责请求路由、协议转换、安全认证、流量控制等一系列横切关注点。

举个例子，你做一个电商平台。用户下单、查询商品、支付，这些功能可能分属不同的微服务。没有网关的时候，客户端得知道每个服务的具体地址。有了网关，客户端只需要知道网关的地址就行。

核心职责：

我在项目中遇到过一种情况：团队把认证逻辑分散在各个服务里，结果每次改认证策略都要改十几个服务。后来上了网关，把认证统一收敛到网关层，维护成本直接降了一半。嗯，这就是网关的价值。

你可能会问：没有网关行不行？当然行。小项目、单体应用，确实不需要。但一旦服务数量超过5个，或者你需要对外提供API，网关就成了刚需。

我总结了几点核心原因：

解耦客户端与后端：客户端不需要知道后端有多少个服务，也不需要关心服务地址变了。网关帮你屏蔽了这些细节。
统一安全策略：认证、鉴权、防SQL注入、防XSS攻击，这些安全措施在网关层统一处理，比分散在各个服务里靠谱得多。
流量管控：限流、熔断、降级，这些能力在网关层实现，可以保护后端服务不被突发流量冲垮。我曾经见过一个案例，双十一大促时因为没有限流，订单服务直接被压垮，导致整个系统瘫痪了半小时。
协议适配：老系统可能用的是SOAP协议，新系统是RESTful。网关可以在中间做协议转换，让新旧系统平滑对接。
观测性：所有请求都经过网关，日志、监控、链路追踪自然就统一了。排查问题的时候，你只需要看网关的日志就够了。

避坑指南：我曾经犯过一个错误——把业务逻辑也塞进网关里。比如在网关层做数据聚合、字段转换。结果网关变得越来越重，成了单点瓶颈。记住，网关只做横切关注点，不要掺和业务逻辑。

PaaS平台，说白了就是给开发者提供「开箱即用」的运行环境。你不需要关心服务器、网络、存储这些基础设施，只需要把代码部署上去就行。

那API网关在PaaS里扮演什么角色？我把它比作「PaaS平台的守门员」。

PaaS能力	API网关的作用
服务注册与发现	网关动态感知后端服务的变化，自动更新路由
弹性伸缩	网关配合负载均衡，把流量分发到新扩的实例上
多租户隔离	网关根据租户ID做路由隔离，防止租户间互相影响
灰度发布	网关根据Header或Cookie，把部分流量引到新版本
安全合规	网关统一做IP白名单、访问频率控制、数据脱敏

在PaaS架构里，API网关通常部署在集群的边缘层。它和Kubernetes的Ingress Controller配合使用，一个负责南北向流量（外部到内部），一个负责东西向流量（服务到服务）。

我记得有一次帮客户做PaaS平台迁移，他们原来的网关是Nginx手动配置的，每次加服务都要改配置文件然后重启。迁移到Kubernetes + API网关后，服务上线自动注册，网关自动感知，再也不用半夜爬起来改配置了。

注意：API网关不是万能的。它解决的是「入口统一」的问题，但服务间的调用（东西向流量）如果也走网关，会增加延迟。我建议南北向流量走网关，东西向流量用Service Mesh来处理。

总结一下：API网关在PaaS中的定位，就是「统一入口、安全防护、流量管控、协议适配」。它让PaaS平台更健壮、更安全、更易维护。你想想看，如果没有网关，每个服务都要自己处理认证、限流、日志，那得多累？

好，这一章就到这里。下一章我们聊聊API网关的核心功能——路由与负载均衡，我会结合Kong和APISIX的实际配置来讲解。