做过Web应用、API服务、小程序、IoT平台的团队，大概率都遇到过这些场景：
- 接口响应慢，用户等几秒才出结果；
- 跨地域访问延迟高，海外用户访问国内服务器慢；
- 源站压力大，所有请求都打到源站，容易被打崩；
- 想就近处理请求，但自建边缘节点成本高、运维复杂；
- 静态资源可以CDN加速，但动态逻辑还是要回源；
- 想做A/B测试、灰度发布，但改动要发版，周期长。
这些问题背后，指向同一个核心：传统架构中，所有请求都要回到源站处理，跨地域延迟高、源站压力大、响应慢。
CDN可以加速静态资源（图片、JS、CSS），但动态逻辑（接口处理、数据计算、请求改写）还是要回源。边缘计算的核心是：把部分计算逻辑下沉到CDN边缘节点，在离用户最近的地方处理请求，减少回源、降低延迟、减轻源站压力。
为了帮企业提升接口响应速度和系统架构弹性，360CDN正式推出面向Web应用、API服务、小程序、IoT等场景的 边缘计算方案。核心思路是：依托全球边缘节点+轻量计算引擎+灵活编程模型，在边缘节点就近处理请求，实现"请求就近处理、源站专注核心业务"。
为什么传统架构延迟高、源站压力大？
先搞清楚一个问题：传统架构的瓶颈在哪里？
传统架构的请求链路
用户请求 → CDN（仅加速静态资源） → 回源 → 源站处理 → 返回结果
问题很明显：
- 所有动态请求都要回源：即使只是简单的请求改写、参数校验，也要回到源站；
- 跨地域延迟高：海外用户访问国内源站，网络延迟可能几百毫秒；
- 源站压力大：所有请求都打到源站，源站需要处理所有逻辑；
- 扩展性差：源站扩容成本高，难以应对流量峰值。
边缘计算的请求链路
用户请求 → CDN边缘节点（执行计算逻辑） → 按需回源 → 源站处理核心业务 → 返回结果
优势很明显：
- 请求就近处理：边缘节点离用户近，延迟低；
- 减少回源：部分逻辑在边缘处理，不用回源；
- 减轻源站压力：源站只处理核心业务，压力小；
灵活扩展：边缘节点分布式部署，天然高可用。
边缘计算要解决的，就是"如何把计算逻辑下沉到离用户最近的地方"的问题。
360CDN边缘计算怎么做？"边缘节点 + 轻量引擎 + 灵活编程"
360CDN的边缘计算方案，不是简单的"在CDN上跑代码"，而是完整的边缘计算平台。
1. 全球边缘节点：离用户最近
360CDN拥有全球分布的边缘节点：
- 国内覆盖主要省市，海外覆盖主要国家和地区；
- 节点离用户近，网络延迟低（通常10~50ms）；
- 分布式架构，单点故障不影响整体服务；
- 自动路由，用户请求自动路由到最近的边缘节点。
简单说：用户在哪里，计算就在哪里。
2. 轻量计算引擎：快速执行
边缘节点上运行轻量计算引擎，支持快速执行用户代码：
- 毫秒级冷启动：代码首次执行快速启动，无明显延迟；
- 高并发支持：单节点支持高并发请求，性能稳定；
- 资源隔离：不同用户的代码隔离运行，互不影响；
- 自动扩缩容：根据流量自动调整资源，无需手动运维。
3. 灵活编程模型：JavaScript/Python
支持多种编程语言，开发者可以快速编写边缘逻辑：
- JavaScript（兼容Service Worker API）：前端开发者熟悉，上手快；
- Python：适合数据处理、API调用等场景；
- 丰富的API：提供请求/响应处理、KV存储、HTTP请求、加密解密等能力；
- 本地调试工具：支持本地调试，开发效率高。
4. 常见应用场景
边缘计算可以做什么？以下是典型场景：
边缘计算 vs 传统源站处理：有什么区别？
简单说：
- 核心业务逻辑（如数据库操作、复杂计算）还是在源站处理；
- 请求改写、验证、分流、聚合等逻辑可以下沉到边缘；
- 边缘计算不是替代源站，而是分担源站压力、降低延迟。
哪些业务场景最需要边缘计算？
几乎所有Web应用都可以从边缘计算中受益，但在以下场景中，边缘计算的价值尤其突出：
共同特点是：对延迟敏感、源站压力大、需要灵活分流或改写请求。
实战反馈：某API服务接口响应时间降低60%，源站压力降低50%
前段时间，一个API服务客户遇到一个很头疼的问题：他们的API服务部署在国内，但海外用户占比30%+，海外用户访问延迟高（200~500ms），而且随着用户量增长，源站压力越来越大，接口响应时间变慢，偶尔还会被打崩。
运维团队面临的痛点很明确：
- 海外用户延迟高，体验差；
- 所有请求都打到源站，源站压力大；
- 想做A/B测试，但改源站代码、发版周期长；
- 接口被恶意刷量，源站被拖垮；
- 自建海外节点成本高，运维复杂。
接入360CDN边缘计算方案后，他们做了以下调整：
- 身份验证下沉：将Token验证逻辑部署到边缘节点，非法请求直接在边缘拦截，不再回源；
- 请求改写：在边缘节点统一改写请求Header，添加用户地域、设备信息等，源站无需重复处理；
- A/B测试分流：在边缘节点根据用户ID哈希分流，快速上线A/B测试，无需改源站代码；
- API聚合：将多个接口聚合为一个边缘接口，客户端只需请求一次，边缘节点并行调用源站多个接口后合并返回；
- 限流防刷：在边缘节点配置限流规则，单IP每分钟请求超过阈值则直接返回429，恶意请求不进入源站。
接入后，他们反馈比较明显：
- 接口响应时间降低60%：海外用户延迟从300ms降到120ms，国内用户从80ms降到30ms；
- 源站压力降低50%：非法请求和限流请求在边缘拦截，源站只处理合法请求；
- A/B测试上线周期从1周缩短到1小时：边缘代码独立部署，无需改源站、无需发版；
- API聚合后，客户端请求次数减少70%：原来需要请求5个接口，现在只需请求1个聚合接口；
- 恶意刷量被有效拦截：边缘限流后，源站不再被刷量拖垮；
- 无需自建海外节点：利用360CDN全球边缘节点，成本低，运维简单。
他们技术负责人后来总结："以前所有逻辑都堆在源站，源站压力大，改个分流逻辑还要发版。上了360CDN边缘计算后，验证、分流、聚合都下沉到边缘，源站专注核心业务，响应快了，压力小了，开发效率也高了。"
⚠️ 掏心窝子的避坑指南
给准备上边缘计算的兄弟们提几个实战建议，都是很容易踩的坑。
1. 不是所有逻辑都适合下沉到边缘
边缘计算适合轻量、无状态、低延迟要求的逻辑，不适合重型、有状态、需要访问数据库的逻辑。
建议：
- 适合下沉：请求改写、Header处理、身份验证、分流、限流、API聚合、简单数据处理；
- 不适合下沉：数据库操作、复杂计算、文件存储、长连接处理；
- 边缘代码要轻量，执行时间控制在毫秒级；
- 边缘节点无状态，不要依赖本地存储（可用KV存储或回源）。
把重型逻辑下沉到边缘，反而会增加延迟。
2. 边缘代码要独立测试，避免影响线上
边缘代码直接在线上运行，如果代码有bug，可能影响所有用户。
建议：
- 使用本地调试工具，在本地充分测试后再部署；
- 支持灰度部署，先在小部分流量上测试，确认无误后再全量；
- 设置超时时间，边缘代码执行超时自动回源，避免阻塞请求；
- 做好错误处理，边缘代码异常时自动回源，保证业务不中断；
- 保留回滚能力，新代码有问题可以快速回滚到旧版本。
边缘代码影响面大，测试不充分容易出事故。
3. KV存储有容量和延迟限制，不要滥用
边缘计算通常提供KV存储能力，但KV存储不是数据库，有容量和延迟限制。
建议：
- KV存储适合小数据、读多写少的场景（如配置、开关、简单缓存）；
- 不适合大数据、写多读少、需要复杂查询的场景；
- 注意KV存储的读写延迟，频繁读写可能影响性能；
- 重要数据还是要存在源站数据库，边缘KV只做缓存；
- 设置合理的过期时间，避免数据过期导致问题。
把KV当数据库用，性能和容量都不够。
4. 边缘节点分布广，要注意数据合规
边缘节点可能分布在不同国家和地区，涉及数据跨境问题。
建议：
- 了解业务涉及地区的数据合规要求（如GDPR、个人信息保护法）；
- 敏感数据不要在边缘节点存储或处理；
- 用户数据尽量在源站处理，边缘节点只做转发和轻量处理；
- 必要时配置地域限制，只在特定地区的边缘节点处理数据；
- 做好数据加密，传输和存储都要加密。
数据合规问题不容忽视，尤其是涉及用户隐私的场景。
5. 边缘计算不是万能的，需要和源站配合
边缘计算是源站的补充，不是替代。
建议：
- 边缘处理轻量逻辑，源站处理核心业务；
- 边缘和源站之间做好接口设计，避免耦合；
- 边缘代码异常时自动回源，保证业务连续性；
- 做好监控和告警，边缘代码异常及时通知；
- 定期review边缘代码，优化性能和逻辑。
只靠边缘计算不够，边缘和源站配合才能发挥最大价值。
如果你的业务也面临 接口响应慢、跨地域延迟高、源站压力大、A/B测试周期长、恶意刷量 这些问题，可以把业务接入360CDN边缘计算方案，先从一个简单的请求改写场景开始尝试。