（RPC通讯示意图）
为什么突然说到gRPC呢，其实以前就想说一说这个东西，也想尝试使用一下，一直没有机会，一直看我公众号的小伙伴肯定都知道，这几天一直在录制一个《eShopOnContainer微服务架构》系列，现在已经是8期了，里边涵盖了使用ASP.NETCore开发微服务的常用的基本的知识技能，具体的你可以看我的视频就行，B站也同步更新。
既然要说到了微服务，那肯定就离不开服务间调用，自然而然的就联系到了常用的一个框架——gRPC了，那今天就简单的说一说这个框架，也算是一个刚入门的，比较简单，后边我也会持续跟进讲解。
划 重 点
gRPC是什么？
用官网的一句话就是：A high-performance, open-source universal RPC framework。
要说gRPC，那就先说下什么的RPC框架，所谓RPC(remote procedure call 远程过程调用)框架实际是提供了一套机制，使得应用程序之间可以进行通信，而且也遵从server/client模型。使用的时候客户端调用server端提供的接口就像是调用本地的函数一样。
而gRPC就是一个由Google开源的，跨语言的，高性能的远程过程调用（RPC）框架。gRPC使客户端和服务端应用程序可以透明地进行通信，并简化了连接系统的构建。它使用HTTP/2作为通信协议，使用 Protocol Buffers 作为序列化协议。
可能第一次看到这种通信框架比较陌生，介绍的也比较官方和抽象，这里说一下另一个常用的服务间通讯的方案，你可能就明白了，那就是RESTFul风格的API，想必每个人都用过RestfulAPI吧，这里就先简单说下RestfulAPI，如果这个还不是很理解的话，建议死记硬背。
1、REST，即Representational State Transfer的缩写。直接翻译的意思是"表现层状态转化"。 2、它是一种互联网应用程序的API设计理念：URL定位资源，用HTTP动词(GET,POST,DELETE,PUT,DETC)描述操作，比如只需要知道/api/blog，你就知道了他的常见的CURD多种操作。
3、简单来说就是url地址中只包含名词表示资源，使用http动词表示动作进行操作资源，将软件和网络这两个领域一定程度上结合起来。
4、之所以灵活，是因为他很少参与业务逻辑，只定义资源操作。 看完了RestfulAPI，你应该就能明白gRPC是干什么的了吧。
那两者有什么区别呢，平时在前后端分离或者移动端需要后端api的场景下，经常使用Restful丰富的API，既然大家已经习惯并熟悉了Restful，为何还用gRPC呢？
PS：下边的内容我基本是摘抄于官网和网络，文末有参考连接，今天主要是介绍下如何操作代码，文字讲解不是重点。
为什么要使用gRPC？
问题：既然是server/client模型，那么我们直接用restful api不是也可以满足吗，为什么还需要RPC呢？
我这里简单说明下优缺点和比较，说说到底使用gRPC有什么好处。
gRPC 和 Restful API
gRPC和Restful API都提供了一套通信机制，用于server/client模型通信，而且它们都使用http作为底层的传输协议(严格地说, gRPC使用的http2.0，而Restful api则不一定)。
不过gRPC还是有些特有的优势，如下：
1、gRPC可以通过protobuf来定义接口，从而可以有更加严格的接口约束条件。 2、通过protobuf可以将数据序列化为二进制编码，这会大幅减少需要传输的数据量，从而大幅提高性能。 3、gRPC可以方便地支持流式通信.
场景与好处
