在如今云原生技术的大环境下，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，分别表示必须、可选和重复。
message Person {required string name = 1;optional int32 id = 2;repeated string email = 3;
}
- 枚举定义：枚举类型允许你定义一组有限的可能的值。
enum PhoneType {MOBILE = 0;HOME = 1;WORK = 2;
}
- 服务定义：服务允许你定义一组相互关联的RPC（远程过程调用）。
service HelloService {rpc SayHello (HelloRequest) returns (HelloReply) {}
}
4.字段编号：每个字段都有一个唯一的数字编号。这是必要的，因为在解析过程中，我们需要知道每个字段的顺序。在 .proto 文件中定义的每个字段都有默认值。例如，int32 类型的字段默认值为 0。
5.字段类型：每个字段都有一个类型。例如，string、int32、message 等。对于 message 类型的字段，你需要在括号内定义该消息的类型。对于 repeated 类型的字段，你可以将多个值放入一个列表中。例如，Person 消息中的 email 字段可以包含一个电子邮件地址列表。
6.服务调用：在客户端代码中，你可以使用生成的 stub 类来调用服务方法。例如，你可以这样调用 SayHello 方法：
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强大的跨语言调用能力
项目结构:
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
项目源代码: https://github.com/ConstantineQAQ/grpc-demo
总结
回归题目，gRPC因为他强大的可扩展性，轻便的底层传输格式，越来越多的企业在技术选型时选择了它，我也希望未来能有一款应用可以通过gRPC发挥出每种语言的优势，绽放出绚丽的色彩。
)
