如何实现两个GCP Python Cloud Functions间的公共代码共享与引用

针对两个独立部署的Python云函数要复用公共逻辑的场景，可根据自身的维护成本、迭代节奏选择以下几种实现方式：

1. 公共代码随函数部署包一同打包 #

这是最零成本的实现方式：

• 把公共逻辑整理为独立的.py文件（或小型Python包目录），分别放到两个函数的部署根目录下
• 函数代码中直接用本地相对导入的方式引用，比如from common_utils import parse_request_params
• 部署时按正常流程把整个目录的代码打包上传即可
  优缺点：操作门槛最低，本地调试可以直接运行，无额外权限配置成本；但每次修改公共代码需要同步更新两个函数的部署目录，重复部署操作多，容易出现两个函数引用的公共代码版本不一致的问题。

2. 公共代码打包为私有Python依赖通过requirements.txt拉取 #

适合长期维护的复用场景：

• 把公共代码按照标准Python包结构组织，通过pyproject.toml或setup.py配置打包规则，生成可安装的分发包
• 将分发包托管在GCP Cloud Artifact Registry搭建的私有PyPI源中，按照语义化版本标记每次更新
• 两个函数的requirements.txt中直接添加对应版本的私有依赖地址，部署时云函数运行时会自动拉取安装
  优缺点：公共代码可以统一发版、统一维护，两个函数可以按需固定依赖版本，从根源上避免版本不一致的问题；初始配置需要搭建私有PyPI源、给函数的运行服务账号配置对应仓库的读权限，有一次性的配置成本。

3. 函数运行时从Cloud Storage动态拉取公共代码 #

适合不想维护额外打包流程的灵活场景：

• 把公共代码的.py文件上传到专属的Cloud Storage存储桶，设置为私有访问
• 在每个函数的初始化代码中，先通过Cloud Storage客户端把公共代码文件下载到云函数运行时的可写临时目录/tmp，再将该目录加入Python的导入搜索路径，即可正常引用公共代码，示例代码如下：

from google.cloud import storage
import sys

# 初始化存储客户端，拉取公共代码到临时目录
storage_client = storage.Client()
bucket = storage_client.bucket("your-common-code-bucket")
blob = bucket.blob("common_utils.py")
blob.download_to_filename("/tmp/common_utils.py")

# 将临时目录加入导入路径
sys.path.insert(0, "/tmp")
from common_utils import 公共方法

优缺点：公共代码只需要维护一份，修改后直接更新存储桶里的文件即可，不需要重新打包部署两个函数；但会增加函数的冷启动耗时，且如果没有做版本固定，公共代码的意外改动会同时影响两个函数的运行稳定性，需要给函数服务账号配置对应存储桶的读权限。

4. 公共代码托管在独立Git仓库，通过远程依赖导入 #

适合公共代码有独立版本管理需求的场景：

• 把公共代码放到独立的Git仓库中，每次迭代打对应的版本tag
• 在两个函数的requirements.txt中直接指定Git仓库的依赖地址，格式类似git+https://your-repo-url@版本tag#子目录路径
  优缺点：公共代码的版本可以通过Git tag追溯，不需要额外搭建PyPI源；需要给云函数的部署服务账号配置对应Git仓库的拉取权限，适合代码量较小的公共模块。

选型参考 #

• 公共逻辑占比低、两个函数迭代完全绑定的场景，选本地打包方式最省事
• 公共代码需要长期迭代、会被更多函数复用的场景，优先选择私有PyPI包方案，长期维护成本最低
• 不想维护打包流程、能接受轻微冷启动开销的场景，选择Cloud Storage动态拉取方案更灵活

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