为了理解 Google 开发 gRPC 的原因，我们先简单回顾一下API设计的时间表。
RPC 是设计和构建 API 的最古老方法之一。RPC 允许您编写代码，就好像它会在本地计算机上运行一样，即使您实际上可能调用在另一台机器上运行的服务（通常在您的本地网络上）。
实际上，这使得开发人员能够使用直接操作（如 SendUserMessages、addEntry 等），而不必考虑网络详细信息。 RPC消息轻量、高效，但是也和底层系统紧密耦合。 这使得它们难以集成和更改，并且更容易泄露有关系统的详细信息。
当引入REST API架构时，它通过提供使用通用HTTP方法（如 GET、POST、PUT 和 DELETE）访问数据和资源的统一方式解决了其中的一些挑战。 尽管 REST 简化了数据访问，但 API 通常会返回比所需更多的元数据。 REST API 还需要更多有关网络的信息（例如，向哪里发送请求），因此它们不像 RPC 那样轻量和高效。
通过采用更新的技术，gRPC 更新了旧的 RPC 方法，使其具有互操作性且更加高效。 如今，在开发微服务架构的 API 时，这是一个有吸引力的选择。
gRPC 的一些优点包括：
总体而言，gRPC 提供了一个高性能、灵活的框架，非常适合高度分布式微服务架构中的服务间通信。
gRPC 的优势和好处很大程度上源于采用了两种技术：
gRPC 使用协议缓冲区（或Protobufs ）来定义服务和消息，而不是 XML 或 JSON。 它是一种与语言无关的机制，用于序列化服务之间相互发送的结构化消息。
与 REST API 的OpenAPI 规范的概念类似，gRPC 中的 API 契约是在 .proto 文本文件中实现的，开发人员在其中定义他们希望如何构造数据。 然后，protoc 编译器会自动将 .proto 文本文件编译成任何受支持的语言。 在运行时，消息被压缩并以二进制格式发送。
这有两个主要优点：
传统上，REST API 使用 HTTP/1.1 作为传输层。 虽然 REST API 也可以通过 HTTP/2 传递，但 gRPC 对 HTTP/2 的独家使用带来了一些关键优势。 其中一个优点是能够使用二进制发送通信。 此外，HTTP/2 支持处理多个并行请求的能力，而不是一次处理一个请求。 通信也是双向的，这意味着单个连接可以同时发送请求和响应。
总的来说，这提高了性能并降低了网络利用率，这在繁忙的微服务架构中尤其有价值。 但也存在一些限制。 现代网络浏览器通常不支持 HTTP/2，因此您可能需要使用 NGINX 之类的反向代理来传递应用。
如今，REST 是最主流的 API 设计风格，因此它提供了一个有用的参考点来与 gRPC 进行比较。REST 和 gRPC 都是为 Web应用和微服务构建 API 的有效方法，其中一种并不一定比另一种更好。 也就是说，了解它们的主要区别对于选择最佳工具是很有帮助的。
gRPC 和 REST 之间的一些主要区别属于以下类别：
虽然 REST API 可以利用 HTTP/2，但 RESTful 服务传统上使用基于文本的 HTTP/1.1 作为传输层。gRPC 专门使用 HTTP/2，这是一种更高效的二进制协议，并且支持通过单个 TCP 连接进行标头压缩和多路复用等功能。
REST API 通常使用 JSON 作为发送和接收数据的数据格式。 JSON 是基于文本的，易于读写，并且得到广泛支持。gRPC API 使用 Protobufs，它采用二进制格式，可提供更小的负载和更快的交互。 但是，Protobuf 本身并不容易读取。
REST API 支持请求-响应模型，但对流式传输的支持有限。 相比之下，gRPC API 通过 HTTP/2 交付，并支持多种通信模式，包括一元（请求-响应）、服务器流、客户端流和双向流。
REST 是一种以资源为中心的模型，支持 GET、POST、PUT 和 DELETE 等标准 HTTP 方法。 每个请求必须包含处理该请求所需的所有信息。 此外，API 契约通常使用 OpenAPI 规范编写，客户端和服务器的编码作为单独的步骤处理。 相比之下，gRPC 是一个以服务为中心的模型，其中消息和服务在 .proto 文件中定义。 该文件可用于为 API 客户端和服务器生成代码。
REST 可能比较慢，因为它通过 HTTP/1.1 传输基于文本的数据。 每个请求都需要一次 TCP 握手，这可能会引入一些延迟。gRPC 通过 HTTP/2 支持多个流，因此多个客户端可以同时发送多个请求，而无需建立新的 TCP 连接。 它还利用了 HTTP/2 的功能，例如标头压缩。
REST 使用标准 HTTP 状态代码进行错误处理。 相比之下，gRPC 提供了更精细的来定义错误状态代码并确保它们的一致性。 默认情况下，gRPC 模型非常有限，但最常见的扩展方法是使用Google 开发的更丰富的错误模型。
REST 几乎受到每种语言的广泛支持，但没有提供内置的代码生成功能。 实施完全留给开发人员。 gRPC 凭借其 protoc 编译器，为多种编程语言提供本机代码生成。
总而言之，gRPC 和 REST 之间的选择取决于你需要完成的任务。gRPC 为服务在分布式应用中进行通信提供了一种高效、高性能的方法。 也就是说，它不能被 Web 浏览器和其他客户端直接读取，并且需要API 网关或 NGINX 等反向代理才能与前端客户端交互。 对于属于事件驱动的微服务架构的内部 API 来说，它是一个绝佳的选择。
另一方面，REST 几乎在所有语言中都被广泛采用和支持。 由于数据是使用 JSON 或 XML 交换的，因此它是人类和机器可读的。 此外，它的学习曲线较低，并且受到许多网络浏览器的支持，这使其成为公开 API 的理想选择。
gRPC 是微服务架构中通信的最佳选择之一。 这部分是由于性能，但也是因为其在语言支持方面的灵活性。 开发人员可以轻松构建和生成以他们喜欢的语言运行的 gRPC 客户端和服务器。 由于 gRPC 以二进制格式描述 API 契约，因此微服务可以独立于构建它们所使用的语言进行通信。
最常见的基于 gRPC 的微服务架构之一是将 API 网关置于微服务前面，然后通过 gRPC 处理所有内部通信。API 网关处理来自 HTTP/1.1 的传入请求，并将它们作为通过 HTTP/2 的 gRPC 请求代理到微服务。
随着 gRPC 的采用不断增长，开发人员和安全运营团队需要确保实施有效的安全解决方案。 由于 gRPC 消息采用二进制格式，因此对于需要看到基于 ASCII 的通信的设备和工具可能会出现问题。
gRPC API 也容易受到许多最常见的 API 安全威胁。 在基于 gRPC 的架构中，访问控制、加密和运行时保护等标准 API 安全实践同样重要。
gRPC应用和 API 需要采取整体的安全方法。 保护 gRPC 的一些最佳实践包括：
最终，您应该验证您的API 网关、 Web应用防火墙(WAF) 和其他 API 管理和安全工具是否能够承担保护生产中的 gRPC应用和 API 的任务。 他们应该能够导入每个服务的 .proto 文件并使用它来为 gRPC应用和 API 应用安全保护。
NGINX 提供各种免费资源，以满足您在 gRPC 旅程中的任何阶段的需求。