gRPC 与.NET 入门作者|MohamadLawand译者|张卫滨策

作者|MohamadLawand
译者|张卫滨
策划|丁晓昀
从本质上来讲， API就是服务器和客户端之间的一个协议，指定了服务器如何基于客户端的请求提供特定的数据。

文章图片
在构建API的时候，我们会想到不同的技术。根据需求不同，我们所选择的开发API的技术也会随之发生变化。在目前的这个时代，主要有两种用于创建API的技术：
gRPC
REST
这两种技术都使用HTTP作为传输机制。尽管使用了相同的底层传输机制，但是它们的实现却是完全不同的。
我们先对比一下这两项技术，然后再深入了解gRPC 。
REST
REST是一套架构约束，而不是协议或标准。 API开发人员可以使用各种方式来实现REST 。
为了让一个API被认作是RESTful的，我们需要遵循一些约束条件：
客户端-服务器端架构：所有的请求必须使用HTTP作为传输机制；
无状态：API应该是无状态的，这意味着，服务器不应该在服务器端存储任何关于客户端会话的状态。从客户端到服务器的每个请求都必须要包含所有必要的信息以理解该请求。服务器不能使用任何在服务器端所存储的上下文。
可缓存：客户端-服务器间流过的所有数据必须都是可缓存的，这意味着它们可以被存储起来，以便于后续检索和使用。
统一接口：客户端和服务器之间必须有一个接口，以便于信息以标准的形式进行传输。
分层的系统：在客户端的请求以及服务器端的响应之间所涉及的所有服务器必须要按照它们的职责来进行组织，组织方式不能影响到请求或响应。
gRPC
gRPC构建在RPC（远程过程调用， RemoteProcedureCall）协议坚实的基础之上，它也进入了API的领域之中。 gRPC是由谷歌开发的免费、开源的框架，它使用HTTP/2进行API通信，为API的设计者隐藏了HTTP实现。
gRPC有很多特征，所以不管是在微服务还是在web/移动API通信方面，都使其成为下一代web应用的基础模块：
互操作性（Interoperability）：不管当前的HTTP版本是什么，无论基础设施如何变化（比如，从HTTP2升级到HTTP3），协议必须能够适应和改变。
分层架构：技术栈的核心面必须能够独立地演进和升级，而不会破坏任何使用它的应用程序。
载荷的中立性（Agnostic）：不同的服务可能会需要不同的消息类型和编码，比如Protobuf（Protocolbuffer）、JSON、XML等。 gRPC支持所有的这些格式，并且能够通过利用可插拔的压缩机制来压缩载荷。
流：gRPC允许将大的数据集以流的方式从服务器中转到客户端，反之亦然。
可插拔（Pluggable）：gRPC支持按需插入不同的功能和服务以满足我们的需求，比如健康检查、故障恢复和负载均衡。框架实现提供了扩展点，允许我们插入这些功能。
与docker和kubernetes类似， gRPC是云原生基金会（CNCF）的一部分。
简而言之， gRPC的好处包括：
现代、快速
开源
利用HTTP/2
语言中立
易于添加认证、日志
为了使用gRPC：
我们需要使用Protobuf（ProtocolBuffer）来定义消息和服务
gRPC代码会自动生成，我们则需要提供具体的实现。
不管是在服务器端还是在客户端，文件都能支持12种不同的语言。
默认情况下， gRPC会使用谷歌开源的ProtocolBuffers机制来进行结构化数据的序列化：
它是语言中立的
能够为任何现代编程语言生成代码
数据传输是二进制和高效的