了解到 gRPC 还是刚开始工作的时候, 开发时会根据 proto 生成 ts 的 interface, 最近阅读了 gRPC 的实现代码, 学习了很多知识和理念所以来分享一下, 本篇理论知识主要来自于 gRPC 与云原生应用开发 一书。
随着微服务和云原生相关技术的发展，应用程序的架构模式已从传统的单体架构或分层架构转向了分布式的计算架构。尽管分布式架构本身有一定的开发成本和运维成本，但它所带来的收益是显而易见的。
在实现分布式应用程序时，我们必须考虑两个因素: 网络协议和传输载荷的编码。从最早的 RMI+Java 原生序列化，到 HTTP+JSON/XML 形式，但这种形式有其自身的局限性，比如其网络传输载荷低效、接口规范松散等。正是在这样的背景下，gRPC 应运而生，借助优异的性能和谷歌的大力推广，gRPC 受到众多大厂青睐。目前，gRPC 已经成为云原生计算基金会的孵化项目，并被广泛应用于众多开源项目和企业级项目中。
gRPC 最大的特点是高性能，HTTP/2+protocol buffers 的组合使其在性能方面具备了天然的优势，这也是 gRPC 广受欢迎的重要原因。但是，相对于更成熟稳定的 HTTP+JSON 组合，gRPC 的风险不容低估，比如其协议不够稳定，社区相对较小等，这都是在做技术选型的时候需要考虑的重要因素。正如我们所熟知的，从来就没有“银弹”，作为技术从业者，我们只能去分析和对比各种可用的技术，根据自身需求选择最合适的技术方案。
随着微服务架构和云原生架构的出现，为多种业务能力所构建的传统软件被进一步拆分为一组细粒度、自治和面向业务能力的实体，也就是微服务。因此，基于微服务的软件系统也需要借助进程间（或服务间、应用程序间）通信技术，将这些微服务通过网络连接起来。比如，对于一个采用微服务架构实现的在线零售系统，我们会发现它有多个互相连接的微服务，如订单管理、搜索、结账、配送等。与传统应用程序不同，微服务的细粒度特性使得网络通信连接的数量陡增。因此，不管应用哪种架构风格（传统架构或微服务架构），进程间通信技术都是现代分布式软件应用程序的重要组成部分。
当为现代原生应用程序和微服务实现同步的请求-响应风格的通信时，最常见和最传统的方式就是将它们构建为 RESTful 服务。也就是说，将应用程序或服务建模为一组资源，这些资源可用通过 HTTP 的网络调用进行访问和状态变更。但是，对大多数使用场景来说，使用 RESTful 服务来实现进程间通信显得过于笨重、低效并且易于出错。我们通常需要扩展性强、松耦合的进程间通信技术，该技术比 RESTful 服务更高效。这也就是 gRPC 的优势所在，gRPC 是构建分布式应用程序和微服务的现代进程通信风格。gRPC 主要采用同步的请求-响应风格进行通信，但在建立初始连接后，它完全可以以异步模式或流模式进行操作。