brpc
brpc copied to clipboard
请问 brpc 现阶段是否支持 gRPC 双向streaming?
文档中关于对grpc支持特性的描述比较少,请问下目前是否已经支持了grpc的流式特性?
主要用在什么场景?如果上下游都是brpc,可以用https://github.com/apache/incubator-brpc/blob/master/docs/en/streaming_rpc.md
主要用在什么场景?如果上下游都是brpc,可以用https://github.com/apache/incubator-brpc/blob/master/docs/en/streaming_rpc.md
我们的服务目前基于 brpc(v0.9.5)开发。使用场景为语音识别/合成。 目前服务版本升级,需要同时支持请求/应答双向流。由于要走 NGINX/openresty 反向代理,所以brpc client方式可能不适合。 由于brpc的一些特性十分好用,所以我们想在之前brpc server的基础上进行迭代开发,筛选后可行的方案为HTTP/2(brpc不支持Websocket)。 目前比较符合我们需求的是gRPC streaming RPC(NGINX支持gRPC反向代理)或者HTTP/2 API(考虑过libcurl,但测试发现用libcurl发h2给brpc server会被解析为h1.1)。 关系为:gRPC client->NGINX/openresty->brpc(gRPC) server
nginx 和 upstream server 之间还不支持grpc和h2c协议吧?貌似只在和客户端方向之间的通信上支持。
nginx 和 upstream server 之间还不支持grpc和h2c协议吧?貌似只在和客户端方向之间的通信上支持。
NGINX 在 1.13.10 及以后的版本中已经包含 grpc 相关功能 在 NGINX 配置文件 location 中,添加 grpc_pass (例如:grpcs://127.0.0.1:443;)即可实现 gRPC 反向代理的配置。目前我们的服务已经对这个 feature 验证并测试通过。
nginx 和 upstream server 之间还不支持grpc和h2c协议吧?貌似只在和客户端方向之间的通信上支持。
另外,NGINX 已经在较早的版本中支持 h2c 协议,详细信息可以参考这里
这个有相关计划吗? brpc
支持的平台还比较少, 很难采用 baidu_std
协议.
我理解brpc的定位是服务器之间高效的RPC通信,包括它的设计实现等都能体现这些。@crise1990你想要的其实是客户端和服务器之间的通信(公网),注意这里的客户端是真正意义的移动端。
目前nginx支持的h2,向下游upstream发送的时候,是不是已经修改为http1.1了啊?
我理解brpc的定位是服务器之间高效的RPC通信,包括它的设计实现等都能体现这些。@crise1990你想要的其实是客户端和服务器之间的通信(公网),注意这里的客户端是真正意义的移动端。
目前nginx支持的h2,向下游upstream发送的时候,是不是已经修改为http1.1了啊?
嗯对,因为之前服务端的设计需要考虑到移动端通信(公网)的问题,而且服务端并没有支持 Websocket(我之前接手的服务端代码是基于 bRPC 框架实现,对外 API 是走 HTTP/1.1 协议) 而服务间调用,之前是想在不大改服务端框架的情况下,找到一种更适合流式服务设计的方法,所以想问下 bRPC 是否已经集成了 gRPC Streaming 特性
是的,NGINX 即便是目前支持的 h2 或者 h2c,都会在向下游 upstream 发送的时候改为 HTTP/1.x
我理解brpc的定位是服务器之间高效的RPC通信,包括它的设计实现等都能体现这些。@crise1990你想要的其实是客户端和服务器之间的通信(公网),注意这里的客户端是真正意义的移动端。 目前nginx支持的h2,向下游upstream发送的时候,是不是已经修改为http1.1了啊?
嗯对,因为之前服务端的设计需要考虑到移动端通信(公网)的问题,而且服务端并没有支持 Websocket(我之前接手的服务端代码是基于 bRPC 框架实现,对外 API 是走 HTTP/1.1 协议) 而服务间调用,之前是想在不大改服务端框架的情况下,找到一种更适合流式服务设计的方法,所以想问下 bRPC 是否已经集成了 gRPC Streaming 特性
是的,NGINX 即便是目前支持的 h2 或者 h2c,都会在向下游 upstream 发送的时候改为 HTTP/1.x
streaming复杂度蛮高的,brpc默认支持一种streaming模式:https://github.com/apache/incubator-brpc/blob/master/docs/en/streaming_rpc.md ,但目前没有提供对grpc streaming的封装。另外,服务间能走普通rpc还是尽量普通rpc,这儿大概是什么场景,一定要使用streaming模式么?
我理解brpc的定位是服务器之间高效的RPC通信,包括它的设计实现等都能体现这些。@crise1990你想要的其实是客户端和服务器之间的通信(公网),注意这里的客户端是真正意义的移动端。 目前nginx支持的h2,向下游upstream发送的时候,是不是已经修改为http1.1了啊?
嗯对,因为之前服务端的设计需要考虑到移动端通信(公网)的问题,而且服务端并没有支持 Websocket(我之前接手的服务端代码是基于 bRPC 框架实现,对外 API 是走 HTTP/1.1 协议) 而服务间调用,之前是想在不大改服务端框架的情况下,找到一种更适合流式服务设计的方法,所以想问下 bRPC 是否已经集成了 gRPC Streaming 特性 是的,NGINX 即便是目前支持的 h2 或者 h2c,都会在向下游 upstream 发送的时候改为 HTTP/1.x
streaming复杂度蛮高的,brpc默认支持一种streaming模式:https://github.com/apache/incubator-brpc/blob/master/docs/en/streaming_rpc.md ,但目前没有提供对grpc streaming的封装。另外,服务间能走普通rpc还是尽量普通rpc,这儿大概是什么场景,一定要使用streaming模式么?
谢谢。
我们的使用场景主要是 ASR/TTS 这类需要支持实时识别/实时合成的流式 API 服务。(其实比较理想的情况是使用 Websocket 协议,而且目前我已经基于go websocket 重写了一版微服务,但性能上跟 bRPC 还是存在差距。)
也有考虑过 bRPC 扩展服务端协议(但由于整体性能瓶颈主要在算法引擎侧,所以后续的 PR 并没有在此基础上针对工程侧提出性能优化的要求,所以扩展协议这个方向目前还没有开始做)。
服务间调用使用普通 RPC 是完全没有问题的。不过如果是跟客户端对接(可能是移动端 SDK 或者其他类型的客户端,比如解决方案相关的需求中需要整合不同的 API 能力),尤其是跨部门合作,需要考虑通用型,所以使用 baidu_std
可能就不太合适。在不支持 Websocket 的情况下基本上就只能用 HTTP 或者 gRPC 或者其他主流 RPC 方案。
在考虑到 ASR/TTS 需要实时返回 partial 结果,所以服务端需要按照流式特性进行改造,所以考虑 HTTP/2 或者 gRPC Streaming 这种支持流式的协议或者实现方式。