http 网关如何优雅的暴露内部 grpc 服务

[ducuducu]

目前公司对外的 api 都要经过统一 http 网关，但一些内部的 rpc 服务想要对外服务的话，我们得专门写个 http 接口暴暴露给网关，但这样要维护两套代码有点麻烦，我想在网关这层做一道转换，把外部的 http 的 json 报文转换成内部的 rpc 调用。现在有两种方案：

• 第一种方法：在 grpc 服务的容器内起个 http 服务，这个 http 服务跟容器内的 grpc 服务通信，然后把容器内的这个 http 服务暴露给网关。相似方案的实现者有 grpc-gateway
• 第二种方式：grpc 服务在编译 proto 文件时生成 descriptorSet 描述文件，并上传的网关，网关解析这个文件能知道怎么组装 protobuf 消息，用 DynamicMessage 方式泛型调用内部 grpc 服务。相似方案的实现有 apisix 和 consul 的 grpc-transcoder

想知道下大厂是不是也有在网关层 json 转 rpc 的需求，你们是怎么做的呢？这两种方案你哪个好一些，有啥坑吗

[DefoliationM]

strings.Contains(r.Header.Get("Content-Type"), "application/grpc")

用 content-type 判断一下

[DefoliationM]

@DefoliationM 外面直接发 grpc 请求

[ducuducu]

@DefoliationM 也是个法子🥹

[GenericT]

@DefoliationM grpc 是 http2 的，他这网关看起来就不支持的样子

[lambdaq]

grpc 本来就是 h2 直接透传。谁不接住解析谁就是孙子就完事了。。。

[luozic]

看你们的网关支持啥啊。已有网关是个不支持 h2 的，你这传了有啥用。 看别的网关有啥，是准备切换别的网关了？

[coderxy]

还可以用 json 作为 grpc 的传输协议，http 网关不需要了解 pb 的内容。 最好要在网关做一个映射配置列表，不然全自动映射把内部重要接口泄漏了就 G 了

[ducuducu]

@GenericT 想让外部调用者直接能用 http json 报文调用。或者我可以把 proto 文件他们，让外部调用方用 grpc 方式调网关，这样，，也行

[luozic]

@coderxy 实际这种不是应该 两个么，一个外部的网关 流量出口，一个内部的网关 or 路由 作为 soa 的编排。

[Daath]

像 k8s 的 ingress-nginx 代理 http 和 grpc 服务？如果是的话，用路径匹配，分别指向不同的服务

[rrfeng]

grpc 用 http2 传输的，让我看看哪家网关还不支持 http2 ……

[coderxy]

@luozic 分开也可以，放在一起也可以。

[pinne]

实现过第二种，不过只在内部做定时调用使用过。做法是将 proto 文件内容上传到一个地方，然后网关处解析。不过这样的问题是每次 proto 更新，都要重新上传。想法是可以直接暴露接口给网关，网关自动获取 pb 内容。

[seth19960929]

第一个就错了吧, 不需要在 rpc 容器内启动 HTTP 服务,
你就另起服务作为 gateway, 然后穿透给 rpc 就好了. 就是你说的 grpc-gateway 不就挺好?

[poltao]

结合注册中心，搞个统一网关管理平台，由网关负责转发 http 请求就可以了

[macscsbf]

https://github.com/grpc-ecosystem/grpc-gateway.git
你是说这个吗

[ducuducu]

@macscsbf 对的

[mind3x]

敝司是写了个简单的 HTTP bridge 给一些作 gRPC 调用比较麻烦的 client 用，大概就是 header 里传 service 和 method 名，payload 和 response 都转 JSON 。

[layxy]

感觉你们网关还是不健全,网关一个很重要的基础能力就是协议转换,对外统一都是 http(s),但是内部服务有 springcloud,dubbo,grpc 等,不可能让内部服务再封装 http 再在网关注册,这样所有接入方的工作量会大上不少,而且也浪费资源

[layxy]

@layxy 大点的公司会分流量网关和业务网关,但是一般公司不会拆分这么细