把一部分逻辑放在边缘节点上，收益不是在于计算速度快慢，而是可以省去一次跨区域的往返。适用场景要先筛选出来。
适合边缘处理的请求具有共同的特点：延迟敏感、逻辑轻量、不需要访问整个数据库。比如根据地区来显示不同的内容、根据请求头进行个性化分流、修改响应头和缓存策略、验证鉴权令牌、A/B 测试的流量分配等。涉及事务写入和复杂查询的逻辑仍然需要回源，边缘算力和内存配额都很有限，塞入重逻辑就会超时。
脚本边界要划定好。执行时间一般只有几十毫秒，内存占用也有上限，外部网络访问要单独申请开通。调试期间采用灰度发布的方式，先放到少量节点上进行测试，看命中率、错误率怎么样之后再全部上线。
回源兜底不能省。当出现脚本异常、超时或者被限流的情况时，请求应该可以正常穿透到源站，而不能直接返回错误页面。设置好降级规则，然后进行一次实际的演练。
从节点维度来看，耗时的长短以及失败率的多少，各个区域之间的差异也很大。
成本账要单独计算。边缘请求是按次数收费的，在站点访问量大的时候，把高频但是本可以使用缓存规则来解决的动作放到边缘上，费用可能会大于收益；先通过日志统计可以下放请求的比例，再确定接入范围。