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

高度可扩展
允许我们发送大量的数据
允许我们扩展和演进API

文章图片
案例学习：
在如今的技术趋势下，比较现代的方式是构建微服务。在本例中，我们学习一下构建航空售票系统的过程：

文章图片
上图展现了一个基于微服务的航空售票系统。在这里，有几个与这种类型的架构相关的关键点，我们需要注意：
微服务通常是由不同的语言构建的。那么我们可以说，预订管理服务可以基于.NET构建，支付处理可以是基于Java的，而乘客信息则是使用Node.js的。
每个服务都有不同的业务功能。
假设我们现在有使用不同语言编写的微服务，它们之间要互相进行交流。当这些微服务想要交换信息的时候，它们需要就一些事情达成共识，比如：
交换数据的API
数据格式
错误格式
访问速度限制
REST是最流行的构建API的方案。但是，这个决策取决于很多与我们的实现相关的架构考量：
设计数据模型的类型；
端点会是什么样子；
错误该如何进行处理；
一个客户端可以进行多少次调用；
授权是如何实现的。
考虑到这些因素，我们再来看一下gRPC和REST的差异：
gRPC
契约优先的API开发方式：契约（服务和消息）是在文件中定义的，它们是gRPC的核心。这是以一种语言中立的方式来定义API 。这些文件随后可以被其他编程语言用来生成代码（如强类型的客户端和消息类）。
内容是二进制的：HTTP/2和Protobuf是二进制的协议，内容是为计算机和高性能而设计的。
gRPC的设计隐藏了远程操作的复杂性。通过使用gRPC库和相关的代码生成，我们不需要关心路由、头信息和序列化等问题。当需要在客户端调用一个方法时，我们只需要调用对应的方法就可以了。
gRPC支持双向的异步流：某个gRPC调用建立流之后，客户端和服务器都能在任意时间向对方发送异步流。服务器流和客户端流（在这种情况下，只有响应或请求中的某一个是流）也是支持的。
gRPC是为分布式应用的高性能和高生产率而设计的。
RESTAPI
内容优先的API开发方式（URL、HTTP方法、JSON）：注重可读性和格式化。
内容是基于文本的（HTTP1.1和JSON），所以是人类可读的。这样造成的结果就是，它们非常适合进行调试，但是对性能并不友好。
更加强调HTTP 。我们需要考虑低级别的一些问题，这是一件好事儿，因为我们对HTTP请求有很大的控制权。
面向CRUD 。
最广泛的受众：每台计算机都能使用HTTP/1.1和JSON ，易于上手。
基于这些对比，我们可以看到这两种方式各有其优点。但是，我们可以看到， gRPC为基于微服务的场景提供了一组强大的特性。
使用gRPC创建一个服务器-客户端应用
在开始编码之前，我们在自己的计算机上安装以下软件：
.NETCore5SDK
VisualStudioCode
软件安装完成之后，我们需要创建项目结构（在本文中，我们将在终端/命令行中直接使用dotnet命令）：
我们还需要配置SSL信任：
接下来，我们在VSCode打开这个新项目，看一下都创建了哪些内容。我们可以看到，我们自动有了如下的内容：
Protos文件夹
Services文件夹
在Protos文件夹中，我们有一个greet.proto文件。正如我们在前文中所提到的， .proto能够以语言中立的方式来定义API 。