2019/09/30 78
PRC(Remote Procedure Call)远程过程调用,两台服务器:A 和 B,A 服务器想调用 B 服务器上提供的某个函数/方法,由于它们不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和交换调用的数据。
那么 RPC 需要解决以下问题:
gRPC 是 Google 开源的基于 HTTP/2 和 ProtoBuf 的通用 RPC 框架,主要面向移动应用开发基于 HTTP/2 协议标准而设计,基于 ProtoBuf(Protocol Buffers)序列化协议开发,且支持众多开发语言。gRPC 提供了一种简单的方法来精确地定义服务和为 iOS、Android 和后台支持服务自动生成可靠性很强的客户端功能库。客户端充分利用高级流和链接功能,从而有助于节省带宽、降低 TCP 连接次数、节省 CPU 使用。
gRPC 现在处于初期阶段,存在一些明显的磨合问题,但未来前景光明。总的来说,我对 gRPC 如何整合到后端体统非常乐观,而且很高兴见证这个框架的发展。
REST 和 gRPC 之间最大的区别之一是有效负载的格式。 REST 消息系统通常包含 JSON,而 gRPC 接收并返回 Protobuf,从性能角度来看 Protobuf 是一种非常高效的格式,而 JSON 是一种文本格式。
REST 在很大程度上取决于 HTTP(通常是 HTTP 1.1)和请求-响应模型。而 gRPC 使用较新的 HTTP/2 协议
HTTP 1.0 RFC 1945 是一个 60 页的 RFC。 HTTP 1.1 最初再 RFC 2616 中描述,它膨胀到 176 页。但是,后来 IETF 将其拆分为六个不同的文档 RFC 7230、7231、7232、7233、7234 和 7235,合并页数更高。
HTTP 1.1 允许许多可选部件,这些部件会增长其大小和复杂性。
网页的趋势是增加页面的总大小(平均1.9MB)以及需要单独请求的页面上对象的数量。由于每个对象都需要单独的 HTTP 请求,因此单独对象的乘法会显著增加 Web 服务器上的负载,并减慢用户的页面加载时间。
HTTP 1.1 对延迟很敏感。每个请求都需要 TCP 握手,而数量较大的请求会显著占用加载页面所需的时间。在大多数情况下,可用带宽的持续改进并不能解决这些延迟问题。
对同一域的连接数的限制(过去只有 2 个,现在为 6-8)大大降低了并行发送多个请求的能力。
REST 乍看上去非常不错,但是与实际业务结合起来是非常困难的,因此大多实现并不完全遵循 REST 理念,只是用其原则。开发人员还要经常为 REST URL 和参数伤神费力。
gRPC 使用的概念模型是具有具有清晰接口的服务和用于请求和响应的结构化消息。此模型直接从编程语言概念(如接口、函数、方法和数据结构)进行转换。它还允许 gRPC 为您自动生成客户端库。
REST 仅支持 HTTP 1.x 中可用的请求-响应模型。但是,gRPC 充分利用了 HTTP/2 的功能,并允许您不断流式传输信息。流式处理有几种类型。
服务器在收到客户端请求消息后发送回响应流。发送回所有响应后,服务器的状态详细信息和可选的尾随元数据将发送回服务器端完成。客户端在具有服务器的所有响应后完成。
客户端向服务器发送多个请求的流。服务器发送回单个响应,通常但不一定是在收到客户端的所有请求后发送的,以及其状态详细信息和可选的尾随元数据。
在这种情况下,客户端和服务器以非常自由的形式相互发送信息(客户端启动序列除外)。最终,客户端将关闭连接。
在微服务领域,gRPC 将很快占据主导地位。性能优势和易于开发实在是太好了,不能放弃。但是,不要搞错,REST 还会在会很长一段时间内存在。为了向后兼容性的原因和公开访问。