Cloud Run for Anthos应用版本部署策略咨询：通过生产流量子集验证新版本的正确方案

嘿，我来帮你理清这个问题——正确答案其实是选项A，不是C，下面给你拆解原因：

为什么选项A是最优解？ #

Cloud Run（包括Anthos版本）的原生设计就是用Revisions来管理应用的不同版本：

• 每次部署新版本代码，都会生成一个全新的Revision（旧版本的Revision会保留）
• 你可以直接在Cloud Run的服务配置里，灵活设置不同Revisions之间的流量占比（比如给新版本分配10%流量，剩下90%留旧版本）
• 这种方式完全贴合你“先导部分流量评估，再决定是否全量发布”的需求，不需要额外添加任何组件，操作直接且成本低

为什么选项C不合适？ #

选项C提到的通过Cloud Build触发器配置TRAFFIC_PERCENTAGE变量，是一种自动化的持续部署流量分配方式：

• 它的作用是在CI/CD流水线自动构建部署时，直接给新版本分配固定比例的流量
• 但你的需求是手动可控、按需调整的流量测试——比如先给5%流量观察几天，没问题再升到50%，最后全量切换，这种场景下用Cloud Build的固定变量配置就太僵化了，没办法灵活调整流量比例

其他选项的问题 #

• 选项B：创建新Service再加Cloud Load Balancing属于过度设计，Cloud Run本身就支持Revision级别的流量拆分，额外加LB只会增加架构复杂度和运维成本
• 选项D：Traffic Director是服务网格级别的流量管理工具，Cloud Run for Anthos已经集成了Istio服务网格，但原生的Revision流量管理完全能满足你的需求，不需要额外配置Traffic Director来做这个简单的流量拆分

内容的提问来源于stack exchange，提问作者Joycelyn Chua