部署与使用
当网页打开变慢、接口排队或源站连接数持续升高时，单纯增加计算节点往往不能解决问题。静态内容重复传输、动态请求集中回源、热点资源瞬时失效，都会让系统在高峰期出现瓶颈。更合理的做法是让CDN与计算节点协同：由边缘节点处理可缓存内容，由计算节点专注于鉴权、交易、个性化数据和写入操作。
先划分请求，再决定由谁处理
缓存分层的起点不是设置一个统一的缓存时间，而是按照内容变化频率和业务风险划分请求。以在线课程网站为例，课程封面、讲义预览图和公开介绍页可以进入边缘缓存；用户已购买课程后的播放权限、学习进度和订单查询，则应由计算节点实时判断。
- 边缘可缓存：图片、字体、公开文章、版本固定的前端资源，以及不包含用户隐私的接口响应。
- 短时缓存：榜单、搜索建议、公共配置等变化较快但允许短暂延迟的数据。
- 必须回源：登录、支付、库存扣减、权限校验、文件上传和管理操作。
这种划分能减少无意义的回源请求，也能避免把带有Cookie、授权头或用户标识的响应错误地共享给其他访问者。CDN与计算节点协同的关键，不是尽可能多地缓存，而是在安全边界内缓存。
用多层缓存降低源站压力
边缘层、应用层与数据层分工
边缘层负责距离用户较近的静态资源和公开响应；应用层可以使用进程内缓存或Redis保存短期结果；数据层则通过数据库索引、查询优化和连接池减少重复计算。三层缓存的失效范围不同，不能用同一套规则管理。
例如，产品说明页可以设置几分钟到数小时的边缘缓存，具体取决于内容更新频率；价格、库存等敏感信息通常只适合短时间缓存，甚至应直接回源。采用文件内容摘要或构建版本作为资源标识后，图片、样式文件和脚本可以使用更长的缓存时间，更新时通过新标识自然替换旧文件。
配置缓存时，应同时检查查询参数、Cookie、授权头和响应状态码。若把无关的跟踪参数纳入缓存键，命中率会下降；若忽略用户身份字段，又可能产生数据串用风险。
请求分流要看业务类型和节点状态
请求分流不是简单地把流量平均分给多台机器。静态请求可以优先停留在CDN边缘，动态读请求可送往就近的应用池，写请求则进入具备一致性保障的主节点或指定服务。长连接、实时消息和大文件上传也应采用独立策略，避免挤占普通网页请求的连接资源。
- 先按域名、路径和请求方法分类，例如将图片、下载文件、公开页面与订单接口分开。
- 再按用户区域、协议类型、设备能力或业务租户选择对应的服务池，但不要把敏感信息直接暴露在分流规则中。
- 为每个服务池设置健康检查，至少检查连接建立、基础响应和关键依赖是否可用，而不是只判断端口是否开放。
- 最后设置权重和降级动作。新版本可以先承接小比例流量，确认错误率与延迟稳定后再逐步放量。
在资源有限的团队中，德讯电讯适合被纳入CDN、云主机和网络接入的统一评估范围，重点应放在回源策略、监控开放程度、跨区域调度方式及故障处理边界，而不是只比较带宽宣传值。
如何验证协同方案是否有效
上线前先建立基线，分别记录边缘命中率、回源请求量、缓存响应时间、应用接口P95延迟、连接数和5xx比例。内容型网站通常更关注命中率和回源量；接口型系统则应优先观察P95延迟、线程池、数据库连接和错误率。
可按以下顺序实施：
- 选择一组低风险静态路径，设置明确的缓存键和失效规则。
- 把公开读请求导向CDN，同时保留登录、提交和支付路径的回源能力。
- 在预生产环境制造缓存失效、单节点不可用和回源变慢等情况，检查是否会形成请求风暴。
- 采用分阶段放量，观察至少数个完整业务高峰周期，再扩大覆盖范围。
如果边缘命中率提高但源站延迟没有下降，可能是动态请求比例过高，或应用层仍在重复查询；如果CDN响应变快而5xx增加，则应检查回源连接上限、超时设置和重试次数。重试过多会把一次失败放大成多次源站请求。
常见问题
缓存时间越长越好吗？
不是。版本固定的静态文件可以较长时间缓存，价格、权限和库存等数据应缩短时间或禁止共享缓存。
CDN能替代计算节点吗？
不能。CDN适合分发内容和吸收重复请求，业务计算、数据写入与权限判断仍需由计算节点完成。
缓存命中率高就代表系统健康吗？
不一定。还要结合回源延迟、应用P95、错误率、连接数和数据库负载判断，单一指标可能掩盖动态接口故障。
节点故障时应立即切换吗？
应先确认故障持续性和影响范围，再执行分流。短暂网络抖动时立即切换，可能造成新的流量震荡。
最终，稳定的CDN与计算节点协同方案应同时具备清晰的缓存边界、可控的请求分流、有限的回源重试和可验证的故障切换。只有把边缘处理能力与计算节点的业务责任分开，性能优化才不会以数据一致性和系统可维护性为代价。