如何基于gRPC沟通微服务框架

本文我们来讲解一下如何使用 gRPC构建微服务，gRPC是一个开源框架，可用于构建可扩展且高性能的微服务并创建服务之间的通信。

背景

随着企业越来越多地转向微服务，对构建这些微服务的低延迟和可扩展框架的需求也在增加。为了满足这一需求，各种工具和框架提供商正加快满足微服务需求。同时从构建大型微服务应用程序的经验中学习，技术专业人士分享他们对可重用组件的知识，以便其他人可以构建具有相同规模和性能的架构。

什么是 gRPC

gRPC 是一个开源框架（由 Google 创建），是一个通用的 RPC 框架，用于大规模构建具有高性能的网络应用程序。实现有多种语言版本，并且支持跨平台通信。

使用场景

gRPC 非常适合服务与服务之间的 RPC 通信。在这里，我们将使用 Java 来实现微服务和相关框架，让它的功能更齐全。为了让其他服务可以访问它，我们将创建一个包装 REST 服务，这个服务将使用 gRPC 客户端与 gRPC 服务进行通信。

准备工作

我们需要设置一个基础环境来构建和运行示例。基本要求是安装 Java 和 Maven。gRPC 工具和服务器运行时库等其他依赖项，将在构建过程中自动下载。有关构建应用程序所需的核心依赖项，请参阅下面的代码。

<dependency>
    <groupId>io.github.lognet</groupId>
    <artifactId>grpc-spring-boot-starter</artifactId>
    <version>4.5.0</version>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>

<dependency>
    <groupId>org.mapstruct</groupId>
    <artifactId>mapstruct</artifactId>
    <version>${mapstruct.version}</version>
</dependency>

核心功能

gRPC 基本上是一种与平台和编码无关的协议。这意味着，您可以使用任何类型的编码，如二进制、JSON、XML 等，但推荐的方法是使用“protobuf”，它使用专门的序列化/反序列化机制支持二进制编码。可插拔设计允许用户对其进行扩展以支持所需的平台和堆栈。

protobuf 的核心构造是 proto IDL（接口定义语言），定义了消息类型和服务定义。它还提供了为所需平台生成模型类和服务接口的工具。

消息类型

我们可以从在.proto文件中定义消息类型的 proto 定义开始。看下面的例子。

message AccountProto {
     int32 accId = 1;
     string accName = 2;
     string accBalance = 3;
     bool status = 4;
     ...
}

有关数据类型和关键字的完整参考，请参阅proto3文档。

Protobuf 提供了一种工具，可以根据适用于您的平台/编程语言的消息定义为模型类生成代码。以下命令将根据给定的消息定义在 Java 中生成account类。

$ > protoc -I=proto-demo --java_out=proto-demo account.proto

服务定义

gRPC 服务定义是一组需要对定义的消息类型执行的操作。这些操作可以采用以下四种通信形式之一：

1. 单通道 RPC — 它是最简单的通信形式。它本质上是同步的，允许用户以阻塞模式发送请求并等待响应，直到服务器完成处理。
2. 流式 RPC — 在这种形式中，客户端一次性发送数据，但服务器以流的形式返回响应。
3. 客户端流式 RPC — 与服务器流式传输不同，在这种形式中，客户端以流的形式发送请求的数据，服务器将数据作为一个整体返回。

4. 双向流式 RPC — 在这种形式中，服务器和客户端都支持根据请求和响应流式传输数据。

   具有标准 CRUD 操作的消息类型的示例服务定义将采用以下输入：

service AccountService {
    rpc GetAccount (google.protobuf.Int32Value) returns (AccountProto);
    rpc GetAllAccounts (google.protobuf.Empty) returns (stream AccountProto);
    rpc CreateAccount (AccountProto) returns (AccountProto);
    rpc UpdateAccount (AccountProto) returns (AccountProto);
    rpc DeleteAccount (google.protobuf.Int32Value) returns (google.protobuf.Empty);
}

gRPC-Java 实现提供的扩展工具有助于根据域逻辑和服务器存根生成用户需要实现的服务接口，客户端将使用这些存根调用已部署的服务。

$ > protoc -I=grpc-demo\src\main\proto --java_out=grpc-demo\src\main\proto account.proto

标准服务器和客户端

gRPC-Java 库提供了一个响应式服务器实现（基于 Netty）来部署您的服务和一个阻塞/非阻塞客户端实现来连接您的服务和其他服务。

您需要注册您的服务实现并以编程方式启动服务器。

server = ServerBuilder.forPort(port), .addService(new GreeterImpl()).build().start();

在此处找到 GitHub 参考。

要连接到部署在基于 Netty 的 gRPC 服务器上的服务，您需要创建一个消息通道并将其与生成的服务器存根连接以进行调用。

ManagedChannel channel = ManagedChannelBuilder.forTarget(target).usePlaintext().build();
blockingStub = GreeterGrpc.newBlockingStub(channel);
HelloRequest request = HelloRequest.newBuilder().setName(name).build();
HelloReply response = blockingStub.sayHello(request); 

