使用命名管道承载gRPC
最近GRPC很火,感觉整RPC不用GRPC都快跟不上时髦了。 gRPC设计 gRPC是一种与语言无关的高性能远程过程调用 (RPC) 框架。刚好需要使用一个的RPC应用系统,自然而然就盯上了它,但是它真能够解决所有问题吗?不见得,先看看他的优点: gRPC的主要优点: 现代高性能轻量级 RPC 框架。 协定优先 API 开发,默认使用协议缓冲区,允许与语言无关的实现。 可用于多种语言的工具,以生成强类型服务器和客户端。 支持客户端、服务器和双向流式处理调用。 使用 Protobuf 二进制序列化减少对网络的使用。 对应的适用场景: 微服务 :gRPC 设计用于低延迟和高吞吐量通信。 gRPC 对于效率至关重要的轻量级微服务非常有用。 点对点实时通信 :gRPC 对双向流式传输提供出色的支持。 gRPC 服务可以实时推送消息而无需轮询。 多语言环境 :gRPC 工具支持所有常用的开发语言,因此,gRPC 是多语言环境的理想选择。 网络受限环境 :gRPC 消息使用 Protobuf(一种轻量级消息格式)进行序列化。 gRPC 消息始终小于等效的 JSON 消息。 gRPC还是有缺点的: 浏览器支持受限 :绝大数浏览器不支持 HTTP/2 非人工可读取 :proto文件规定的格式在通讯中会序列化成二进制数据,人工解析较为困难。 不适用的场景与替代: 浏览器可访问的API :gRPC