crise1990 commented on issue #843: URL: https://github.com/apache/incubator-brpc/issues/843#issuecomment-886686029
> > > 我理解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 扩展服务端协议](https://github.com/apache/incubator-brpc/blob/master/docs/cn/new_protocol.md)（但由于整体性能瓶颈主要在算法引擎侧，所以后续的 PR 并没有在此基础上针对工程侧提出性能优化的要求，所以扩展协议这个方向目前还没有开始做）。 服务间调用使用普通 RPC 是完全没有问题的。不过如果是跟客户端对接（可能是移动端 SDK 或者其他类型的客户端，比如解决方案相关的需求中需要整合不同的 API 能力），尤其是跨部门合作，需要考虑通用型，所以使用 `baidu_std` 可能就不太合适。在不支持 Websocket 的情况下基本上就只能用 HTTP 或者 gRPC 或者其他主流 RPC 方案。 在考虑到 ASR/TTS 需要实时返回 partial 结果，所以服务端需要按照流式特性进行改造，所以考虑 HTTP/2 或者 gRPC Streaming 这种支持流式的协议或者实现方式。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
