proto包名相同的场景下如何将流量路由到不同版本的gRPC服务

安全阿岳

2026-9-30

gRPC多版本蓝绿部署解决方案

设计合理性说明

你们的初始设计没有问题。
proto文件中的package v1是API兼容性级别的标识，仅当出现不兼容修改（删除字段、修改字段类型、调整方法签名等breaking change）时才需要升级为package v2。功能迭代的小版本、补丁版本完全不需要修改proto包声明，避免批量改动文件的诉求是合理的，符合gRPC生态的常规实践。

原生支持的路由实现方案

gRPC没有HTTP路径重写的对应概念，但原生支持通过**请求元数据（Metadata）**传递自定义标识，可完美满足版本路由需求，实现成本极低：

1. 客户端改造（仅需新增一行逻辑，无需修改生成代码）

Golang侧示例如下，仅需要在发起请求前把目标版本注入请求上下文即可：

import "google.golang.org/grpc/metadata"

// 注入版本标识到请求上下文
ctx := metadata.AppendToOutgoingContext(context.Background(), "x-service-version", "v1.2.0")
// 后续正常调用protoc生成的客户端方法即可，无需修改生成的代码
resp, err := yourGenClient.YourRPCMethod(ctx, reqParams)

该逻辑和REST请求在Header中携带版本参数的作用完全等价，对业务逻辑无侵入。

2. 路由侧配置

如果你使用Envoy、Istio、APISIX等支持gRPC的网关或服务网格，直接配置路由规则：匹配请求元数据中的x-service-version字段，将流量转发到对应版本的服务集群即可，配置逻辑和REST匹配请求头路由完全一致。
如果你是自研路由逻辑，在服务端拦截器中读取x-service-version元数据，执行对应版本的流量转发/隔离逻辑即可。