gRPC-第二代rpc服务

在如今云原生技术的大环境下，rpc服务作为最重要的互联网技术，蓬勃发展，诞生了许多知名基于rpc协议的框架，其中就有本文的主角gRPC技术。

一款高性能、开源的通用rpc框架

作者作为一名在JD实习的Cpper，经过一段时间的学习和实践，发现了C++与Java之间的种种不同，这也让我产生了一个想法：既然rpc需要做到的就是客户端无感知调用，那么客户端和服务端使用的语言也不应该成为约束，正巧在来JD实习之前，我就有接触过gRPC，所以就想写一篇文章分析一下gRPC与当今主流rpc框架之间的区别与优势。

对比

1. gRPC的实现原理

在 gRPC 里客户端 应用可以像调用本地对象一样直接调用另一台不同的机器上服务端 应用的方法，使得使用者能够更容易地创建分布式应用和服务。与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。

gRPC的客户端和服务端可以用在多样化的环境中运行，使用者可以使用各种官方支持的语言来构建自己的应用。例如：你可以很轻易的使用Java作为gRPC的服务端，而在客户端使用Ruby、Go、Python等语言。

gRPC调用图

2. gRPC的优势与劣势

2.1 优势：

2.1.1 多语言支持

gRPC官方就支持多种编程语言，包括C#/.NET, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python, Ruby等。开发人员无需考虑使用何种开发语言，可以充分利用语言的优势：C++的内存操作，go语言的灵活，Java的生态丰富......

2.1.2 基于Protocol Buffers

gRPC默认使用Protocol Buffers作为其接口定义语言（IDL）和底层消息交换格式。Protocol Buffers是一种语言和平台中立的接口描述语言，允许开发者定义数据结构和服务接口，并且可以生成多种语言的代码。这使得在不同语言之间实现数据和服务接口的一致性变得简单。其消息格式采用二进制方式传输，比传统的Json体积更小。

具体的语法定义如下：

消息定义：在 .proto 文件中定义消息，消息由字段组成。字段有三种类型：required、optional、repeated，分别表示必须、可选和重复。

ini 复制代码

message Person {
  required string name = 1;
  optional int32 id = 2;
  repeated string email = 3;
}

枚举定义：枚举类型允许你定义一组有限的可能的值。

ini 复制代码

enum PhoneType {
  MOBILE = 0;
  HOME = 1;
  WORK = 2;
}

服务定义：服务允许你定义一组相互关联的RPC（远程过程调用）。

scss 复制代码

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

4.字段编号：每个字段都有一个唯一的数字编号。这是必要的，因为在解析过程中，我们需要知道每个字段的顺序。在 .proto 文件中定义的每个字段都有默认值。例如，int32 类型的字段默认值为 0。

5.字段类型：每个字段都有一个类型。例如，string、int32、message 等。对于 message 类型的字段，你需要在括号内定义该消息的类型。对于 repeated 类型的字段，你可以将多个值放入一个列表中。例如，Person 消息中的 email 字段可以包含一个电子邮件地址列表。

6.服务调用：在客户端代码中，你可以使用生成的 stub 类来调用服务方法。例如，你可以这样调用 SayHello 方法：

ini 复制代码

HelloService.stub stub = HelloServiceGrpc.newBlockingStub(channel);
HelloReply response = stub.sayHello(HelloRequest.newBuilder().build());

2.1.3 跨平台兼容性

gRPC支持多种软件和硬件平台。这种跨平台能力意味着gRPC不仅能在不同的操作系统上运行，还能在各种环境中有效运行，如服务器、移动设备和Web环境。

2.1.4 底层调用协议

gRPC使用HTTP/2作为底层传输协议克服了一些HTTP/1.1版本的一些限制。二进制组帧和压缩。 HTTP/2 协议在发送和接收方面均紧凑且高效。在单个 TCP 连接上多路复用多个 HTTP/2 调用。多路复用可消除队头阻塞。

2.1.5 强大的社区和生态系统

gRPC的社区和生态系统提供了丰富的文档、教程和API参考，帮助开发者在不同的语言和平台上使用gRPC。这种广泛的社区支持也促进了对新语言和平台的支持。例如：Dubbo3对gRPC的支持、gRPC-Swift、gRPC-Spring。

github上的gRPC生态支持

2.1.6 严格规范

具有 JSON 的 HTTP API 没有正式规范。开发人员为 URL、HTTP 谓词和响应代码的最佳格式争论不休。gRPC 规范对 gRPC 服务必须遵循的格式进行了规定。 gRPC 消除了争论并为开发人员节省了时间，因为 gRPC 在各个平台和实现中都是一致的。

2.2 劣势：

2.2.1 浏览器支持有限

当下，不可能直接从浏览器调用gRPC服务。gRPC大量使用HTTP/2功能，没有浏览器提供支持gRPC客户机的Web请求所需的控制级别。例如，浏览器不允许调用者要求使用的HTTP/2，或者提供对底层HTTP/2框架的访问。

2.2.2 不是人类可读的

HTTP API请求以文本形式发送，可以由人读取和创建。默认情况下，gRPC消息使用protobuf编码。**虽然protobuf的发送和接收效率很高，但它的二进制格式是不可读的8。protobuf需要在.proto文件中指定的消息接口描述才能正确反序列化。需要额外的工具来分析线路上的Protobuf有效负载，并手工编写请求。

grpc与传统rpc相比较

demo展示

下面作者将使用C++与go作为开发语言来展示gRPC强大的跨语言调用能力

项目结构:

go 复制代码

grpc-demo
├── cpp
│   ├── CMakeLists.txt // C++的CMakeLists.txt文件，用来生成makefile
│   ├── cmake // 用来存放一些cmake函数
│   │   └── common.cmake // cmake函数
│   ├── include // 头文件
│   ├── proto // Protocol Buffers定义文件
│   │   └── helloworld.proto
│   └── src // C++源文件
│       └── main.cpp
├── go
│   ├── Makefile // makefile脚本
│   ├── go.mod // Go语言包管理
│   ├── proto
│   │   ├── helloworld.proto
│   ├── service
│   └── src // go源文件
│       └── main
│           └── main.go
└── proto
    └── helloworld.proto

项目源代码: github.com/Constantine...

总结

回归题目，gRPC因为他强大的可扩展性，轻便的底层传输格式，越来越多的企业在技术选型时选择了它，我也希望未来能有一款应用可以通过gRPC发挥出每种语言的优势，绽放出绚丽的色彩。