让CDN承担流量清洗和静态分发、让API网关专注路由与鉴权，二者按“流量分层”协同，多数场景下能降低后端70%以上无效请求压力。这不是把两个组件串起来那么简单，而是把请求按“能不能缓存、要不要鉴权、是否动态”拆成三条路径，各司其职，下面直接拆解配合逻辑、配置方法和选型对比。
API网关和CDN怎么配合才不白花钱
很多团队把CDN挂在API网关前面,结果发现命中率极低，后端压力没降多少，问题出在没做流量分类，API请求里有相当一部分是重复读操作，比如商品详情、库存查询、配置拉取，这些响应体基本不变，完全可以让CDN直接返回。
先分清三层流量
- 静态资源层：图片、JS/CSS、字体文件，CDN全权处理，根本不回源。
- 可缓存动态层：带固定参数的GET请求，响应头加上
Cache-Control: max-age，CDN按规则缓存。 - 纯动态层：登录、下单、支付，CDN直接透传给API网关，不缓存。
行业共识认为,多数互联网应用的读接口占比超过写接口，把第二层流量从后端剥离，压降效果立刻显现，具体做法是在API网关的响应头里统一注入缓存标记，让CDN识别哪些响应能存、存多久。
按路径配置回源策略
CDN回源地址不要直接指向后端服务器,而是指向API网关的独立域名，这样CDN只认网关这一个入口，网关做鉴权和限流，后端服务器被完全屏蔽，配置时注意三点：
- CDN回源Host设置为API网关专属域名,不要用默认源站IP。
- 在API网关里单独给CDN回源IP段开白名单,防止绕过CDN直接攻击网关。
- 对CDN回源请求做UA识别,避免CDN缓存刷新时流量风暴压垮网关。
API网关与CDN的区别与选型
两者职责边界清晰：CDN管“近”和“快”，把内容推到离用户最近的地方；API网关管“通”和“安”，控制请求能不能进来、发给谁，选型时先看业务类型再看成本。
场景侧重点对比型，比如资讯站、视频列表、电商商品页，CDN投入产出比极高，如果业务是交易型，比如支付、订单、优惠券核销，API网关的稳定性比CDN更重要，分不清的时候做个简单测试：统计一周的请求日志，计算读请求和写请求的比例，读请求超过70%就值得深挖CDN缓存。
| 维度 | CDN优先 | API网关优先 |
|---|---|---|
| 请求类型 | 大量GET读请求 | POST/PUT写请求多 |
| 响应特点 | 响应体变化小 | 强动态、强个性化 |
| 安全需求 | 防DDoS、防刷 | 鉴权、限流、灰度 |
| 成本敏感度 | 流量带宽成本高 | 实例规格成本高 |
价格与部署形态参考
云厂商的CDN计费主要按流量或请求次数,API网关按调用量或实例规格，小流量阶段直接选按量付费，日均请求过百万再考虑包年包月，开源方案上，API网关可以选Kong或者APISIX，CDN自建不划算，直接用云厂商的即可，国内场景下，简米云CDN加云原生API网关组合最常见，海外业务选Cloudflare加Kong的也不少。
降低后端压力的三层防护策略
配合不是把两个产品接上线就完事,要针对不同攻击和数据特征设三层防线。
第一层：CDN边缘拦截
- 在CDN控制台开启高频访问限频,单IP每秒超过阈值直接返回403。
- 配置URL鉴权,防止CDN防盗链，带签名的请求才能命中缓存。
- 开启WEB攻击防护,SQL注入、XSS等恶意请求在边缘就被过滤掉，根本到不了API网关。
第二层：API网关流量治理
- 设置单客户端IP的每秒请求数阈值，超过直接拒绝，配合CDN的限频双保险。
- 配置优雅降级，当后端服务响应超时比例超过设定值，网关直接返回降级数据，不再透传请求。
- 开启缓存插件，APISIX等网关自带
proxy-cache，热点key的读请求在网关层再缓存一遍，CDN没命中的二次重复请求由网关兜底。
第三层：后端服务自我保护
后端接口统一加熔断器，比如Sentinel或Resilience4j，当错误率超过阈值，熔断器打开，请求快速失败，不再占用线程池，同时给数据库连接池设置最大等待时间，防止线程堆积拖垮整个服务。
实际配置步骤与验证方法
拿一个典型的电商详情页场景举例,后端是Spring Boot服务，前端需要商品信息、库存、评价三个接口。
第一步：改造接口响应头
Spring Boot的Controller里统一加响应头，凡是不带用户维度的数据都声明可缓存：
response.setHeader("Cache-Control", "public, max-age=300");
response.setHeader("CDN-Cache-Control", "max-age=300");带用户ID的参数不设置该头,CDN自动不缓存这类响应。
第二步：配置CDN缓存规则
在CDN控制台新增缓存配置：
- 路径：
/api/product/，缓存时长5分钟，优先级最高。 - 路径：
/api/order/，不缓存，直接回源。 - 路径：
/static/，缓存30天。
第三步：验证缓存生效
用curl带-H "X-Forwarded-For: 1.2.3.4"模拟不同用户访问同一个商品接口，观察响应头，出现X-Cache: HIT说明CDN命中，X-Cache: MISS说明回源了，同时在后端日志里统计一段时间内的实际请求数，对比CDN的命中日志，就知道后端压力降了多少。
API网关缓存与CDN缓存的边界划分
很多团队容易搞混：既然API网关也能缓存，为什么还要CDN？答案是距离，CDN的节点在用户附近，网关的节点在数据中心，用户访问CDN命中，网络延迟是10-30毫秒；回源到网关再命中缓存，延迟可能变成50-100毫秒，延迟差一个数量级，体验完全不同。
什么情况放网关缓存
- 需要做用户维度鉴权的响应，比如购物车、个性化推荐。
- CDN节点分布但源站在特定地域,回源延迟已经很高，网关缓存能省掉后端计算。
- 动态接口的TTL很短,比如几秒钟，CDN缓存刷新频繁，不如网关缓存更精细。
什么情况放CDN缓存
- 完全公开的内容,无鉴权要求。
- 响应体较大,比如图片处理结果、PDF文件。
- 需要跨区域加速,用户在上海、源站在北京，CDN能让上海用户就近读取。
两者配合时,CDN缓存的TTL应该比网关缓存TTL短，因为CDN命中后不会回源，网关根本收不到请求；如果CDN的TTL长于网关，用户在网关缓存失效后依然会从CDN拿到旧数据。
CDN与API网关协同常见问题排查
配合过程中最常遇到的坑有三个。
缓存击穿
某个热点key突然失效,大量请求同时回源打到API网关和后端，解决方式是在API网关层加单飞逻辑，同一时刻只有一个请求去后端取数据，其他请求等待结果复用，APISIX的proxy-cache插件结合lua-resty-lock可以实现。
缓存雪崩
大量key在同一时间失效,导致回源压力集中，解决方式是在API网关统一生成缓存key时加上随机偏移量：
key = md5(uri + params + (timestamp / 300))300秒的时间窗口内,不同请求的key分散到不同时间段失效。
回源链路超时
CDN回源到API网关时,TCP连接建立缓慢，导致用户侧看到502，业内专家指出，CDN的回源超时配置需要根据网络链路质量调整，默认超时5秒，跨地域回源建议放大到10秒，同时在API网关侧开启TCP快速重传，减少丢包重传等待时间。
常见问题解答
用了CDN之后API网关还有必要做限流吗？
有必要,CDN只能限制单一IP的请求频率，无法识别分布式攻击，多个攻击IP分散请求到不同CDN节点，最后都汇聚到API网关上，网关的全局限流才能识别整体流量异常。网关限流是最后一道防线，CDN限频是第一道防线，二者不能互相替代。
价格方面，API网关和CDN哪个成本更高？
取决于流量结构,如果请求体小、QPS高、带宽消耗低，CDN费用往往低于API网关费用，如果响应体大，比如图片视频，CDN流量费用会明显上升，国内主流云厂商的CDN流量单价约为每GB2-0.5元，API网关按百万次调用计费约为5-2元，实际采购前先拉取三个月的请求日志，分别统计流量和调用量，再导入价格计算器算总账。
API网关和CDN的组合方案如何选型？
中小团队直接买云厂商的托管服务,简米云或酷番云的CDN搭配各自的API网关，同厂商内网回源不占用公网流量，延迟更低，大团队对流控精确度要求高，选择开源APISIX或Kong自建网关，搭配Cloudflare或者国内云CDN，灵活度更高但运维复杂度明显上升，据工信部数据，国内公有云API网关市场近两年增长较快，托管方案稳定性已相当成熟，小团队不必自建。