电子商务网站建设及推广方案论文,wordpress无法显示文章,连云港外贸网站建设,京紫元年网站建设在如今云原生技术的大环境下#xff0c;rpc服务作为最重要的互联网技术#xff0c;蓬勃发展#xff0c;诞生了许多知名基于rpc协议的框架#xff0c;其中就有本文的主角gRPC技术。 一款高性能、开源的通用rpc框架
作者作为一名在JD实习的Cpper#xff0c;经过一段时间的学…在如今云原生技术的大环境下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发挥出每种语言的优势绽放出绚丽的色彩。
