HTTP/2和Protobuf是如何为gRPC铺平道路的？

        2015 年，谷歌开源了一个名为 gRPC 的新 RPC（远程过程调用）框架。 事实上，这是由拥有最大（如果不是最大）微服务生态系统之一的公司构建和采用的，这一事实应该充分说明其功效。 谷歌每秒进行数百亿次 gRPC 调用，证明了该框架惊人的可扩展性。 难怪人们对 gRPC 的兴趣一直在稳步上升。 也许，它正准备跨越鸿沟，从“早期采用者”过渡到“早期大众”类别。

        在本文中，我想简单介绍一下 Protocol Buffer 和 HTTP/2 这两种技术，并讨论一下 gRPC 是如何站在这两者的肩膀上的。

Protocol Buffer  

          如果要调用RPC(远程过程调用)，则需要一种方法将内存中的对象（有效负载）转换为字节流，以便可以在网络上传输它们。 这种方法有很多名称：序列化(serialization)、编码(encoding)、编排(marshaling)。 大多数编程语言默认都支持该功能，最常用的是 JSON。 Json编码是人类可读的，并且它背后有一个庞大的社区。 但 JSON 也有其缺点， 它往往编解码速度较慢且编码后数据占用空间较大。 当处理大数据或大量相互通信的微服务时，所有这些缺点都会迅速累积起来。 另外JSON 没有类型，这会给向后或向前兼容性带来挑战。

        Protocol Buffer（又名 Protobuf）由 Google 开发并于 2008 年公开发布。Protobuf 是一种与语言和平台无关的接口定义语言(Interface Definition Language)。 它试图解决上述的一些限制。 使用 protobuf，您可以在 .proto 文件中定义消息格式。 然后，您可以使用 protobuf 编译器生成客户端和服务端代码来编码和解析数据。 它使用高效的二进制格式，并且数据类型可以随着时间的推移而发展。 一个缺点是二进制格式降低了人类的可读性。

HTTP/2

        gRPC 是面向 API 而不是面向资源的(比如REST)。 gRPC 建立在 HTTP2 传输层之上，因此可以支持 4 种类型的 API（unary, client streaming, server streaming, and bi-directional streaming）。 它还利用 Protobuf 进行消息交换。 Protbuf 支持 11 种以上语言以及二进制协议的所有优点。 正是 HTTP2 和 Protobuf 的强大组合赋予了 gRPC 在性能、吞吐量和灵活性方面的超能力。

Conclusion

        gRPC 的成功在很大程度上归功于Protobuf和 HTTP/2 等其它技术的进步。 随着 Protobuf 的流行和 HTTP/2 使用的增加，gRPC 的采用也在增加。保持对gRPC的关注——虽然它不是万能的，但它在开发者社区流行中肯定是有原因的!

原文链接：

How HTTP/2 & Protobuf Paved the Way for gRPC - API Academy