• 相信大家對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 >

• 編寫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目錄（targetgenerated-sourcesprotobuf）下就找到了生成的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();
    }
}

• 服務端與客戶端
  • 服務端啟動類

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文件的編寫和使用，這部分需要插件等依賴，過程相對復雜，但也可能會出現工具或腳本，可以簡化下這部分。但生成代碼確實是真香~ 減少了一部分工作量。