欢迎大家来到IT世界,在知识的湖畔探索吧!
前言
- 相信大家对RPC协议都有一定的了解,并且或多或少都会在项目中涉及,但可能都和小编类似,都是直接使用平台封装的插件,对于其中的原理不是很了解,今天借此机会和大家分享下最近接触的RPC框架-grpc,一同聊聊那些知其然却不知其所以然的内容。
概述
- RPC(Remote Procedure Call)远程过程调用协议,是一种本地可以通过网络请求远程计算机,完成计算机间的数据内容的交互的协议,不需要了解网络底层技术就可以快速上手,使得开发更加容易,同时提升了交互体验效率。
- 为了方便开发,有很多基于RPC协议实现的RPC框架,比如Thrift、Dubbo,和本文即将要介绍的gRPC。
什么是gRPC
- gRPC是由google开发的一种支跨平台(语言)、高性能、开源通用的RPC框架。
- 它是基于HTTP2.0协议的,可以保持客户端与服务端长连接,基于二进制流(字节流)传输数据。
- 客户端与服务端交互过程
- 客户端(gRPC Sub)调用A方法,发起RPC请求
- 请求内容使用Protobf进行对象序列化压缩
- 服务端(gRPC Server)接收请求,解析请求内容,业务处理后返回
- 响应结果通过Protobuf进行对象序列化压缩
- 客户端接收响应,解析响应内容,最终完成交互
实践案例
小编以java版进行案例展示,其它语言类似,可自行测试
- POM依赖
- gRPC官方提供完成的依赖配置,按照说明直接引用即可(依赖包含插件),版本仅供参考,也可选择其它版本。
<!-- gRPC配置 -->
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-netty-shaded</artifactId>
<version>1.29.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-protobuf</artifactId>
<version>1.29.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-services</artifactId>
<version>1.29.0</version>
</dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-stub</artifactId>
<version>1.29.0</version>
</dependency>
<!-- proto插件 -->
<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.11.0:exe:${os.detected.classifier}</protocArtifact>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.29.0:exe:${os.detected.classifier}</pluginArtifact>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compile-custom</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
欢迎大家来到IT世界,在知识的湖畔探索吧!
- 编写protobuf文件
- 小编使用的是proto3版本,需要注意固定的目录结构(src/proto/*.proto),否则会编译失败。
- proto文件有固定的编写格式,可以自行上网搜索即可
欢迎大家来到IT世界,在知识的湖畔探索吧!syntax = "proto3";
//包所在路径
option java_package = "com.greatom.dockerdemo.rule";
option java_multiple_files = true;
package rule;
//声明服务和方法
service RuleService {
//查询并更新规则
rpc getArchivesDic (RuleRequest) returns (RuleResponse);
//获取当前规则字典
rpc getRule (Request) returns (Response);
}
//定义请求对象
message RuleRequest {
// message RuleRPCDTO {
// int32 ruleCode = 1;
// string administrativeCost = 2;
// }
Response ruleRPCDTO = 1;
int32 basicId = 2;
}
//定义响应对象
message RuleResponse {
int32 id = 1;
}
message Request {
}
//定义响应消息
message Response {
int32 ruleCode = 1;
string administrativeCost = 2;
}
- 使用maven插件编译,双击执行(生成Bean,maven->Plugins->protobuf->protobuf:compile;生成具体接口,maven->Plugins->protobuf->protobuf:compile-custom)。
- 小编只执行protobuf:compile命令,然后在target目录(\target\generated-sources\protobuf)下就找到了生成的java文件,复制出来粘贴到项目执行目录下即可。
- 编写接口实现类
- 编译完后会生成RuleServiceGrpc接口,接下来就是按照自己的业务需求编写逻辑即可。小编定义的两个接口分别是 getArchivesDic(更新规则)、getRule(查询规则)。具体实现如下
// 继承生成的RuleServiceGrpc.RuleServiceImplBase
// 实现接口具体逻辑
@Component
public class RuleGRPCServer extends RuleServiceGrpc.RuleServiceImplBase {
// 更新规则字典
@Override
public void getArchivesDic(RuleRequest request, StreamObserver<RuleResponse> responseObserver) {
Response ruleRPCDTO = request.getRuleRPCDTO();
RuleDTO ruleDTO = new RuleDTO();
BeanUtils.copyProperties(ruleRPCDTO, ruleDTO);
RuleResponse ruleResponse = RuleResponse.newBuilder().setId(1).build();
responseObserver.onNext(ruleResponse);
responseObserver.onCompleted();
}
// 查询规则字典
@Override
public void getRule(Request request, StreamObserver<Response> responseObserver) {
Response response = Response.newBuilder().setRuleCode(1)
.setAdministrativeCost("2222").build();
responseObserver.onNext(response);
responseObserver.onCompleted();
}
}
- 服务端与客户端
- 服务端启动类
欢迎大家来到IT世界,在知识的湖畔探索吧! public static void main(String[] args) throws Exception {
// 设置service接口.
Server server = ServerBuilder.forPort(9999).addService(new RuleGRPCServiceImpl()).build().start();
System.out.println(String.format("GRpc服务端启动成功, 端口号: %d.", port));
server.awaitTermination();
}
日志 --- GRpc服务端启动成功, 端口号: 9999.
- 客户端启动类
public static void main(String[] args) throws Exception {
// 1. 拿到一个通信的channel
ManagedChannel managedChannel = ManagedChannelBuilder.forAddress("localhost", 9999).usePlaintext().build();
try {
// 2.拿到道理对象
RuleServiceGrpc.RuleServiceBlockingStub rpcDateService = RuleServiceGrpc.newBlockingStub(managedChannel);
Request rpcDateRequest = Request
.newBuilder()
.build();
// 3. 请求
Response rpcDateResponse = rpcDateService.getRule(rpcDateRequest);
// 4. 输出结果
System.out.println(rpcDateResponse.getRuleCode());
} finally {
// 5.关闭channel, 释放资源.
managedChannel.shutdown();
}
}
日志:
- 16:05:44.628 [grpc-nio-worker-ELG-1-2] DEBUG io.grpc.netty.shaded.io.grpc.netty.NettyClientHandler - [id: 0x8447cc92, L:/127.0.0.1:60973 - R:localhost/127.0.0.1:9999] INBOUND DATA: streamId=3 padding=0 endStream=false length=12 bytes=0000000007086f1203323232
- 16:05:44.648 [grpc-nio-worker-ELG-1-2] DEBUG io.grpc.netty.shaded.io.grpc.netty.NettyClientHandler - [id: 0x8447cc92, L:/127.0.0.1:60973 - R:localhost/127.0.0.1:9999] INBOUND HEADERS: streamId=3 headers=GrpcHttp2ResponseHeaders[grpc-status: 0] padding=0 endStream=true
- 输出结果-----111
- 16:05:44.664 [grpc-nio-worker-ELG-1-2] DEBUG io.grpc.netty.shaded.io.grpc.netty.NettyClientHandler - [id: 0x8447cc92, L:/127.0.0.1:60973 - R:localhost/127.0.0.1:9999] OUTBOUND GO_AWAY: lastStreamId=0 errorCode=0 length=0 bytes=
- 客户端日志输出结果即表示客户端通过gRPC调用服务端成功,并返回结果。
总结
- gRPC本质上就是传统的C|S模型,这样看角色分的清楚,也很容易理解。
- 还有就是它很聪明的点是基于HTTP2.0协议的,而不是自己制定,这就对未来的网络开发很友好,降低了门槛。
- 比较难上手的点在于proto文件的编写和使用,这部分需要插件等依赖,过程相对复杂,但也可能会出现工具或脚本,可以简化下这部分。但生成代码确实是真香~ 减少了一部分工作量。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/17775.html