谷歌斗篷为什么需要同城双活部署
谷歌斗篷是本文的核心主题。上个月有个做跨境电商投放的团队踩了个坑，挺典型的。他们的Cloak服务跑在单台服务器上，机房网络突然抖了一下，跳转决策直接超时了将近四分钟。这四分钟里广告流量全落到默认页去了，转化归因断得干干净净。事后他们负责人问得挺具体：要是上了同城双活，这种中断能不能压到用户基本感觉不到？能。但得先搞清楚这套东西到底管什么、不管什么。
先说说谷歌斗篷是干嘛的。它属于面向Google Ads投放链路的流量调度和页面适配服务，用户从点击广告到落地页渲染这中间，流量特征识别、规则匹配、目标页面决策这几步都归它管。同城双活呢，就是在同一个城市里找两个物理隔离的可用区，各跑一套对等的Cloak决策节点，规则库、指纹库、配置中心都是共享的，再靠健康探测来做流量自动接管。那故障秒级切换是什么意思？主节点一出现不可用信号，调度层在秒级窗口内把新进来的流量引到备用节点，跳转服务不出现能被感知到的中断，就这么回事。
同城双活的技术架构与组成
双节点对等与共享状态层
这套架构有个前提，两个可用区里的Cloak节点功能上得完全对等，不能有主备角色的固化。每个节点自己就能完成流量识别、规则匹配、跳转决策这一整套。规则库、设备指纹库、IP信誉库这些状态数据走配置中心统一分发，节点本地留一份热缓存，决策延迟能压下来。这么设计图什么？切换的时候不需要做状态迁移，备节点拿本地缓存直接接管就行。
健康探测与故障判定
切换靠什么触发？健康探测。一般是在调度层给每个节点配两条链路，主动探测和被动探测。主动探测按固定间隔发轻量请求，看节点响应状态怎么样；被动探测统计的是真实流量的错误率、超时率，还有响应时间分位数。主动探测连续失败到阈值，或者被动探测的错误率在滑动窗口里超过设定比例，这个节点就被标记为不可用。
阈值这个事得说道说道。设太敏感，偶发抖动就触发切换；设太迟钝，秒级恢复就没意义了。灵敏度和误判之间得找个平衡点，这个没有万能值。
节点一旦被标记不可用，调度层把新进请求全量路由到健康节点。已经建立的会话连接怎么处理？常见的两种做法：等它自然结束，或者主动断开引导重连。前者对用户友好但收敛慢，后者收敛快但可能断掉少量会话。
回切也不能马虎。故障节点恢复了别急着全量接回来，得先观察一段时间，权重渐进恢复。要不然恢复瞬间流量一冲，二次故障就来了。
适用条件与限制
哪些场景适合采用
广告投放规模已经比较大，跳转服务一断就是实打实的转化损失；对服务可用性有明确要求，双倍节点资源成本能接受；同一城市内已经有两个可用区资源，或者云服务商支持同城多可用区；团队有基本的监控告警能力，健康探测阈值维护得起来。
- 跨地域访问延迟——同城双活改变不了用户到服务节点的物理距离，这个问题得靠边缘节点或者多地域部署
- 规则准确性——双活只保证服务不断，规则判定对不对它管不了，规则缺陷还是得走样本回放和校验流程
- 数据一致性冲突——两个节点同时写状态数据的话，冲突消解机制得另做，同城双活本身不提供这个
- 成本敏感型小规模投放——日均点击量低的时候，双活的资源开销可能比中断造成的预期损失还高
有个独立站投放团队，日均广告点击量两千左右，Cloak服务原来跑在单台云主机上。有次赶上机房维护窗口，那台主机网络不可达了大约三分钟，跳转请求大量超时，落地页匹配完全失效。后来他们改成同城双可用区部署，两套节点规格一样，规则库走配置中心同步，健康探测间隔设到数秒级。
中间踩过一个坑。刚开始探测超时阈值设得太短，网络稍微抖一下就往切换走，反而搞出不少不必要的流量迁移。后来把阈值放宽到能过滤瞬时不稳定的水平，同时保留被动探测的错误率统计，切换才稳下来。最终单节点故障时新流量接管控制在秒级，也不用人工介入重启了。
与相邻概念的对比
同城双活与跨城多活
同城双活的两个节点在一个城市里，网络延迟通常个位数毫秒，状态同步成本低，适合对延迟敏感但容灾范围要求不高的场景。跨城多活节点分散在不同城市，能扛城市级故障，但同步延迟明显上去了，规则库一致性维护更麻烦，成本也更高。选哪个看业务对容灾范围的实际要求，别一味追求覆盖范围大。
同城双活与单节点加冷备
单节点加冷备便宜，但冷备节点一般不保持热状态，切换得启动服务、加载规则库，恢复时间往往是分钟级。跳转服务这种中断即损失转化的场景，秒级和分钟级的差距直接反映在损失量级上。
同城双活与负载均衡多实例
负载均衡多实例是在同一个可用区里横向扩多个服务实例，解决的是容量问题，不是可用区级故障。整个可用区出问题的时候，多实例一起失效。同城双活解决的是可用区级别的隔离，这俩可以叠着用。
部署与维护中的关键检查项
- 两个可用区的节点规格对不对等——备用节点接管后资源不够，性能会退化
- 规则库同步链路有没有延迟监控——同步滞后会导致两节点决策不一致
- 健康探测阈值是不是拿实际流量验证过的，别直接套默认值
- 回切策略有没有配渐进恢复，恢复瞬间的流量冲击得防
- 切换事件有没有完整日志，事后复盘切换原因和影响范围全靠它
- 有没有定期做故障演练，验证切换机制在真实条件下还有效
常见概念性问题
同城双活能否保证零中断
不能。秒级切换意味着有个短暂的时间窗口，正在处理的请求可能受影响。要做到零中断得配上更复杂的会话保持和请求重放机制，成本上去了。同城双活的目标是把中断压到用户几乎无感知的量级，绝对零中断做不到。
两个节点同时故障怎么办
同城双活不覆盖双节点同时失效的情况。两个可用区同时出问题，得靠跨城节点或者降级兜底页面。要不要配第三节点看业务对极端故障的容忍度，多数中小规模投放场景没必要。
切换后规则是否立即生效
切换只改流量路由。规则生不生效，取决于备用节点的本地缓存跟最新规则库一不一致。备用节点缓存旧了，切换后可能出现短暂的规则版本差异。维护好同步链路的及时性是避免这个问题的关键。