在此处找到 GitHub 参考。

网络客户端

还有一个 gRPC Web 模块，允许 Web 客户端无缝访问您的 gRPC 服务。他们的早期版本支持通过反向代理连接 Web 客户端，但现在可以在没有中间代理的情况下进行。

另一种方法是使用 REST/GraphQL 协议将包装服务层暴露给面向外部的世界，并通过 gRPC 客户端连接。

数据映射和持久性

我们可能需要在其之上添加另一层，以使用 Hibernate 等数据访问库创建功能齐全的域服务。与 Hibernate 或任何数据库一样，需要以某种方式修饰所需的实体，而这对于 protobuf 模型生成的模型可能不可行。因此，我们可能需要一些映射逻辑来将模型类转换为实体类。一个这样好的库是 MapStruct，它基于 bean 约定进行自动映射。我们只需要提供映射接口：

@Mapper
public interface AccountProtoMapper {
        Account map(AccountProto accountProto);
        AccountProto map(Account account);
}

第三方支持

为了进一步简化整个构建和运行环境，有一些流行的第三方 Maven 插件和库也有帮助。

1. 运行与 Build 集成的 Proto Tool

协议缓冲区 Maven 插件（由 Xolstice 提供）运行 proto 工具及其扩展，以及从.proto文件构建和生成源代码。它还附加了 .proto文件作为项目的资源。请参阅示例配置以生成 Java 代码。

<configuration>
    <protocArtifact>com.google.protobuf:protoc:${protoc.version}:exe:${os.detected.classifier}</protocArtifact>
    <pluginId>grpc-java</pluginId>
    <pluginArtifact>io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
</configuration>

参考可以在这里找到。

2. 生成映射器类

MapStruct 库支持生成消息类型的映射器类，这些映射器类可以将消息从/到类的实体。它提供了一个注解处理器，通过在构建时分析指定的注解来生成一个映射器类。Maven编译插件参考下面的配置。

<configuration>
        <annotationProcessorPaths>
               <path>
                       <groupId>org.mapstruct</groupId>
                       <artifactId>mapstruct-processor</artifactId>
                       <version>${mapstruct.version}</version>
               </path>
        </annotationProcessorPaths>
</configuration>

3.自动启动gRPC服务器并注册服务实现

默认情况下，gRPC 服务器不会与 web 服务器（在本例中为 Netty）一起启动。此外，它需要在服务器启动之前注册所有 gRPC 服务。LogNet 的 gRPC Spring Boot 会自动扫描所有带有@GRpcService注解的类，并向服务器构建器注册服务定义。构建服务器后，它会在 Spring 应用程序属性中配置的端口上自动启动 gRPC 服务器。

除了注册服务和启动服务器外，它还支持自动配置的安全、健康检查和服务发现。有关详细信息，请参阅此处。

GitHub 上提供了上述方法的完整示例实现。

差异化

• 谷歌构建 gRPC 是出于从零开始构建大规模微服务的学习需求。大多数流行的微服务框架仍然缺乏对性能和跨平台支持的要求，因为没有大型系统可以在单个堆栈和单个编码中构建。
• 最受欢迎的是对 HTTP/2 的支持，它仍然是许多提供商的路线图。它为在单个 TCP 连接上使用多路复用非阻塞数据流的二进制线路传输提供了优势。进一步支持标头压缩，它提供了额外的性能优势。
• 除了支持 protobuf 作为主要编码机制外，它还增加了对基于 JSON 的服务的支持，这些服务可以很容易地被低端客户端使用。虽然 protobuf 是实施 gRPC 的推荐方式，但 Google 增加了对 FlatBuffers 的支持，并增加了内部和整个行业的采用率。
• 初始版本支持通过反向代理（如基于 Envoy 和 Ngnix 的系统）公开 gRPC 服务。gRPC Web 的最新发展弥补了这一差距，并通过跨 JavaScript 库采用 HTTP/2 增加了对向 Web 客户端公开 gRCP 服务的支持。进一步的开发正在进行中，以增加对 Angular 和 React 等流行 Web 框架的支持。

• 借助功能齐全的开发堆栈，它还为单元测试助手（如InProcessServer和InProcessChannelBuilder.

采用

• Google 在其内部工具和平台上使用它，例如 Bigtable、Pub/Sub、Speech 和 TensorFlow。
• CoreOS 是 gRPC 的早期采用者，并在其服务发现工具和容器引擎中增加了支持。
• Microsoft 是 gRPC 的高级采用者，并增加了对其 Web API 和构建工具的支持，以简化开发人员无缝构建服务的工作。
• 现在，越来越多的项目在整个行业中使用它，例如 Docker、Square、Netflix 和 Cisco 等开源开发人员。

替代方法

除了构建 gRPC 之外，Google 的应用程序还提供了文章中提到的工具/库和 Spring Boot 启动框架。一些专门的微服务框架为 gRPC 服务实现提供了开箱即用的支持。

1. Quarkus gRPC
2. Asp.NET gRPC
3. Akka gRPC
4. Salesforce gRPC