gRPC远程调用
gRPC是一个现代的高性能框架，它发展了古老的远程过程调用（RPC）协议。
什么是gRPC？
gRPC是一个现代的高性能框架，它发展了古老的远程过程调用（RPC）协议。在应用程序级别，gRPC简化了客户端和后端服务之间的消息传递。gRPC源自Google，是开源的，并且是云原生产品的 Cloud Native Computing Foundation（CNCF）生态系统的一部分。CNCF认为gRPC是一个孵化项目。孵化意味着最终用户在生产应用程序中使用了该技术，并且该项目有大量的参与者。
典型的gRPC客户端应用程序将公开实现业务操作的本地进程内函数。在后台，该本地功能调用了远程计算机上的另一个功能。看起来像是本地调用，实质上变成了对远程服务的透明的进程外调用。RPC管道抽象了计算机之间的点对点网络通信，序列化和执行。
在云原生应用程序中，开发人员经常跨编程语言，框架和技术工作。这种互操作性使消息契约和跨平台通信所需的管道复杂化。gRPC提供了抽象这些问题的“统一水平层”。开发人员在其本机平台上的代码侧重于业务功能，而gRPC处理通信管道。
gRPC在包括Java，JavaScript，C＃，Go，Swift和NodeJS在内的大多数流行开发堆栈中提供全面的支持。
gRPC的好处
gRPC使用HTTP / 2作为其传输协议。与HTTP 1.1兼容时，HTTP / 2具有许多高级功能：
-
一种用于数据传输的二进制框架协议-与基于文本的HTTP 1.1不同。
-
多路复用支持通过同一连接发送多个并行请求-HTTP 1.1将处理一次限制为一个请求/响应消息。
-
双向全双工通信，用于同时发送客户端请求和服务器响应。
-
内置流式传输使请求和响应能够异步流式传输大数据集。
-
标头压缩可减少网络使用量。
gRPC是轻量级且高性能的。它可以比JSON序列化快8倍，而消息却要小60-80％。用Microsoft Windows Communication Foundation（WCF）的话来说，gRPC的性能超过了高度优化的NetTCP绑定的速度和效率。与支持Microsoft堆栈的NetTCP不同，gRPC是跨平台的。
协议缓冲区
gRPC包含一种称为协议缓冲区的开源技术。它们提供了一种高效且与平台无关的序列化格式，用于序列化服务之间相互发送的结构化消息。开发人员使用跨平台接口定义语言（IDL），为每个微服务定义服务合同。合同以基于文本的.proto文件的形式实现，描述了每种服务的方法，输入和输出。相同的合同文件可用于在不同开发平台上构建的gRPC客户端和服务。
使用protobuf编译器proto文件，protoc为目标平台生成客户端代码和服务代码。该代码包括以下组件：
客户端和服务共享的强类型对象，代表消息的服务操作和数据元素。
具有远程gRPC服务可以继承和扩展的必需网络管道的强类型基类。
客户端存根，其中包含调用远程gRPC服务所需的管道。
在运行时，每条消息都被序列化为标准的Protobuf表示形式，并在客户端和远程服务之间交换。与JSON或XML不同，Protobuf消息被序列化为已编译的二进制字节。
可以从Microsoft体系结构站点上获得的《用于WCF开发人员的gRPC》一书深入介绍了gRPC和协议缓冲区。
.NET中的gRPC支持
gRPC已集成到.NET Core 3.0 SDK和更高版本中。以下工具支持它：
Visual Studio 2019 16.3版或更高版本，已安装Web开发工作负载。
Visual Studio程式码
dotnet CLI
该SDK包含用于端点路由，内置IoC和日志记录的工具。开源Kestrel Web服务器支持HTTP / 2连接。图4-20显示了一个Visual Studio 2019模板，该模板为gRPC服务构建骨架项目。请注意.NET Core如何完全支持Windows，Linux和macOS。
gRPC使用
在以下情况下支持gRPC：
-
同步后端微服务到微服务通信，需要立即响应才能继续处理。
-
需要支持混合编程平台的多语言环境。
-
在性能至关重要的地方，低延迟和高吞吐量通信。
-
点对点实时通信-gRPC可以实时推送消息而无需轮询，并且对双向流具有出色的支持。
-
网络受限的环境–二进制gRPC消息始终小于等效的基于文本的JSON消息。
在撰写本文时，gRPC主要与后端服务一起使用。现代浏览器无法提供支持前端gRPC客户端所需的HTTP / 2控制级别。就是说，对带有.NET的gRPC-Web的支持使从使用JavaScript或Blazor WebAssembly技术构建的基于浏览器的应用程序进行gRPC通信成为可能。gRPC-Web使ASP.NET Core gRPC应用程序能够支持浏览器应用程序中的gRPC功能：
-
强类型代码生成的客户端
-
紧凑的Protobuf消息
-
服务器流
gRPC实施
Microsoft的微服务参考架构eShop on Containers显示了如何在.NET Core应用程序中实现gRPC服务。图4-22给出了后端体系结构。
在上图中，请注意eShop如何通过公开多个API网关来拥抱后端的前端模式（BFF）。我们在本章前面讨论了BFF模式。请密切注意位于Web-Shopping API网关和后端Shopping微服务之间的Aggregator微服务（灰色）。聚合器从客户端接收单个请求，将其分配给各种微服务，对结果进行聚合，然后将其发送回发出请求的客户端。这样的操作通常需要同步通信以产生即时响应。在eShop中，使用gRPC执行来自聚合器的后端调用，如图所示。
gRPC通信需要客户端和服务器组件。在上图中，请注意Shopping Aggregator如何实现gRPC客户端。客户端对后端微服务进行同步gRPC调用（红色），每个后端微服务都实现一个gRPC服务器。客户端和服务器都可以利用.NET Core SDK内置的gRPC管道。客户端存根提供了调用远程gRPC调用的管道。服务器端组件提供了gRPC管道，自定义服务类可以继承和使用。
公开RESTful API和gRPC通信的微服务需要多个端点来管理流量。您将打开一个端点，该端点侦听RESTful调用的HTTP流量，并侦听gRPC调用的另一个流量。必须为gRPC通信所需的HTTP / 2协议配置gRPC端点。
尽管我们努力使微服务与异步通信模式脱钩，但是某些操作需要直接调用。gRPC应该是微服务之间直接同步通信的主要选择。它基于HTTP / 2和协议缓冲区的高性能通信协议使其成为理想的选择。