配置支持App Engine、存储桶和云函数的跨项目后端负载均衡器

方案一：Cloud Run代理转发层（通用适配所有服务类型） #

既然你已经搞定了Cloud Run的跨项目负载均衡配置，最直接的方式是用Cloud Run作为中间代理，转发请求到其他项目的Cloud Functions、存储桶或App Engine服务：

• 核心思路：在负载均衡所在项目部署轻量Cloud Run服务，根据请求路径/规则转发到目标跨项目资源，利用已有的Cloud Run跨项目后端配置实现统一路由。

• 配置要点：

  1. 编写代理逻辑：用Node.js/Python实现请求转发，处理路径映射、请求头（尤其是Host头，避免目标服务校验失败）和请求体透传。
  2. 权限配置：给Cloud Run服务的默认服务账号授予目标项目资源的访问权限：
     • Cloud Functions：授予roles/cloudfunctions.invoker角色
     • 存储桶：授予roles/storage.objectViewer（读访问）或roles/storage.objectAdmin（读写访问）角色
     • App Engine：授予roles/appengine.appViewer（读访问）或对应操作角色
  3. 复用已有配置：将这个代理Cloud Run服务添加到你的跨项目后端服务中，通过负载均衡的URL映射规则路由到不同的目标资源。

• 极简Node.js代理示例：

const express = require('express');
const axios = require('axios');
const app = express();
app.use(express.json({ limit: '10mb' }));

// 转发到跨项目Cloud Functions
app.all('/cf/*', async (req, res) => {
  const targetUrl = 'https://us-central1-target-project.cloudfunctions.net/my-function' + req.path.replace('/cf/', '/');
  try {
    const resp = await axios({
      method: req.method,
      url: targetUrl,
      data: req.body,
      headers: { ...req.headers, host: new URL(targetUrl).host }
    });
    res.status(resp.status).send(resp.data);
  } catch (err) {
    res.status(err.response?.status || 500).send(err.response?.data || 'Proxy Error');
  }
});

// 转发到跨项目存储桶
app.all('/storage/*', async (req, res) => {
  const targetUrl = 'https://storage.googleapis.com/target-bucket' + req.path.replace('/storage/', '/');
  try {
    const resp = await axios({
      method: req.method,
      url: targetUrl,
      headers: { ...req.headers, host: new URL(targetUrl).host }
    });
    res.status(resp.status).send(resp.data);
  } catch (err) {
    res.status(err.response?.status || 500).send(err.response?.data || 'Proxy Error');
  }
});

const port = process.env.PORT || 8080;
app.listen(port, () => console.log(`Proxy running on port ${port}`));

方案二：VPC Peering + Serverless NEG（原生适配Cloud Functions/App Engine） #

对于Cloud Functions和App Engine，可以通过VPC peering实现跨项目Serverless NEG的直接引用，无需代理：

• 核心思路：通过VPC peering打通负载均衡项目与目标项目的网络，在目标项目创建Serverless NEG（绑定Cloud Functions或App Engine服务），然后在负载均衡项目中跨项目引用该NEG。
• 配置步骤：
  1. 建立VPC peering：在负载均衡项目和目标项目中分别创建VPC peering连接，确保双方都接受 peering 请求。
  2. 创建目标项目的Serverless NEG：
     • Cloud Functions NEG：指定函数所在区域、函数名称，关联目标项目的VPC。
     • App Engine NEG：指定App Engine服务版本，关联目标项目的VPC。
  3. 权限授权：目标项目需要给负载均衡项目的服务账号（service-[负载均衡项目编号]@cloud-lb-sa.iam.gserviceaccount.com）授予roles/compute.networkUser角色，允许其访问目标项目的Serverless NEG。
  4. 配置负载均衡：在负载均衡项目中创建后端服务，选择"跨项目NEG"，填入目标项目的NEG资源路径，再配置URL映射路由到该后端服务。

注意：存储桶无法通过Serverless NEG跨项目引用，仍需结合方案一的代理或方案三的直接IAM授权。

方案三：IAM授权直接访问跨项目存储桶 #

对于存储桶，无需代理即可通过负载均衡直接访问，只需配置正确的IAM权限：

• 配置步骤：
  1. 在负载均衡项目中创建后端服务，选择"Cloud Storage"作为后端类型，填入跨项目存储桶的完整名称（如gs://target-project-bucket）。
  2. 授权负载均衡服务账号：给负载均衡项目的service-[项目编号]@cloud-lb-sa.iam.gserviceaccount.com服务账号授予目标存储桶的roles/storage.objectViewer（读访问）或更高权限。
  3. 可选启用Cloud CDN：为后端服务开启Cloud CDN，优化静态资源的访问性能。

总结建议 #

• 如果需要统一适配所有三种后端类型，方案一的Cloud Run代理层是最灵活的选择，配置成本低且兼容所有服务。
• 对于Cloud Functions和App Engine，方案二的原生Serverless NEG方式性能更优，适合对延迟敏感的场景。
• 存储桶优先用方案三的直接IAM授权，无需额外代理层。

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