gRPC 的主要用途之一就是实现微服务以及服务之间的通信。在微服务的服务间通信中，gRPC 会与其他通信协议一同使用，并且 gRPC 服务通常会实现为多语言服务（由不同的语言实现）。为了进一步理解该技术，下面来看在线零售系统这样一个真实的场景，如图 3-5 所示，它是对前述内容的扩展。
该场景中有许多微服务，每个微服务都面向在线零售系统的特定业务能力。有一些服务的实现形式是 gRPC 服务，如 Product 服务；另外还有一些组合服务，如 Catalog 服务，它会调用底层的服务来构建其业务能力。如第 1 章所述，大多数同步消息可以使用 gRPC 来传递。如果有特定的异步消息场景，可能需要持久化消息，那么就可以使用事件代理或消息代理，如 Kafka、Active MQ、RabbitMQ 和 NATS。当需要将特定的业务功能暴露到外部时，可以使用传统的基于 REST 或 OpenAPI的服务或者 GraphQL 服务。因此，Catalog 和 Checkout 等服务消费基于 gRPC 的后端服务，同时暴露基于 REST 或 GraphQL 的外部接口。
在大多数实际用例中，这些面向外部的服务是通过 API 网关暴露的。这里可以应用各种非功能性的能力，如安全性、节流、版本化等。大多数这样的 API 使用像 REST 或 GraphQL 这样的协议，但还有一种可能，这种情况不太常见，那就是只要 API 网关支持暴露 gRPC 接口，gRPC就可以作为对外的接口。API 网关实现了横切性的功能，如认证、日志、版本化、节流和负载均衡。通过组合使用 API 网关与 gRPC API，可以将这些功能部署到核心 gRPC 服务之外。这种架构还有另外一个重要方面，那就是可以使用多种编程语言，但共享相同的服务契约，比如通过相同的 gRPC 服务定义来生成代码。这样一来，便可以根据服务的业务能力来选择适当的实现技术。
