Google Cloud Container Registry：避免镜像冗余，实现多入口云函数部署

可以借助单个容器部署多个入口点不同的Google Cloud Function（GCF），下面提供两种可行方案，各有优劣，可根据你的需求选择：

方案1：基于同一个镜像部署多个独立云函数 #

GCF支持在部署时通过--entry-point参数指定函数的入口方法，只要你的镜像中包含所有需要的处理函数，就可以基于同一镜像多次部署不同的云函数，每个函数指定不同的入口点。

操作示例 #

假设你的镜像gcr.io/[你的项目ID]/shared-function-image:latest中已经包含func1和func2两个处理函数，部署命令如下：

# 部署第一个云函数，指定入口为func1
gcloud functions deploy func1-service \
  --entry-point func1 \
  --runtime python39 \
  --trigger-http \
  --image gcr.io/[你的项目ID]/shared-function-image:latest

# 部署第二个云函数，指定入口为func2
gcloud functions deploy func2-service \
  --entry-point func2 \
  --runtime python39 \
  --trigger-http \
  --image gcr.io/[你的项目ID]/shared-function-image:latest

优势与局限 #

• 优势：每个云函数是独立资源，可单独缩放、配置触发器，日志和监控也相互隔离，排查问题更方便；同时只需要维护一份镜像，节省Container Registry的存储空间和镜像构建时间。
• 局限：需要管理多个云函数资源，配置和部署步骤会多一些。

方案2：单云函数内部路由（你提到的方式） #

在单个云函数的主入口中，根据请求的特征（比如路径、请求头、参数）来路由到对应的处理函数。

代码示例（Python） #

def main(request):
    # 根据请求路径判断要调用的处理函数
    request_path = request.path.strip()
    
    if request_path == "/func1":
        return handle_func1(request)
    elif request_path == "/func2":
        return handle_func2(request)
    else:
        return "无效的请求端点", 404

def handle_func1(request):
    # 函数1的业务逻辑
    return "来自函数1的响应"

def handle_func2(request):
    # 函数2的业务逻辑
    return "来自函数2的响应"

优势与局限 #

• 优势：只需要维护一个云函数资源，管理成本低，无需多次部署。
• 局限：所有流量共享同一个函数实例，缩放是整体进行的，若某一个业务逻辑流量突增，会导致整个函数扩容，可能造成资源浪费；同时日志和监控是合并的，需要额外过滤才能定位到具体函数的问题。

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