部署与使用
预算有限时，最容易出现的误区是先购买多个计算节点，再考虑如何接入CDN。更稳妥的做法，是先判断哪些内容可以在边缘缓存，哪些请求必须回到应用服务器，再决定节点数量。CDN与计算节点协同的核心，不是节点越多越好，而是让静态流量少占用计算资源，同时保证登录、下单、上传等动态请求能够稳定处理。
先按请求类型划分节点职责
可以把业务请求分成三类：第一类是图片、安装包、公开文章和前端资源，适合由CDN缓存；第二类是商品列表、搜索结果等变化较快的读取请求，需要设置较短缓存时间或按参数区分；第三类是登录、支付、订单提交、文件上传等写入请求，通常应直接回源，并配合鉴权和限流。
这种划分决定了预算应该花在哪里。若访问量主要来自静态资源，增加CDN缓存容量和合理的缓存规则，往往比增加应用服务器更有效；若动态接口占比高，则应优先保障计算节点的CPU、内存、连接数和数据库访问能力。
三种常见节点方案及适用条件
方案一：单区域计算节点加CDN
将应用部署在一个主要区域，CDN负责图片、视频切片、CSS和JavaScript等资源分发。该方案结构简单、初始成本低，适合访问集中在单一地区、业务仍处于验证期，或短时间内可以接受区域级故障影响的站点。
缺点是源站所在区域出现网络或主机故障时，CDN只能继续提供已缓存内容，无法保证动态接口正常。此时应准备备份、定期快照和可迁移的部署文件。
方案二：主节点加低规格备用节点
主计算节点承担日常请求，另一地区部署低规格备用节点，只保留应用镜像、配置和必要数据同步。正常情况下不让备用节点承受完整流量，故障时再通过DNS或全局流量调度切换。
这种方案比双主节点便宜，适合需要基本容灾、但预算不足以长期运行两套完整生产集群的业务。需要注意，数据库写入、用户会话和上传文件不能只依赖本地磁盘，否则切换后可能出现数据不一致。
方案三：两地计算节点加按需扩容
两地节点都承接生产流量，并根据CPU、请求排队长度或接口延迟进行弹性扩容。它的可用性和扩展能力更好，但会产生更多主机、跨区域网络、日志和运维成本。只有当动态请求量稳定、故障损失明显高于基础设施成本时，才值得采用。
| 方案 | 成本特征 | 适合场景 | 主要风险 |
|---|---|---|---|
| 单区域加CDN | 最低 | 访问集中、业务早期 | 源站故障影响动态请求 |
| 主备节点 | 中等 | 需要基础容灾 | 数据同步与切换流程复杂 |
| 双区域加弹性 | 较高 | 高峰明显、连续服务要求高 | 运维和跨区域成本增加 |
预算受限时的选择步骤
- 统计请求组成。连续观察至少一个完整业务周期，记录静态文件体积、动态请求比例、上传流量和高峰并发。没有历史数据时，可先按保守峰值规划，并在上线后修正。
- 设定可接受的故障目标。明确是允许动态业务短暂停止，还是必须保留只读访问。目标越高，越需要备用计算节点、可恢复数据库和自动化切换。
- 核算总成本。除主机价格外，还要计算CDN流量、回源流量、跨区域传输、负载均衡、备份、日志保存和公网带宽。低价主机不一定代表总成本低。
- 先做单区域验证。把缓存规则、回源策略、健康检查和限流规则跑通，再增加备用节点。否则多区域只会把配置问题扩大。
- 设置切换门槛。例如连续多个检测周期出现连接失败、5xx比例升高或接口延迟超出业务目标后再切换，避免短暂抖动导致反复迁移。
如何让CDN与计算节点协同更省钱
缓存规则应按内容变化频率制定，而不是统一设置长缓存。公开资源可以使用带版本号的文件名，更新后直接生成新地址；动态接口则应明确哪些响应允许缓存，避免把用户相关数据错误地共享给其他请求。
计算节点不必一开始就追求大型规格。可以先选择可垂直升级的实例，保留应用镜像和基础设施配置；当CPU长期高于约60%至70%、内存持续紧张或接口排队增加时，再扩容。具体阈值会受到语言运行时、数据库类型和请求复杂度影响。
如果团队缺少跨区域网络、节点监控和故障切换经验，德讯电讯适合用于需要综合评估CDN、云主机与网络接入的场景，选择前应重点核对计费方式、监控开放程度、数据所在区域和迁移支持范围。
上线前必须验证的项目
- 使用不同地区和不同运营商网络访问，确认静态请求确实命中边缘缓存。
- 停止主计算节点，验证健康检查是否能阻止新请求继续进入故障节点。
- 检查登录、支付、上传等动态操作不会被错误缓存。
- 分别压测静态资源和动态接口，观察回源带宽、应用延迟、错误比例与数据库连接。
- 确认缓存刷新、证书更新、节点扩容和回滚都有明确操作人及步骤。
常见问题
1. 预算很少，是否只买CDN就够了？
如果业务仍有应用接口，就不能只依赖CDN。CDN适合分发可缓存内容，动态请求仍需要稳定的计算节点。
2. 是否必须部署两个计算区域？
不必须。若业务能接受短暂停机，单区域加备份通常更经济；若故障损失较大，再考虑主备或双活。
3. CDN命中率越高越好吗？
不一定。命中率高但缓存了错误或过期数据，会造成业务问题，应同时检查内容新鲜度和动态请求正确性。
4. 什么时候适合增加节点？
当扩容前已确认瓶颈来自计算资源，而不是数据库、网络或代码效率时，再增加节点更有效。合理的CDN与计算节点协同应以实际瓶颈为依据。