为什么你需要关心“流量去哪儿”的问题？
验证与回滚
折腾Edge Compute时，我发现最麻烦的往往不是安装，而是配置。假设你运营一个电商网站，想试试新的首页布局会不会让更多人下单。传统做法是：后端写代码，按用户ID或者Cookie把流量分成两组，然后分别展示不同页面。听起来简单，但一上线就遇到麻烦——用户来自五湖四海，不同地区的网络延迟不同，页面加载速度各异，甚至部分海外用户直接访问了旧版本。更头疼的是，如果想先只对某个省份的用户测试新版，等确认没问题再全量开放，传统后端逻辑往往需要改路由、配数据库、甚至重新部署。
这些问题背后其实只有一个核心矛盾：“决策点”离用户太远了。请求要从用户端绕到中心服务器，中心服务器再根据一堆规则决定给哪个版本。每多一次网络跳转，就多一次延迟和失败风险。而边缘计算要做的，就是把决策点拉到离用户最近的那一跳——也就是CDN节点上。
Edge Compute：A/B测试、灰度发布、地域路由：先分清楚这三个概念
在进入边缘计算之前，有必要把三个容易混淆的术语拆开讲清楚。
A/B测试：比较两个版本的效果
把用户随机分成两组，一组看到A版本（比如旧首页），另一组看到B版本（新首页）。然后通过埋点数据统计哪个版本的转化率更高。这里的关键是“随机”——不能故意把某个地区的用户全分给B，否则样本偏差会导致结论无效。
灰度发布：逐步扩大新版本覆盖面
先让一小部分用户（比如5%）用新版本，观察无故障后再逐步扩大到10%、50%、100%。本质是风险控制：如果新版本有Bug，爆炸半径很小。灰度发布通常要求同一用户在整个测试期间始终看到同一个版本（粘性），否则用户一会儿新一会儿旧，体验混乱。
用户地域精准画像路由
根据IP地址判断用户所在国家/城市、运营商甚至具体大区，然后分配不同的响应内容或后端服务器。例如，广东用户直接访问广州节点，新疆用户分配兰州节点；或者针对海外用户展示英文版。
这三者经常组合使用。比如：灰度发布时，只对华东地区的用户放出新版本，同时在华东内部随机做A/B测试比较两个版本。这种组合需求，靠传统中心化架构做起来异常复杂，而边缘计算天然适合。
边缘计算凭什么能解决这些问题？
故障定位思路
边缘计算的核心思想是“计算靠近数据源”。在CDN场景下，全球成百上千个边缘节点原本只负责缓存静态文件，但现在这些节点上可以运行轻量级脚本（Edge Function / Edge Worker）。当用户请求到达离他最近的节点时，脚本立即执行，根据请求携带的信息（IP、Cookie、User-Agent等）现场决定：
- 该用户属于哪个实验组？
- 该用户来自哪个地域？
- 应该返回哪个版本的页面或转发到哪个源站？
整个过程在节点内完成，不需要回源询问中心服务器。这意味着：
- 延迟极低：决策在离用户仅几毫秒的地方做出，用户体验更好。
- 无中心压力：流量分发逻辑分散到各个节点，中心服务器只需要管理配置同步。
- 独立灰度：每个节点可以独立决定是否启用新版本，例如先只在美国西部节点启用灰度，测试稳定后再推往全球。
- 动态路由：根据实时地理位置或网络状况动态调整后端地址，甚至能在边缘做简单的负载均衡。
核心实现逻辑：三个阶段
虽然具体代码因平台而异（Cloudflare Workers、Fastly Compute@Edge、阿里云Edge Routine等），但思想是通用的。我们以最简模型描述。
第一阶段：请求拦截与特征提取
边缘脚本最先拿到原始请求。它需要做三件事：
- 解析IP：通过内置数据库或API将用户IP转换为地理位置（国家、城市、经纬度）。部分平台还会提供ASN、运营商。
- 读取Cookie：如果之前已经给用户打上了实验标签（比如
experiment_id=blue），则直接使用该标签保证粘性。 - 计算哈希：如果用户是第一次访问并且没有标签，可以通过对用户IP或User-Agent做一致性哈希，将其映射到某个实验组。例如取IP的MD5前几位对100取模，小于5则进入灰度组。
第二阶段：路由决策
根据提取的特征，边缘脚本生成一个“路由指令”：
- 版本选择：如果用户属于灰度组，则改写URL路径指向新版静态资源或转发到新版源站；否则保留原版。
- 地域路由：如果用户IP来自欧洲，则设置后端为欧洲源站集群；若来自亚洲，则设置亚洲源站。
- 响应注入：在返回的HTML中嵌入埋点脚本（用于后续分析），同时设置
Set-Cookie记录当前实验分组，确保后续请求依然命中相同版本。
第三阶段：配置同步与监控
边缘节点的脚本是由中心控制台统一下发的。你可以在控制面板里配置：灰度比例、地域白名单/黑名单、实验起止时间。配置更新后秒级同步到所有边缘节点。同时每个节点会将决策日志汇总到中心，用于后期分析A/B测试效果。
关联教程：此处可内链到“Edge Compute部署与验证”内容。
相关阅读：此处可内链到“Edge Compute常见问题”专题。
这种方案与纯后端方案相比，到底好在哪？——Edge Compute
实际操作要点
很多团队习惯在Nginx或应用层用Lua做灰度，或者在API网关做路由。但边缘计算提供了几个不可替代的优势：
- 无侵入性：你完全不需要修改后端代码，边缘脚本直接在请求进入源站前拦截并改写。对于老旧系统或无法频繁变更的场景尤其友好。
- 全球一致性：传统Nginx灰度需要每台机器部署相同配置，升级麻烦。边缘计算配置中心一次推送，全球节点同步。
- 支持更细粒度：比如“只对北京联通用户且使用iPhone的用户展示新版”，这种复杂规则在后端维护起来很重，在边缘脚本里只是一段if判断。
- 降低回源带宽：边缘节点可以直接返回简单的静态响应（如维护页、重定向），无需占用源站资源。
实际应用中要警惕哪几个坑？
技术选型不能只看好处，需要了解边界和风险。
1. 边缘脚本的资源限制
大多数边缘计算平台对CPU执行时间、内存、脚本大小有严格限制（例如Cloudflare Workers限制30秒CPU时间、128MB内存）。如果你试图做复杂的加解密或大数据量处理，很可能超时。建议只做轻量级逻辑，复杂的计算回源处理。
2. 粘性问题与一致性哈希
灰度发布要求同一用户始终看到同一版本。如果边缘脚本仅靠IP做哈希，那么用户切换网络（手机切Wi-Fi）可能会导致分组变化。通常建议配合Cookie或JWT Token来持久化分组。但Cookie本身会被清除，所以需要设计回退策略（比如回退到IP哈希）。
3. 地域数据库准确度
IP地理定位是一个概率问题，部分手机用户使用动态IP或VPN可能导致误判。用于地域路由时，建议设定一个“未知地域”的默认兜底策略（比如默认分配到主要源站）。
4. 测试与回滚
边缘脚本一旦部署就会影响所有流量。务必先在少量节点上测试，或者通过“排除白名单”的方式先放行内部IP。同时要保留一键关闭灰度的能力——大多数控制台支持禁用脚本或切换版本。
从一个简单的例子看完整流程
故障定位思路
假设我们要对某个静态网站做A/B测试：B版本标题改为“限时特惠”来测试点击率。使用边缘计算方案：
- 在管理后台编写边缘脚本：读取请求的Cookie，如果没有
ab_test值，则按IP哈希赋值为A或B，并设置Cookie。 - 脚本检查
ab_test的值：如果为B，则从缓存或源站拉取B版本的HTML（可能通过不同的URL前缀区分）。 - 脚本还在响应中注入一段统计脚本，上报用户分组和点击事件。
- 发布脚本，先设置灰度比例为5%（即只有5%的哈希值进入B组）。观察一小时后，发现B组点击率明显提升且无报错，在控制台将比例调高到50%。
- 同时可以按地域过滤：在脚本中加一句“如果IP国家不是CN，则强制分配A组”，确保海外用户不受影响。
- 最终确认效果后，将B版本设为默认版本，然后下线脚本。
整个过程没有改动一行后端代码，所有决策都在CDN边缘完成。
延伸阅读：此处可内链到“Edge Compute配置案例”相关文章。
总结：边缘计算≠万能，但它是流量分发的“瑞士军刀”
配置前的检查
对于中小型团队甚至个人站长，过去实现A/B测试和地域路由往往需要依赖昂贵的商业服务或复杂的自建系统。边缘计算的出现，把以前只有大厂才能玩的精细化流量调度能力，以低成本、低门槛的形式交给了所有人。你不需要精通分布式系统，只需要理解基本的请求/响应模型，就能在CDN边缘编写控制逻辑。
当然，它也有适用范围：如果你的业务数据高度敏感且必须存放在境内，注意选择边缘节点在境内的服务商；如果你的逻辑极其复杂（比如需要实时查询数据库），那么边缘脚本可能不适合，应回源处理。但总体而言，对于大多数Web应用的灰度发布、A/B测试和地域路由场景，边缘计算是目前最优的解法之一。按这个顺序复查，Edge Compute遇到异常时也更容易定位。
延伸阅读