介绍
我们在之前的文章中，连续使用四篇文章的篇幅介绍过 gRPC 的相关知识，如果有读者朋友还未阅读，可以按需翻阅一下前面的四篇关于 gRPC 的文章。
本文我们介绍 Golang 语言微服务架构的软件系统为什么选择使用 gRPC 作为分布式应用之间的通信协议。
进程间通信
微服务架构的软件系统由多个分布式应用组成，进程间通信技术将分布式应用相互连接。进程间通信一般包含两种实现方式，其中一种是同步的请求和响应，另外一种是异步的消息传递。
在我们微服务项目开发中，进程间通信的传统方式是使用 RESTful 服务的方式实现同步的请求和响应。实际上，通过 HTTP 和 JSON 将应用程序构建为 RESTful 服务已经是构建微服务的标准方法。
但是随着微服务数量增多，RESTful 服务的方式实现进程间通信越来越低效，因为 RESTful 服务使用文本传输，微服务之间缺乏强类型接口，并且 REST 架构不能强制应用程序使用等问题，所以 RESTful 服务的方式已经不能满足需求。
基于以上原因，gRPC 进程间通信应运而生，gRPC 扩展性强、松耦合，比 RESTful 服务更高效，所以越来越多的公司将进程间通信协议替换为 gRPC。
03
gRPC 的优点和缺点
优点：
gRPC 进程间通信与 RESTful 服务不同的是，它没有使用文本传输，而是使用基于 protocol buffers 的二进制协议，二进制传输的效率远远高于文本传输的效率，并且 gRPC 是基于 HTTP/2 实现的 protocol buffers 协议，从而使进程间通信更加高效。
gRPC 与 RESTful 服务不同的是，gRPC 先要定义服务接口，然后再去实现细节。因此，gRPC 可以约束多语言开发的分布式应用程序，使分布式应用程序更加可靠，可扩展。
gRPC 使用 protocol buffers 定义服务接口，可以支持多种语言，并且强制约束了不同语言的分布式应用程序之间进程间通信使用的类型，可以使分布式应用程序更加稳定。
缺点：
gRPC 也不是十全十美，在项目开发中，有时需要给三方提供接口服务，尤其是外部公司的三方，因为 gRPC 具有接口契约和强类型等特点，会限制面向外部服务的灵活性，所以 gRPC 可能不适合面向外部的服务。
在面向浏览器和 APP 应用等客户端接口开发时，因为它们对 gRPC 的支持还处于初级阶段，大部分公司还是选择使用 REST 接口进行通信，所以我们在选择进程间通信协议时，还是要根据实际使用场景做出最佳选择。
04
总结
本文我们介绍目前进程间通信使用比较多的 RESTful 服务方式和 gRPC 方式，随着微服务架构的服务中，分布式服务数量越来越多的背景下，RESTful 服务的方式已经不能满足需求。
我们通过简述 RESTful 服务方式的局限性，和 gRPC 的优势，介绍了微服务架构选择 gRPC 通信协议的原因。
推荐阅读：
参考资料：
https://grpc.io/docs/what-is-grpc/faq/
