如何配置GCP中SFTP文件上传后自动触发Cloud Function运行

你当前在GCE VM上自建的SFTP服务没有托管存储的原生事件触发能力，以下是经过生产验证的落地路径，不需要改动客户端侧的上传逻辑，客户完全无感知。

方案1：inotify+Pub/Sub触发（推荐，适配现有架构，改造量最小） #

核心逻辑是在SFTP所在VM上通过内核级的文件事件监听确认文件上传完成，投递事件到Pub/Sub后拉起Cloud Function处理，完全兼容你已经搭建完成的SFTP服务。

• 权限前置配置
  给SFTP实例绑定的服务账号分配最小必要权限：目标Pub/Sub主题的发布权限、如果要做文件持久化备份再加对应Cloud Storage桶的对象写入权限，不要直接用Compute Engine默认服务账号的宽权限。
• 搭建事件链路
  新建一个Pub/Sub主题（例如命名为sftp-edi-upload），创建第二代Cloud Function时选择该主题作为触发源，给函数的运行时服务账号分配文件读取、EDI业务处理需要的对应权限。如果选择把上传的文件同步到Cloud Storage持久化存储，函数直接读取GCS上的文件即可，不需要额外打通到VM的内网访问链路，稳定性更高。
• VM侧部署文件监听服务
  不要写定时轮询脚本扫目录，资源占用高、延迟大还容易漏事件。直接安装inotify-tools，通过内核提供的inotify接口监听SFTP上传目录，只监听IN_CLOSE_WRITE事件——该事件仅在文件写入完成、文件句柄关闭时触发，天然避开文件上传过程中读取到半截文件的问题。
  监听脚本示例如下，写完后用systemd托管配置开机自启、异常自动重启，不要用nohup后台运行：

  #!/bin/bash
  # 替换为实际的SFTP上传目录
  WATCH_PATH=/srv/sftp/edi_upload
  # 替换为实际的Pub/Sub主题全路径
  TOPIC=projects/[你的GCP项目ID]/topics/sftp-edi-upload
  # 替换为实际用来存EDI备份的GCS桶
  BACKUP_BUCKET=gs://your-edi-backup-bucket
  
  inotifywait -m -r -e close_write --format '%w%f' "$WATCH_PATH" | while read FILE_FULL_PATH
  do
    # 过滤非EDI后缀的临时文件、传输碎片文件
    if [[ "$FILE_FULL_PATH" =~ \.edi$ ]]; then
      # 同步文件到GCS做持久化备份，避免VM本地盘故障丢业务数据
      gsutil cp "$FILE_FULL_PATH" "$BACKUP_BUCKET/$(basename "$FILE_FULL_PATH")"
      # 组装事件消息投递到Pub/Sub，携带文件路径、上传时间等必要信息
      gcloud pubsub topics publish "$TOPIC" --message="{
        \"local_path\":\"$FILE_FULL_PATH\",
        \"gcs_path\":\"$BACKUP_BUCKET/$(basename "$FILE_FULL_PATH")\",
        \"upload_ts\":\"$(date -Iseconds)\"
      }"
    fi
  done
  

• 函数逻辑开发
  Cloud Function被Pub/Sub触发后，直接解析消息体里的文件地址，读取EDI内容做订舱请求解析、后续业务流转即可。记得加幂等校验逻辑，同一个文件重复收到事件时跳过重复处理，避免生成重复订舱单。

方案2：SFTP目录挂载GCS（长期维护成本最低） #

如果可以接受SFTP服务的小幅配置调整，长期来看该方案运维成本最低：

• 安装gcsfuse将Cloud Storage桶直接挂载为SFTP的上传根目录，所有客户通过SFTP上传的文件会直接持久化写入GCS，不需要在VM本地盘存储业务文件，省去磁盘扩容、本地文件备份的工作量。
• 挂载时添加--implicit-dirs参数适配SFTP的目录结构，同时配置好SFTP的chroot权限隔离，避免不同客户的文件越权访问。
• 直接给对应GCS桶配置「对象最终创建」事件触发器，直接关联Cloud Function即可，不需要额外维护VM上的监听脚本、Pub/Sub自定义投递链路，所有事件通知由GCP托管，可靠性更高。
• 注意大文件上传场景下，GCS的事件通知只会在对象分片全部合并完成后触发，不会出现读取到半传文件的问题。

生产环境避坑要点 #

• 不要监听IN_CREATE/IN_MODIFY类事件，这类事件会在文件开始写入、上传未完成时触发，此时读取文件会拿到不完整的EDI内容，直接导致解析失败。
• 如果客户上传的EDI文件体积较大，可要求客户上传完正式文件后额外上传一个同名的.ok标记文件，监听到标记文件后再触发处理，彻底规避网络波动导致的文件传输不完整问题。
• 文件处理完成后及时将文件移动到已处理目录，不要长期滞留在上传目录，避免重复触发处理逻辑。
• 所有服务账号严格遵循最小权限原则分配IAM角色，不要给项目级的高权限，避免安全风险。

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