跨GCP项目通过其他项目PubSub触发Cloud Function实现方案

GCP原生PubSub触发器确实不支持直接绑定其他项目下的主题，以下是3种生产可用的实现路径，按运维成本从低到高排序：

方案1：源主题推送订阅直接调用本项目HTTP类型Cloud Function #

这是改动最小的方案，不需要额外中转资源：

• 在当前项目部署目标Cloud Function时，选择HTTP触发器，推荐开启服务账号鉴权（不要开未认证访问，避免公网恶意调用），部署完成后复制Function的HTTP调用地址
• 切换到T1所属的源项目，给T1创建推送类型的订阅
• 订阅推送端点填写刚才复制的Function HTTP地址，推送身份选择源项目内的服务账号，提前给这个服务账号绑定当前项目目标Function的Cloud Functions Invoker角色，保证推送请求有权限调用Function
• 发测试消息验证链路通断即可，消息重试、死信策略都可以直接在这个推送订阅上配置

注意：这个方案需要你在源项目拥有PubSub订阅创建、主题配置的对应权限。

方案2：跨项目订阅投递到本项目中转主题，绑定原生PubSub触发器 #

如果不想用HTTP触发器，希望完全沿用原生PubSub触发的事件格式、重试逻辑，优先选这个方案，全程托管无额外运维成本：

• 在当前项目新建一个中转PubSub主题T_mid
• 给源项目的PubSub官方服务账号（格式为service-${源项目数字编号}@gcp-sa-pubsub.iam.gserviceaccount.com）绑定T_mid的Pub/Sub Publisher权限
• 切回源项目，给T1创建订阅，投递类型选择Pub/Sub主题，投递目标填当前项目T_mid的完整资源路径
• 回到当前项目，给T_mid绑定原生PubSub类型的Cloud Function触发器即可

注意：这个方案的消息可靠性和同项目原生触发完全一致，不需要维护额外转发代码，是长期运行的首选方案。

方案3：自维护轻量转发层 #

如果你没有源项目的主题、订阅配置权限，仅持有T1的消息消费权限，可以用这个方案：

• 在当前项目部署一个极低规格的转发服务（用最小实例数的Cloud Run、单实例Cloud Function都可以），以拉模式消费T1的订阅消息
• 转发服务收到消息后，直接调用目标Cloud Function，或者把消息投递到本项目自建的PubSub主题，再通过主题触发目标Function
• 这个方案仅需要源项目给你开T1的订阅消费权限即可，不需要源项目管理员配合做配置，缺点是需要自己维护转发逻辑的异常重试、幂等处理。

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