现代软件应用程序很少是孤立运行的，相反，它们会通过计算机网络连接在一起，并且以互相传递消息的方式进行通信和协调。因此，现代软件系统是分布式软件应用程序的集合，这些应用程序在不同的网络位置运行，并且运用不同的通信协议在彼此间传递消息。例如，一个在线零售软件系统会由多个分布式应用程序组成，如订单管理应用程序、商品目录应用程序和数据库等。为了实现在线零售系统的业务功能，这些分布式应用程序需要相互连接。
微服务架构
微服务架构将软件应用程序构建为一组独立、自治（独立开发、部
署和扩展）、松耦合、面向业务能力 的服务 。
随着微服务架构和云原生架构的出现，为多种业务能力所构建的传统软件系统被进一步拆分为一组细粒度、自治和面向业务能力的实体，也就是微服务。因此，基于微服务的软件系统也需要借助进程间（或服务间、应用程序间）通信技术，将这些微服务通过网络连接起来。比如，对于一个采用微服务架构实现的在线零售系统，我们会发现它有多个互相连接的微服务，如订单管理、搜索、结账、配送等。与传统应用程序不同，微服务的细粒度特性使得网络通信连接的数量陡增。因此，不管采用哪种架构风格（传统架构或微服务架构），进程间通信技术都是现代分布式软件应用程序的重要组成部分。
进程间通信通常会采用消息传递的方式来实现，要么是同步的请求–响应风格，要么是异步的事件驱动风格。在同步通信风格中，客户端进程通过网络发送请求消息到服务器进程，并等待响应消息。在异步的事件驱动风格中，进程间会通过异步消息传递进行通信，这个过程会用到一个中介，也就是事件代理（event broker）。我们可以根据业务场景，选择希望实现的通信模式。
当为现代云原生应用程序和微服务实现同步的请求–响应风格的通信时，最常见和最传统的方式就是将它们构建为 RESTful 服务。也就是说，将应用程序或服务建模为一组资源，这些资源可以通过 HTTP 的网络调用进行访问和状态变更。但是，对大多数使用场景来说，使用RESTful 服务来实现进程间通信显得过于笨重、低效并且易于出错。我们通常需要扩展性强、松耦合的进程间通信技术，该技术比 RESTful 服务更高效。这也就是 gRPC 的优势所在，gRPC 是构建分布式应用程序和微服务的现代进程间通信风格（本章稍后会对比 gRPC 和 RESTful 服务）。gRPC 主要采用同步的请求–响应风格进行通信，但在建立初始连接后，它完全可以以异步模式或流模式进行操作。
本章将介绍 gRPC 的定义以及发明这项进程间通信协议的主要动机，其间会借助一些实际的应用场景来深入探讨 gRPC 的核心构成要素。另外，本章还涉及进程间通信技术本身及其演化过程，熟悉这一点非常重要，有助于理解 gRPC 试图解决的关键问题。本章将逐一介绍这些技术，并对它们进行对比。下面先来看一下 gRPC 的定义。
