​大家好，我是指北君。又是一周工作日的最后一天，但也不要忘记努力。

(相关资料图)

吃得苦中苦，你长大开路虎，少壮不努力，你长大开夏利。

接下来开始进入正题~

​前言

相信大家对RPC协议都有一定的了解，并且或多或少都会在项目中涉及，但可能都和小编类似，都是直接使用平台封装的插件，对于其中的原理不是很了解，今天借此机会和大家分享下最近接触的RPC框架-grpc，一同聊聊那些知其然却不知其所以然的内容。

​概述

RPC(Remote Procedure Call)远程过程调用协议，是一种本地可以通过网络请求远程计算机，完成计算机间的数据内容的交互的协议，不需要了解网络底层技术就可以快速上手，使得开发更加容易，同时提升了交互体验效率。

为了方便开发，有很多基于RPC协议实现的RPC框架，比如Thrift、Dubbo，和本文即将要介绍的gRPC。

​什么是gRPCgRPC是由google开发的一种支跨平台（语言）、高性能、开源通用的RPC框架。它是基于HTTP2.0协议的，可以保持客户端与服务端长连接，基于二进制流（字节流）传输数据。客户端与服务端交互过程

客户端（gRPC Sub）调用A方法，发起RPC请求

请求内容使用Protobf进行对象序列化压缩

服务端（gRPC Server）接收请求，解析请求内容，业务处理后返回

响应结果通过Protobuf进行对象序列化压缩

客户端接收响应，解析响应内容，最终完成交互

​实践案例

小编以java版进行案例展示，其它语言类似，可自行测试

POM依赖

gRPC官方提供完成的依赖配置，按照说明直接引用即可（依赖包含插件），版本仅供参考，也可选择其它版本。

io.grpc grpc-netty-shaded 1.29.0 io.grpc grpc-protobuf 1.29.0 io.grpc grpc-services 1.29.0 io.grpc grpc-stub 1.29.0 org.xolstice.maven.plugins protobuf-maven-plugin 0.6.1 com.google.protobuf:protoc:3.11.0:exe:${os.detected.classifier} grpc-java io.grpc:protoc-gen-grpc-java:1.29.0:exe:${os.detected.classifier} compile compile-custom

编写protobuf文件

小编使用的是proto3版本，需要注意固定的目录结构（src/proto/*.proto）,否则会编译失败。proto文件有固定的编写格式，可以自行上网搜索即可​

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// 实现接口具体逻辑@Componentpublic class RuleGRPCServer extends RuleServiceGrpc.RuleServiceImplBase { // 更新规则字典 @Override public void getArchivesDic(RuleRequest request, StreamObserver 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 responseObserver) { Response response = Response.newBuilder().setRuleCode(1) .setAdministrativeCost("2222").build(); responseObserver.onNext(response); responseObserver.onCompleted(); }}

服务端与客户端

服务端启动类

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文件的编写和使用，这部分需要插件等依赖，过程相对复杂，但也可能会出现工具或脚本，可以简化下这部分。但生成代码确实是真香~ 减少了一部分工作量。​

关键词： 启动成功 请求内容 你不知道的 使用的是 传输数据