brpc
brpc copied to clipboard
apache
请问 brpc 现阶段是否支持 gRPC 双向streaming？
主要用在什么场景？如果上下游都是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 在 1.13.10 及以后的版本中已经包含 grpc 相关功能 在 NGINX 配置文件 location 中，添加 grpc_pass （例如：grpcs://127.0.0.1:443;）即可实现 gRPC 反向代理的配置。目前我们的服务已经对这个 feature 验证并测试通过。
nginx 和 upstream server 之间还不支持grpc和h2c协议吧？貌似只在和客户端方向之间的通信上支持。
另外，NGINX 已经在较早的版本中支持 h2c 协议，详细信息可以参考这里
我理解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 这种支持流式的协议或者实现方式。