如何基于共享代码库组织多个Google Cloud Run服务并拆分依赖

1. 代码仓库组织方案 #

• 采用 monorepo 结构管理所有服务代码，根目录拆分三个核心目录：shared/ 放通用工具代码、services/ 放各独立服务实现、deploy/ 放各服务的部署配置文件
• shared/ 目录下封装所有可复用逻辑：包括Firestore读写封装、Cloud Storage操作工具、通用参数校验、日志上报组件，打包为本地可导入的Python工具包，不需要发布到PyPI，各服务在构建时直接引用本地路径即可
• services/ 下每个子目录对应一个独立Cloud Run服务，每个子目录下单独存放自身的业务代码、requirements.txt 依赖声明、Dockerfile，基础拆分示例如下：
  • lightweight-trigger-service：仅依赖google-cloud系列SDK，处理所有Firestore变更触发、移动端常规读写请求，镜像体积可控制在100M以内
  • ml-inference-service：仅在依赖里添加pytorch、transformers等ML库，专门处理推理相关请求，可单独配置更高规格的实例适配推理需求
• 每个服务的requirements.txt仅声明自身运行所需的依赖，shared目录用到的可选依赖（比如pytorch）不需要在轻量服务的依赖里声明，避免不必要的体积膨胀

2. 流量路由与服务调用规则 #

• 所有外部请求统一走Google Cloud Load Balancer入口，根据URL路径转发到对应Cloud Run服务，比如/api/firestore/* 转发到轻量服务，/api/ml/* 转发到ML推理服务
• 内部服务之间的调用直接用Cloud Run自带的私有服务域名，不需要走公网，延迟更低且更安全
• 原有Cloud Functions触发的请求，直接根据触发场景配置对应服务的调用地址：Firestore写入触发的非ML逻辑直接调用轻量服务，涉及推理的触发事件调用ML服务

3. 构建部署优化方案 #

• 各服务的Dockerfile单独编写，轻量服务直接用python:slim基础镜像，ML服务可以直接用Google Cloud提供的预构建PyTorch镜像，减少构建时间和镜像体积
• 构建时通过上下文路径控制只打包对应服务和共享代码，比如构建轻量服务的命令为 gcloud builds submit --tag gcr.io/[项目ID]/lightweight-service ./services/lightweight-trigger-service，同时在Dockerfile里通过COPY指令把根目录的shared目录复制到镜像内
• 依赖分层缓存：Dockerfile里先拷贝requirements.txt安装依赖，再拷贝业务代码，每次代码变更不需要重新安装依赖，大幅提升构建速度

4. 轻量化替代方案（适合小型项目） #

如果拆分后服务数量少于5个，不想维护多套部署配置，可以用Cloud Run的多容器单服务部署模式：

• 同一个Cloud Run服务内部署两个容器，轻量服务容器作为入口接收所有请求，ML推理容器只处理内部转发的推理请求，两个容器共享网络命名空间，本地调用延迟极低
• 该模式不需要额外配置负载均衡，所有请求统一用同一个服务域名，维护成本更低

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