日期:2026-08-18
我们内部一堆业务系统,有的用老 REST,有的用 gRPC,接大模型时各写各的适配,协议不统一,换模型供应商又得改一遍,接入方怨气冲天,网关组成了背锅侠。我们盘点过,光是适配不同供应商的协议,网关组一个月小一半时间花在改胶水上,正事没空做,技术债越堆越高。更离谱的是,有次某供应商改了返回字段,十几个调用方一夜之间报错,网关组被拉去一个个排查,其实根子在协议层没收敛,每次供应商抖一下全公司跟着抖。
现在网关对外只露一套 OpenAI 兼容协议,REST 和 gRPC 的调用方都走这套统一接口。请求进来先做归一化,字段映射、缺省补全,再按路由分发到背后的模型供应商。供应商那侧的协议差异由网关兜底转译,换供应商接入方无感。管控台里改条路由配置就能切供应商,不用动业务代码。接入方出问题先看网关日志里的归一后请求,不用再翻各家的原始报文,排障清爽了。
多协议归一要把五花八门的入参收拢成一套,我们定义了内部统一请求模型,REST 的 query 参数、gRPC 的结构体都映射进来,缺的给默认值。请求体差异难在字段名和嵌套不同,我们做了一层字段映射表,新增供应商填表就行,不再写胶水代码。供应商适配是脏活,每家认证、返回格式都不一样,我们把它收敛成适配器插件,认证和返回解析各写各的但接口统一,插上就能用。版本兼容不能忘,老调用方用的旧字段得留着,我们做向后兼容,废弃字段标记但不删。还有错误码归一,各家报错格式不同,我们统一成网关错误体,调用方一套处理逻辑走天下。
案例片段(已脱敏): 协议转换与归一化配置片段(字段示意):
gateway: ingress: openai_compatible normalize: model: map_to_internal default: { temperature: 0.4, stream: false } adapters: - vendor_a: { auth: token, resp: openai_shape } - vendor_b: { auth: oauth, resp: transform } compat: keep_deprecated_fields一次切换:某业务从 vendor_a 切 vendor_b,只改路由配置,业务代码零改动,调用方当天无感知完成迁移,供应商那次升级我们也只在网关侧改了适配器。
供应商适配的测试我们建了一套回放,每家适配器上线前拿历史报文跑一遍,返回 shape 对得上才放,这关拦过好几次字段错位。灰度切供应商时我们做了双跑比对,新旧适配器同时算,结果不一致就告警,确认稳了再切流量,这谨慎来自一次直接切翻车的教训。管控台的路由配置我们加了审批,谁改了路由、改了啥一目了然,避免有人手滑把流量导到错供应商,也方便事后复盘。
接入改造成本因为我们统一了协议,新业务接大模型从改一周代码降到贴配置半天。协议适配复用率上来了,新增供应商不再重写胶水,填适配器表即可。接入时效缩短最明显,调用方不用等网关组排期。调用错误率因为字段映射和默认值补全,参数错漏引发的报错少了一截。供应商抖动的影响面变小,协议层收敛后一次适配改全公司受益。文中数据为项目复盘口径,已做脱敏。
网关先把协议归一,这层我们当时没早做,后面补适配补到吐,血泪教训。对外一套 OpenAI 兼容接口,底下供应商随便换,业务方无感,这价值接一次就懂。适配器插件比写死胶水强,认证返回各写各的但接口统一,新增供应商填表就行。向后兼容别偷懒,老字段留着标记废弃,删了老调用方全挂,我们差点犯这错。错误码也要归一,各家报错格式不同,不统一调用方一套逻辑走不了。
协议归一这事,最大的隐性收益是排障简单了,出问题看归一后的请求就能定位,不用再翻各家的原始报文。网关组从胶水工变中枢,靠的就是把差异收进自己肚子里。
路由配置的幂等我们做了,同一条改动的重复提交不会重复生效,避免手抖连发把流量导飞。
协议不统一,网关组就永远是胶水工。我们盘点过,一个月小一半时间花在适配不同供应商协议上,正事一件没干,供应商一升级全公司跟着救火。OpenAI 兼容接口成了我们的救命稻草,对外一套,REST gRPC 都走它,背后供应商再怎么换,接入方代码不动。字段映射表是核心,新供应商填表而非写码,复用率一下就上来了。归一化时缺省值补全这招小但管用,参数错漏引发的报错少了一截,调用方少来找我们。向后兼容我们差点栽,有次想清理废弃字段,被老调用方拦住,幸好留了标记没删。错误码归一那步是后来补的,之前各家报错格式不一,调用方写一堆 if 分支,统一后一套逻辑走天下。切换供应商零代码改动这事,业务方一开始不信,实测切 vendor_b 当天无感迁移,从此网关组排期不再是瓶颈。协议归一不是技术炫技,是把网关从背锅侠变中枢的关键一步。