能否通过Google Cloud Run实现A/B测试的Cookie拆分以固定用户版本？

是的，无需迁移到App Engine，你可以通过两种主要方式在Cloud Run中实现类似的固定用户版本分发效果：

方法1：借助Cloud Load Balancing实现会话粘性 #

Cloud Run本身不直接支持会话亲和性，但可以通过前置Cloud HTTP(S)负载均衡器来实现：

• 为每个需要分发的Cloud Run版本创建单独的后端服务，或在同一个后端服务中添加多个版本作为后端实例组
• 在负载均衡器的后端服务配置里，启用会话亲和性：
  • 选择「基于Cookie」模式：配置负载均衡器生成自定义会话Cookie，同一用户的后续请求会被路由到首次分配的版本
  • 选择「IP哈希」模式：将同一IP（或IP段）的用户请求固定到特定版本，适合无法使用Cookie的场景
• 可结合负载均衡器的流量拆分规则，按比例分配初始流量到不同版本，同时保持会话粘性

这种方式无需修改应用代码，纯配置实现，但需要额外配置负载均衡组件，会产生对应服务成本。

方法2：在应用层实现自定义路由逻辑 #

如果不想依赖负载均衡，也可以在应用层面编写分发逻辑：

• 部署一个入口服务（可以是另一个Cloud Run服务或Cloud Functions）作为流量入口
• 当用户首次访问时，按预设比例分配版本，将版本信息存入用户Cookie（或通过Cloud Memory Store Redis存储IP与版本的映射）
• 后续请求到来时，读取Cookie或查询IP映射，将请求转发到对应的Cloud Run版本服务

这种方式灵活性更高，成本可控，但需要开发和维护额外的路由逻辑，同时要注意：

• Cookie需要设置合适的有效期和作用域，避免跨域失效
• 基于IP的映射可能受用户网络环境影响（如移动网络切换IP），导致版本切换
• 要维护版本映射的一致性，避免因版本更新导致的路由错误

注意事项 #

• 确保被绑定的Cloud Run版本处于活跃状态，不要随意删除，否则会导致用户请求失败
• 基于Cookie的方式比IP哈希更可靠，适合大多数Web应用场景
• 两种方式都可以和Cloud Run的原生流量管理功能结合，先按比例分配初始流量，再保持用户粘性

内容的提问来源于stack exchange，提问作者Jake Hill