上个月有个做家居流量站的团队跑来找我们聊部署位置的事。他们的情况是：日均点击量一千二三，落地页三条主线，服务器两台四核八G的源站，前面挂了一层CDN，只开了基础缓存。验收要求也很明确——跳转决策两百毫秒内完成，配置改完十分钟内全网生效，出问题能单条规则回退。就这三条约束，直接把"服务端整体判定"和"边缘节点就近决策"的取舍摆到了桌面上。源站算得准，可离访客远；边缘算得快，但拿不到完整上下文。下面我就按准备、执行、复盘这个工作流，把这件事拆开讲讲。
准备阶段：先把流量结构和部署条件摸清楚
部署位置这事儿，在写第一行规则之前就该定下来。而定下来的依据是输入项，靠个人习惯拍板肯定不行。准备阶段要产出三样东西：流量画像、节点拓扑、验收口径。缺一个，后面的取舍都会变成拍脑袋。
输入项一：流量画像的颗粒度
先回答一个问题——你的跳转判定依赖哪些信号。如果主要是地域、运营商、设备类型、请求路径这类粗粒度信号，边缘节点完全拿得到，没必要回源。可要是判定得结合登录态、历史访问记录、实时频次计数、账户维度的累计状态，这些数据在源站或独立的状态服务里，边缘节点要么拿不到，要么得额外做一次内部请求，延迟优势就被吃掉了。
操作上建议拉一份七天的访问日志，按信号维度做一次可得性盘点：哪些字段在边缘层可见，哪些必须回源，哪些要查缓存。这里有个限制得说清楚——边缘层的日志采样往往不完整，盘点结果只能当方向参考，不能当精确统计用。验证方法是抽一天做全量对照，把边缘日志和源站日志按请求ID对齐，看信号缺失比例落在什么区间。
输入项二：节点拓扑与回源成本
边缘节点的价值来自"离访客近"，但这个近是有条件的。节点覆盖密度不足的区域，边缘决策的实际延迟可能和回源差不多，甚至因为多一跳内部转发更慢。准备阶段要把节点分布图和主要流量来源叠在一起看，重点确认三件事：核心流量区域是否有可用节点、边缘到源站的回源链路质量、状态同步的通道是否稳定。
这里有个常被忽略的限制：边缘节点上的规则副本需要同步，同步频率决定了配置生效的时效。如果业务要求配置改完几分钟内全网一致，同步机制就必须在准备阶段验证过，而不是上线后再补。验证方法很简单，改一条低风险规则，记录各区域节点实际生效的时间差，这个时间差就是后续所有时效承诺的基线。
验收要求不能写成"要快、要稳"。要落成可测量的项：决策耗时按分位数定阈值而不是平均值，配置生效时间按最慢节点算，回退操作要有明确的完成判据。准备阶段把这些写进检查表，后面执行和复盘才有对照物。这个环节最容易出的问题是口径和执行层脱节——验收要求写的是端到端耗时，监控埋的却是单段耗时，复盘时对不上账。
执行阶段：规则放哪一层，按判定依赖拆而不是按偏好拆
执行阶段的核心动作，是把规则集拆成两层：能在边缘闭合的放边缘，必须依赖完整上下文的回源。这活儿跟二选一没什么关系，关键在分层。
适合放在边缘节点的判定
粗粒度、无状态、可枚举的规则适合下沉。典型的是基于请求头特征的地域分流、设备类型匹配、路径前缀匹配、静态黑名单命中。这类规则的特点是输入完全来自当前请求本身，不需要任何跨请求的状态。
- 条件：判定所需信号全部在单次请求内可得，且规则集规模可控。
- 操作： 把规则编译成节点可执行的轻量脚本或配置表，随同步通道下发。
- 限制： 节点上的存储和计算资源有限，规则条目过多会推高单次匹配耗时，需要设条目上限。
- 验证： 灰度一条规则到小比例流量，对比边缘决策与源站决策的一致率，一致率不达标就不扩大范围。
必须留在服务端的判定
依赖跨请求状态的判定没法在边缘闭合。频次控制要看一段时间窗口内的累计次数，会话保持要看之前发过什么标识，账户维度的策略要看历史放行记录。把这些硬塞到边缘，只能靠边缘侧维护状态副本，副本一致性问题会变成新的故障源。
操作上建议把这类判定收敛到一个独立的决策服务，边缘节点通过内部接口调用，接口超时要有明确的兜底分支。限制在于每增加一次内部调用就多一段耗时，所以决策服务本身要做得足够轻，避免在里面再串数据库查询。验证方法是压测决策服务在目标并发下的分位耗时，把这个数加进端到端预算里重新核对验收口径。
两层之间的衔接约定
分层部署最容易出问题的地方在衔接处：边缘判定放行之后，源站要不要再判一次；边缘判定拒绝之后，源站还有没有申诉通道。这些约定必须在执行阶段写死，不能留给运行时临时决定。建议的做法是边缘层只做"明确可判"的部分，凡是有歧义的请求一律透传到服务端，把复杂度集中在可观测的一层。这样做的代价是回源比例上升，收益是决策链路只有一条主干，排查时不用两头对账。
实战复盘：一个家居流量团队的分层调整过程
回到开头那个团队。他们最初的做法是全量回源：所有跳转判定都在源站完成，CDN只做静态资源缓存。背景是日均一千二三的点击，两条源站机器，三条落地页主线。问题出在两个地方——高峰期端到端耗时经常冲到四百毫秒以上，配置改完要等缓存刷新才生效，最慢的时候接近半小时。
踩的第一个坑是他们试图把频次控制也搬到边缘，结果边缘侧维护的计数副本和源站对不上，同一访客在两套逻辑里被算了两次，跳转分支出现来回摆动。第二个坑是回源比例没有监控，某条规则写错导致大量请求打到源站，源站负载上去之后整体变慢，但当时没人意识到是规则问题，先怀疑的是机器规格不够。
调整过程分三步走。第一步做信号盘点，把三条落地页的判定条件逐条列出来，标出哪些只用当前请求就能判。盘完发现大约六成的判定其实是粗粒度的地域加设备匹配，完全可以下沉。第二步把下沉的部分改成边缘配置表，规则条目控制在几十条以内，同时给边缘层加了一条硬约定：凡是不在配置表里的请求一律透传，不在边缘做任何推测性判定。第三步给回源比例加了监控，按小时统计，超过预设区间就告警。
最终状态是边缘承担了大部分粗判，端到端耗时的分位值回到两百毫秒以内，配置生效时间压到十分钟量级，频次和会话相关的判定全部留在服务端，两套逻辑不再互相干扰。这个案例里没有哪一层是"更好"的，取舍点在于把判定按依赖拆开，各自放在能闭合的那一层。
复盘阶段：用什么指标判断部署位置选对了
复盘不是看系统有没有挂，而是看当初的取舍假设还成不成立。建议盯四类指标，每类都要有明确的观察窗口和判读方式。
决策耗时分布
看分位数而不是平均值。平均值会被大量快速请求稀释，掩盖长尾。观察窗口建议按小时切，重点看高峰时段的分位值是否突破验收阈值。判读方式是把端到端耗时拆成边缘段、内部调用段、源站段，哪一段涨了就回到那一层的配置里找原因。限制是分段埋点本身有开销，采样率要控制，不然监控会反过来影响被测对象。
两层决策一致率
抽一部分请求同时走边缘判定和服务端判定，比对结果。一致率下降通常意味着某一层的规则副本过期，或者信号在传输中出现了衰减。这个指标的价值在于提前发现配置漂移，而不是等用户反馈跳转不对才去查。
回源比例
回源比例是分层部署的健康度指标。比例突然升高，要么是规则配置让更多请求落到透传分支，要么是边缘层出了异常在被动回退。给这个指标设一个区间，超出就查，别等源站扛不住才发现。
配置生效时效与回退完成度
记录每次配置变更从提交到全节点生效的实际耗时，以及每次回退操作从触发到确认完成的耗时。这两个数会随着节点数量增长而变化，定期核对能提前发现同步通道的瓶颈。回退完成度要有明确判据，比如所有节点都确认加载了上一版本配置，而不是"点了回退按钮"就算完。
几个容易混淆的边界问题
边缘节点能不能承担部分状态
可以，但边界要划清楚。只读的、允许短暂不一致的状态可以放边缘，比如地域到策略的映射表；需要强一致的计数和会话状态不要放。判断标准是这份状态不一致时，会不会导致同一访客在短时间内看到互相矛盾的结果。会，就别放边缘。
服务端整体判定是不是一定更准
不一定。服务端拿到的是完整上下文，但上下文本身可能已经过时——比如设备信号在传输链路上被改写，源站看到的和边缘看到的未必是同一份。准确性的前提是信号在采集点就是对的，这跟部署在哪一层没有直接关系。所以准备阶段的信号盘点比架构选择更靠前。
能不能两层都放全量规则做互备
技术上可行，维护上不推荐。两套全量规则意味着两份需要同步的配置，漂移风险翻倍，排查时还要判断是哪一套生效了。互备的正确做法是边缘层保留一份最小可用规则集用于兜底，主干判定仍然单点收敛。
上线前的配置检查项
把上面这些收敛成一份可执行的检查项，按准备、执行、复盘三段对照：
- 信号盘点完成，每个判定条件标注了可得层级，边缘不可得的已明确回源。
- 节点拓扑与流量来源叠图核对过，核心区域的节点覆盖和回源链路质量有记录。
- 配置同步机制验证过，各区域节点的生效时间差有基线数据。
- 边缘层规则条目设了上限，超出上限的请求走透传而非拒绝。
- 内部决策调用设了超时和兜底分支，兜底行为在灰度中验证过。
- 回源比例、决策耗时分布、两层一致率三项监控已接入并有告警区间。
- 回退操作有明确完成判据，且演练过一次。
- 验收口径与实际埋点对齐，端到端耗时和分段耗时的统计口径一致。
这份清单不解决"选哪一层"的问题，它解决的是"选完之后怎么确认没选错"。部署位置本身没有标准答案，约束条件变了，答案就该跟着变。
