1. 概述
促成了 RPC 发展的是微服务概念的兴起。单体应用体量过大造成的代码管理问题，通过拆分公共模块或者功能模块为独立个体降低了开发难度和功能管理难度。
Rest Api 也能满足上述不同服务个体间的联系，但是通过 Get 或者 post 方式的 Http 请求天生带来的问题是大量无用的冗余数据和连接处理带来了性能不必要的损失。尽管通过类似 socket 的进程间通信方式也能解决上述问题，但是 socket 的自由度除了带来了使用上的方便，必然带来了一个问题，那就是缺乏统一的数据格式的约束造成的协议过于个性化，从而难以在大型应用中统一所有的使用方式。而统一 socket 协议除了技术上的难题，还有不同人对于 socket 的理解而造成的使用方式的差异化。
个人观点是，RPC 是为了弥补 Rest Api 在高性能的远程调用场景下的不足，通过使用 h2 优化了连接，并通过使用 protobuf 等数据格式压缩了原本采用的 JSON 或 XML 等数据格式，最终实现了协议统一的条件下，同时带来效率和性能的提升。
2. GRPC
GRPC 是谷歌开源的一套 RPC 方案。gRPC RPCRuntime 层基于 HTTP/2 设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性。
GRPC的调用方式可以归纳为4种：
- Unary RPC: 一元RPC
- Server-Side streaming RPC: 服务端流式RPC
- Client-Side streaming RPC: 客户端流式RPC
- Bidirectional streaming RPC : 双向流式RPC