这篇文章本来要在年前和小伙伴们见面，但是因为我之前的 Mac 系统版本是 10.13.6，这个版本比较老，时至今天在运行一些新鲜玩意的时候有时候会有一些 BUG（例如运行最新版的 Nacos 等），运行 gRPC 的插件也有 BUG，代码总是生成有问题，但是因为系统升级是一个大事，所以一直等到过年放假，在家才慢慢折腾将 Mac 升级到目前的 13.1 版本，之前这些问题现在都没有了，gRPC 的案例现在也可以顺利跑起来了。
所以今天就来和小伙伴们简单聊一聊 gRPC。
1. 缘起
我为什么想写一篇 gRPC 的文章呢？其实本来我是想和小伙伴们梳理一下在微服务中都有哪些跨进城调用的方式，在梳理的过程中想到了 gRPC，发现还没写文章和小伙伴们聊过 gRPC，因此打算先来几篇文章和小伙伴们详细介绍一下 gRPC，然后再梳理微服务中的跨进程方案。
2. 什么是 gRPC
了解 gRPC 之前先来看看什么是 RPC。
RPC 全称是 Remote Procedure Call，中文一般译作远程过程调用。RPC 是一种进程间的通信模式，程序分布在不同的地址空间里。简单来说，就是两个进程之间互相调用的一种方式。
gRPC 则是一个由 Google 发起的开源的 RPC 框架，它是一个高性能远程过程调用 (RPC) 框架，可以在任何环境中运行。gRPC 通过对负载均衡、跟踪、健康检查和身份验证的可插拔支持，有效地连接数据中心内和数据中心之间的服务。
在 gRPC 中，客户端应用程序可以直接调用部署在不同机器上的服务端应用程序中的方法，就好像它是本地对象一样，使用 gRPC 可以更容易地创建分布式应用程序和服务。与许多 RPC 系统一样，gRPC 基于定义服务的思想，指定基于参数和返回类型远程调用的方法。在服务端侧，服务端实现接口，运行 gRPC 服务，处理客户端调用。在客户端侧，客户端拥有存根（Stub，在某些语言中称为客户端），它提供与服务端相同的方法。
gRPC 客户端和服务端可以在各种环境中运行和相互通信 – 从 Google 内部的服务器到你自己的桌面 – 并且可以使用 gRPC 支持的任何语言编写。因此，你可以轻松地用 Java 创建 gRPC 服务端，使用 Go、Python 或 Ruby 创建客户端。此外，最新的 Google API 将包含 gRPC 版本的接口，使你轻松地将 Google 功能构建到你的应用程序中。
gRPC 支持的语言版本：
说了这么多，还是得整两个小案例小伙伴们可能才会清晰，所以我们也不废话了，上案例。
3. 实践
先来看下我们的项目结构：
├── grpc-api
│ ├── pom.xml
│ ├── src
├── grpc-client
│ ├── pom.xml
│ ├── src
├── grpc-server
│ ├── pom.xml
│ ├── src
└── pom.xml
大家看下，这里首先有一个 grpc-api，这个模块用来放我们的公共代码；grpc-server 是我们的服务端，grpc-client 则是我们的客户端，这些都是普通的 maven 项目。
3.1 grpc-api
在 grpc-api 中，我们首先引入项目依赖，如下：
<dependencies>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty-shaded</artifactId>
<version>1.52.1</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-protobuf</artifactId>
<version>1.52.1</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-stub</artifactId>
<version>1.52.1</version>
</dependency>
<dependency> <!-- necessary for Java 9+ -->
<groupId>org.apache.tomcat</groupId>
<artifactId>annotations-api</artifactId>
<version>6.0.53</version>
<scope>provided</scope>
</dependency>
</dependencies>
除了这些常规的依赖之外，还需要一个插件：
<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.6.2</version>
</extension>
</extensions>
<plugins>
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.6.1</version>
<configuration>
<protocArtifact>com.google.protobuf:protoc:3.21.7:exe:${os.detected.classifier}</protocArtifact>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.51.0:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compile-custom</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
我来说一下这个插件的作用。
默认情况下，gRPC 使用 Protocol Buffers，这是 Google 提供的一个成熟的开源的跨平台的序列化数据结构的协议，我们编写对应的 proto 文件，通过上面这个插件可以将我们编写的 proto 文件自动转为对应的 Java 类。
多说一句，使用 Protocol Buffers 并不是必须的，也可以使用 JSON 等，但是目前来说这个场景更常用的还是 Portal Buffers。
接下来我们在 main 目录下新建 proto 文件夹，如下：
注意，这个文件夹位置是默认的。如果我们的 proto 文件不是放在 src/main/proto 位置，那么在配置插件的时候需要指定 proto 文件的位置，咱们本篇文章主要是入门，我这里就使用默认的位置。
在 proto 文件夹中，我们新建一个 product.proto 文件，内容如下：
syntax = "proto3";
option java_multiple_files = true;
option java_package = "org.javaboy.grpc.demo";
option java_outer_classname = "ProductProto";
package product;
service ProductInfo {
rpc addProduct (Product) returns (ProductId);
rpc getProduct(ProductId) returns(Product);
}
message Product {
string id = 1;
string name=2;
string description=3;
float price=4;
}
message ProductId {
string value = 1;
}
这段配置算是一个比较核心的配置了，这里主要说明了负责进程传输的类、方法等到底是个啥样子：
syntax = "proto3";：这个是 protocol buffers 的版本。option java_multiple_files = true;：这个字段是可选的，如果设置为 true，表示每一个 message 文件都会有一个单独的 class 文件；否则，message 全部定义在 outerclass 文件里。option java_package = "org.javaboy.grpc.demo";：这个字段是可选的，用于标识生成的 java 文件的 package。如果没有指定，则使用 proto 里定义的 package，如果package 也没有指定，那就会生成在根目录下。option java_outer_classname = "ProductProto";：这个字段是可选的，用于指定 proto 文件生成的 java 类的 outerclass 类名。什么是 outerclass？简单来说就是用一个 class 文件来定义所有的 message 对应的 Java 类，这个 class 就是 outerclass；如果没有指定，默认是 proto 文件的驼峰式；package product;：这个属性用来定义 message 的包名。包名的含义与平台语言无关，这个 package 仅仅被用在 proto 文件中用于区分同名的 message 类型。可以理解为 message 全名的前缀，和 message 名称合起来唯一标识一个 message 类型。当我们在 proto 文件中导入其他 proto 文件的 message，需要加上 package 前缀才行。所以包名是用来唯一标识 message 的。service：我们定义的跨平台方法都写在 service 中，上面的案例中我们定义了两个方法：addProduct 表示添加一件商品，参数是一个 Product 对象，返回值则是刚刚添加成功的商品的 ID；getProduct 则表示根据 ID 查询一个商品，参数是一个商品 ID，返回值则是查询到的商品对象。这里的定义相当于一个接口，将来我们要在 Java 代码中实现这个接口。message：这里有点像我们在 Java 中定义类，上文中我们定义了两个类，分别是 Product 和 ProductId 两个类。这两个类在 service 中被使用。
message 中定义的有点像我们 Java 中定义的类，但是不能直接使用 Java 中的数据类型，毕竟这是 Protocol buffers，这个是和语言无关的，将来可以据此生成不同语言的代码，这里我们可以使用的类型和我们 Java 类型之间的对应关系如下：
另外我们在 message 中定义的属性的时候，都会给一个数字，例如 id=1，name=2 等，这个数字将来会在二进制消息中标识我们的字段，并且一旦我们的消息类型被使用就不应更改，这个有点像序列化的感觉。
实际上，这个 message 编译后的字节内容大概像下面这样：
这里的标签中的内容包含两部分，字段索引和字段类型，字段索引其实就是我们上面定义的数字。
定义完成之后，接下来我们就需要使用插件来生成对应的 Java 代码了，插件我们在前面已经引入了，现在只需要执行了，如下图：
注意，compile 和 compile-custom 两个指令都需要执行。其中 compile 用来编译消息对象，compile-custom 则依赖消息对象,生成接口服务。
首先我们点击 compile 看看生成的代码，如下：
再看 compile-custom 生成的代码，如下：
好了，这样我们的准备工作就算完成了。
有的小伙伴生成的代码文件夹颜色不对劲，此时有两种解决办法：1.选中目标文件夹，右键单击，选择 Mark Directory as-> Generated Sources root；2.选中工程，右键单击，选择 Maven->Reload project。推荐使用第二种方案。
3.2 grpc-server
接下来我们创建 grpc-server 项目，并使该项目依赖 grpc-api，然后在 grpc-server 中，提供 ProductInfo 的具体实现：
public class ProductInfoImpl extends ProductInfoGrpc.ProductInfoImplBase {
@Override
public void addProduct(Product request, StreamObserver<ProductId> responseObserver) {
System.out.println("request.toString() = " + request.toString());
responseObserver.onNext(ProductId.newBuilder().setValue(request.getId()).build());
responseObserver.onCompleted();
}
@Override
public void getProduct(ProductId request, StreamObserver<Product> responseObserver) {
responseObserver.onNext(Product.newBuilder().setId(request.getValue()).setName("三国演义").build());
responseObserver.onCompleted();
}
}
ProductInfoGrpc.ProductInfoImplBase 是根据我们在 proto 文件中定义的 service 自动生成的，我们的 ProductInfoImpl 继承自该类，并且提供了我们给出的方法的具体实现。
以 addProduct 方法为例，参数 request 就是将来客户端调用的时候传来的 Product 对象，返回结果则通过 responseObserver 来完成。我们的方法逻辑很简单，我就把参数传来的 Product 对象打印出来，然后构建一个 ProductId 对象并返回，最后调用 responseObserver.onCompleted(); 表示数据返回完毕。
剩下的 getProduct 方法逻辑就很好懂了，我这里就不再赘述了。
最后，我们再把这个 grpc-server 项目启动起来：
public class ProductInfoServer {
Server server;
public static void main(String[] args) throws IOException, InterruptedException {
ProductInfoServer server = new ProductInfoServer();
server.start();
server.blockUntilShutdown();
}
public void start() throws IOException {
int port = 50051;
server = ServerBuilder.forPort(port)
.addService(new ProductInfoImpl())
.build()
.start();
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
ProductInfoServer.this.stop();
}));
}
private void stop() {
if (server != null) {
server.shutdown();
}
}
private void blockUntilShutdown() throws InterruptedException {
if (server != null) {
server.awaitTermination();
}
}
}
由于我们这里是一个 JavaSE 项目，为了避免项目启动之后就停止，我们这里调用了 server.awaitTermination(); 方法，就是让服务启动成功之后不要停止。
3.3 grpc-client
最后再来看看客户端的调用。首先 grpc-client 项目也是需要依赖 grpc-api 的，然后直接进行方法调用，如下：
public class ProductClient {
public static void main(String[] args) {
ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50051)
.usePlaintext()
.build();
ProductInfoGrpc.ProductInfoBlockingStub stub = ProductInfoGrpc.newBlockingStub(channel);
Product p = Product.newBuilder().setId("1")
.setPrice(399.0f)
.setName("TienChin项目")
.setDescription("SpringBoot+Vue3实战视频")
.build();
ProductId productId = stub.addProduct(p);
System.out.println("productId.getValue() = " + productId.getValue());
Product product = stub.getProduct(ProductId.newBuilder().setValue("99999").build());
System.out.println("product.toString() = " + product.toString());
}
}
小伙伴们看到，这里首先需要和服务端建立连接，给出服务端的地址和端口号即可，usePlaintext() 方法表示不使用 TLS 对连接进行加密（默认情况下会使用 TLS 对连接进行加密），生产环境建议使用加密连接。
剩下的代码就比较好懂了，创建 Product 对象，调用 addProduct 方法进行添加；创建 ProductId 对象，调用 getProduct。Product 对象和 ProductId 对象都是根据我们在 proto 中定义的 message 自动生成的。
4. 总结
好啦，一个简单的例子，小伙伴们先对 gRPC 入个门，后面松哥会再整几篇文章跟大家介绍这里边的一些细节。
随时随地看视频
