后端服务一多，每个接口都要重复写身份校验、限流、日志和跨域处理。服务少的时候还能应付，接口一多，改一处就得改十几处，维护成本涨得很快。API网关把这些通用逻辑放到一个入口统一处理，业务服务只管自己的业务。阿里云API网关就是云上托管的这类服务。这篇文章用一个改造案例说明它能做什么，以及配认证和限流时要留意哪些地方。
阿里云API网关是什么
阿里云API网关部署在客户端和后端服务之间。请求先到网关，校验通过后再转发给后端。后端可以是ECS上的HTTP服务、VPC内网的服务、函数计算的函数，也可以是其他云上的服务。网关的扩容、高可用和证书更新由平台负责，团队不用自己搭建和维护这套基础设施。
使用流程一般分三步：创建分组，定义API并绑定后端，然后发布到环境。分组可以理解为挂在同一个域名下的一批接口。环境通常有测试、预发和线上三个。比较稳妥的做法是先在测试环境把认证和限流跑通，确认符合预期，再发布到线上。这样即使配置写错，影响也只在测试里。
核心能力
- 身份认证：支持AppCode、签名认证（AppKey和AppSecret）等方式。服务端之间调用时，签名认证更合适。AppSecret只保存在调用方的服务端配置里，不能放进前端代码。
- 流量控制：可以按接口、按应用或按用户设置QPS上限。超出的请求直接返回限流响应，后端不会被突发流量冲垮。
- 访问控制：支持IP黑白名单。异常来源可以加入黑名单，内部接口可以只对办公网段开放。
- 协议与请求转换：在网关层做参数映射、增删请求头。前端的调用方式和后端接口对不上时，可以在网关层转换，不必为了适配而改后端代码。
- 监控与日志：调用量、响应时间、错误率可以接入云监控，访问日志可以投递到日志服务。出问题时先看这些数据，能较快缩小排查范围。
案例：移动端订单接口统一接入
某团队的移动端应用要调用十几个微服务，包括商品、订单、优惠券和用户服务。早期每个服务各自实现Token校验，限流靠服务内的简单计数器。各服务的实现标准不一致，做安全审计时很难给出统一结论。这也是团队决定引入网关的直接原因。
改造思路
团队把对外接口统一迁移到阿里云API网关，按业务域划分为四个分组。认证交给网关处理，后端服务只接收已经校验过的请求。限流则按接口分别配置。下单接口的QPS上限低于商品查询接口，原因很直接：下单会扣减库存，突发流量打进来的代价远大于查询。
实施过程
- 先在测试环境给订单接口配置签名认证，用一个测试应用验证签名算法和时间戳校验是否正常。
- 删除服务里原有的Token校验逻辑之前，先让网关上线，同时保留旧逻辑。观察两周，确认网关的拦截记录和服务日志对得上。两边一致，才能放心拆掉旧代码。
- 按分组逐个切换流量。每切换一个，都看一下错误率和响应时间，有异常就先暂停。
- 给下单接口设置告警。错误率超过阈值时通知值班人员，不要等问题积累到第二天才发现。
效果
迁移完成后，认证逻辑从十几处收拢到一处。新增接口只需要在网关上配置认证方式，不用再改每个服务的代码。一次促销活动中，商品查询的流量明显上涨，网关的限流规则挡住了超出的部分，订单服务的响应时间保持平稳。团队的经验是，限流阈值不能只看平时流量，压测结果和历史峰值都要拿来参考，否则促销一来，阈值很快就失真。
配置时的注意事项
- 先分清环境：测试和线上使用不同的分组或域名，测试配置不容易被误发到线上。
- 密钥管理：AppSecret不要写进客户端代码，也不要提交到代码仓库。轮换时保留新旧密钥并行的过渡期，调用方有时间切换，不会因为换密钥而一下子全部失败。
- 超时设置：网关的后端超时要略小于调用方的超时。如果调用方先超时，网关还在等后端返回，连接和资源就白白占着。
- 后端隔离：如果后端服务的内网地址可以被直接访问，网关就等于白设。建议后端只允许网关所在的网段访问。
适合哪些场景
服务数量多、接口要开放给多个调用方、需要统一认证和限流策略时，阿里云API网关能明显降低维护成本。如果只有一两个内部接口，直接在服务内做校验可能更省事。选型前可以先列一下现在的问题：认证是否统一，有没有限流，调用量能不能统计。哪个问题最痛，就先用网关解决哪个。
网关的价值在于把通用能力从业务代码中拿出来。建议从小范围接口开始试点，验证没问题后再逐步迁移。
