一．概念普及：

protocolbuffers（protobuf）：結構資料序列化機制

主要思想是:定義一個服務, 指定其可以被遠端呼叫的方法及其引數和返回型別。用來實現不同程序間的通訊。

gRPC 預設使用 protocol buffers，用 proto files 建立 gRPC 服務，用 protocol buffers 訊息型別來定義方法引數和返回型別。

GRPC:

Google 開發的基於HTTP/2和Protocol Buffer 3的RPC 框架

基於以下理念：定義一個服務，指定其能夠被遠端呼叫的方法（包含引數和返回型別）。在服務端實現這個介面，並執行一個 GRPC 伺服器來處理客戶端呼叫。在客戶端擁有一個存根能夠像服務端一樣的方法。

Stub存根：

為遮蔽客戶呼叫遠端主機上的物件，必須提供某種方式來模擬本地物件,這種本地物件稱為存根(stub),存根負責接收本地方法呼叫,並將它們委派給各自的具體實現物件。

二．GRPC JAVAdemo實現

針對你選擇的語言構建和安裝 gRPC 外掛和相關工具。 Java gRPC 除了 JDK 外不需要其他工具。

a)         在一個.proto檔案內定義服務

b)         用protocol buffer編譯器生成指定程式語言的伺服器和客戶端程式碼（maven compile + deploy）

c)         使用grpc的對應的語言（grpc-java）的API，實現服務端和客戶端的程序間的通訊。

1.protobuf使用包括以下幾個步驟：

a)       定義資料結構。

b)       編譯成你喜歡的開發語言的相關工具類。

c)       在程式中呼叫工具類來處理資料。

一旦定義好服務，可以使用 protocol buffer 編譯器 protoc 來生成建立應用所需的特定客戶端和服務端的程式碼，生成的程式碼同時包括客戶端的存根和服務端要實現的抽象介面。

需要支援：Idea 外掛 protobuf support

通過：Maven compile+deploy

生成java版本的資料結構類：RPCDateRequest、RPCResponse的java類，我們在服務端、客戶端直接使用即可。

RPCDateRequest.java，RPCResponse.java和其他檔案包含所有 protocol buffer 用來填充、序列化和提取 RPCDateRequest和 RPCResponse訊息型別的程式碼。

RPCDateServiceGrpc.java：包含 (還有其他有用的程式碼)呼叫RPCDateService服務，服務端需要實現的抽象類

        public static abstract class RPCDateServiceImplBase implements io.grpc.BindableService {
public void getDate(com.grpc.api.RPCDateRequest request,
      io.grpc.stub.StreamObserver<com.grpc.api.RPCDateResponse> responseObserver) {
    asyncUnimplementedUnaryCall(METHOD_GET_DATE, responseObserver);
  }

客戶端用來與 RPCDateService服務端進行對話的存根類。

public static final class RPCDateServiceBlockingStub extends io.grpc.stub.AbstractStub<RPCDateServiceBlockingStub> {
  public com.grpc.api.RPCDateResponse getDate(com.grpc.api.RPCDateRequest request) {
    return blockingUnaryCall(
        getChannel(), METHOD_GET_DATE, getCallOptions(), request);
  }
}

服務端的主要工作：

1.       實現定義的服務介面函式

2.       開啟服務端，監聽來自客戶端的請求並響應客戶端的請求。

服務實現

RPCDateServiceImpl.java 繼承自RPCDateServiceGrpc.RPCDateServiceImplBase，實現其定義的getDate方法。。

public void getDate(RPCDateRequest request, StreamObserver<RPCDateResponse> responseObserver) {
    RPCDateResponse rpcDateResponse = null;
    Date now = new Date();
    SimpleDateFormat simpleDateFormat = new SimpleDateFormat("今天是"+"yyyy年MM月dd日 E kk點mm分");
    String nowTime = simpleDateFormat.format(now);
    try {
        rpcDateResponse = RPCDateResponse
                .newBuilder()
                .setServerDate("hello " + request.getUserName() + ", " + nowTime)
                .build();
    } catch (Exception e) {
        responseObserver.onError(e);
    } finally {
        responseObserver.onNext(rpcDateResponse);
    }
    responseObserver.onCompleted();
}

getDate有兩個引數：

·        RPCDateRequest：請求。

·        StreamObserver<RPCDateResponse>：應答觀察者，一個特殊的介面，伺服器用應答來呼叫它。

為了返回給客戶端應答並且完成呼叫：

1.進行訊息構建並填充一個在我們介面定義的RPCDateResponse應答物件。

2.將RPCDateResponse返回給客戶端，然後表明我們已經完成了對 RPC 的處理。

public class GRPCServer {
    private static final int port = 9999;
    public static void main(String[] args) throws Exception {
        Server server = ServerBuilder
                .forPort(port)              //設定服務埠
                .addService(new RPCDateServiceImpl())       //新增服務
                .build().start();
        System.out.print("grpc服務端啟動成功，埠=" + port);
        server.awaitTermination();
    }
}

客戶端的主要工作：

1.         建立Client例項並連線server

2.         呼叫服務端方法（請求）並獲取服務端迴應。

連線服務

需要建立一個 gRPC 頻道，指定我們要連線的主機名和伺服器埠。然後我們用這個頻道建立存根例項

呼叫RPC

1.         我們建立並填充一個RPCDateRequest傳送給服務。

2.         我們用請求呼叫存根的getDate()，如果 RPC 成功，會得到一個填充的RPCDateResponse，從其中我們可以獲得響應資料。

public class GRPCClient {
    private static final String host = "localhost";
    private static final int serverPort  = 9999;

    public static void main(String[] args) throws Exception {
        //根據埠和IP連線服務端，建立grpc channel
        ManagedChannel managedChannel = ManagedChannelBuilder.forAddress(host, serverPort).usePlaintext().build();
        try {
            //建立存根，存根是根據.proto檔案中生成的類RPCDateServiceGrpc的代理。
            //blockingStub為阻塞式，需要阻塞等待服務端的迴應。    另有asyncStub為非阻塞，可以非同步執行。
            RPCDateServiceGrpc.RPCDateServiceBlockingStub rpcDateService = RPCDateServiceGrpc.newBlockingStub(managedChannel);
            //構造請求物件
            RPCDateRequest rpcDateRequest = RPCDateRequest
                    .newBuilder()
                    .setUserName("ChaiShuai")
                    .build();
            RPCDateResponse rpcDateResponse = rpcDateService.getDate(rpcDateRequest);
            System.out.println(rpcDateResponse.getServerDate());
        } finally {
            managedChannel.shutdown();
        }
    }
}

三．FAQ

在建立.proto檔案時，通過new>file，命名為.proto格式建立。添加了protobuf support外掛後，idea自動識別，前面的顯示圖示也變了。

通過maven compile後，相應的Java類會生成到target>generated-sources>java和grpc-java+ java_package（自主命名目錄）下。

在服務端和客戶端需要使用通過.proto定義的服務，要新增相應的maven依賴，這時由.proto生成的java類要進行釋出（maven deploy）.

四．GRPC原理學習

RPC是什麼

通用RPC呼叫流程

GRPC

gRPC 是一個高效能、開源和通用的 RPC 框架，面向服務端和移動端，基於 HTTP/2 設計

語言特點：

語言中立，支援多種語言。

基於 IDL 檔案定義服務，通過 proto3 工具生成指定語言的資料結構、服務端介面以及客戶端 Stub。

通訊協議基於標準的 HTTP/2 設計，支援雙向流、訊息頭壓縮、單 TCP 的多路複用、服務端推送等特性，這些特性使得 gRPC 在移動端裝置上更加省電和節省網路流量。

序列化支援 PB（Protocol buffer）和 JSON，PB 是一種語言無關的高效能序列化框架，基於 HTTP/2 + PB, 保障了 RPC 呼叫的高效能。

gRPC服務端建立和呼叫原理解析：

一．gRPC 服務端建立關鍵流程分析：

a.NettyServer 例項建立：gRPC 服務端建立，首先需要初始化 NettyServer，它是 gRPC 基於 Netty4.1 HTTP/2 協議棧之上封裝的 HTTP/2 服務端。NettyServer 例項由 NettyServerBuilder 的 buildTransportServer 方法構建。NettyServer 構建完成之後，監聽指定的 Socket 地址，即可實現基於 HTTP/2 協議的請求訊息接入。

b.繫結 IDL 定義的服務介面實現類：gRPC 與其它一些 RPC 框架的差異點是服務介面實現類的呼叫並不是通過動態代理和反射機制，而是通過 proto 工具生成程式碼。在服務端啟動時，將服務介面實現類例項註冊到 gRPC 內部的服務註冊中心上。請求訊息接入之後，可以根據服務名和方法名，直接呼叫啟動時註冊的服務例項，而不需要通過反射的方式進行呼叫，效能更優。

c.gRPC 服務例項（ServerImpl）構建：ServerImpl 負責整個 gRPC 服務端訊息的排程和處理，建立 ServerImpl 例項過程中，會對服務端依賴的物件進行初始化。例如 Netty 的執行緒池資源、gRPC 的執行緒池、內部的服務註冊類（InternalHandlerRegistry）等。ServerImpl 初始化完成之後，就可以呼叫 NettyServer 的 start 方法啟動 HTTP/2 服務端，接收 gRPC 客戶端的服務呼叫請求。

二.服務端 service 呼叫流程

gRPC 的客戶端請求訊息由 Netty Http2ConnectionHandler 接入，由 gRPC 負責將 PB 訊息（或者 JSON）反序列化為 POJO 物件，然後通過服務定義查詢到該訊息對應的介面例項，發起本地 Java 介面呼叫，呼叫完成之後，將響應訊息反序列化為 PB(或者 JSON)，通過 HTTP2 Frame 傳送給客戶端。

流程並不複雜，但是細節卻比較多，整個 service 呼叫可以劃分為如下四個過程：

gRPC 請求訊息接入

gRPC 訊息頭和訊息體處理

內部的服務路由和呼叫

響應訊息傳送

GRPC Server端，還有一個最終要的方法：addService。

在此之前，我們需要介紹一下bindService方法，每個GRPC生成的service程式碼中都有此方法，它以硬編碼的方式遍歷此service的方法列表，將每個方法的呼叫過程都與“被代理例項”繫結，這個模式有點類似於靜態代理，比如呼叫sayHello方法時，其實內部直接呼叫“被代理例項”的sayHello方法（參見MethodHandler.invoke方法，每個方法都有一個唯一的index，通過硬編碼方式執行）；bindService方法的最終目的是建立一個ServerServiceDefinition物件，這個物件內部位置一個map，key為此Service的方法的全名（fullname，{package}.{service}.{method}）,value就是此方法的GRPC封裝類（ServerMethodDefinition）。

三．Protobuf 上的 GRPC

用 protobuf 定義的服務介面可以通過 protoc 的程式碼生成擴充套件簡單地對映成 GRPC ，以下定義了所用的對映：

路徑→ / 服務名 / {方法名}

服務名 → ?( {proto 包名} "." ) {服務名}

訊息型別 → {全路徑 proto 訊息名}

內容型別 → "application/grpc+proto"

gRPC客戶端建立和呼叫原理解析

gRPC的客戶端呼叫主要包括基於Netty的HTTP/2客戶端建立、客戶端負載均衡、請求訊息的傳送和響應接收處理四個流程。

gRPC的客戶端呼叫總體流程如下圖所示

ManagedChannelBuilder來建立客戶端channel，ManagedChannelBuilder使用了provider機制，具體是建立了哪種channel有provider決定，可以參看META-INF下同類名的檔案中的註冊資訊。當前Channel有2種：NettyChannelBuilder與OkHttpChannelBuilder。當前版本中為NettyChannelBuilder；可以直接使用NettyChannelBuilder來構建channel。

ManagedChannel是客戶端最核心的類，它表示邏輯上的一個channel；底層持有一個物理的transport（TCP通道，參見NettyClientTransport），並負責維護此transport的活性；即在RPC呼叫的任何時機，如果檢測到底層transport處於關閉狀態（terminated），將會嘗試重建transport。（參見TransportSet.obtainActiveTransport()）

通常情況下，我們不需要在RPC呼叫結束後就關閉Channel，Channel可以被一直重用，直到Client不再需要請求為止或者Channel無法真的異常中斷而無法繼續使用。

每個Service客戶端，都生成了2種stub：BlockingStub和FutureStub；這兩個Stub內部呼叫過程幾乎一樣，唯一不同的是BlockingStub的方法直接返回Response, 而FutureStub返回一個Future物件。BlockingStub內部也是基於Future機制，只是封裝了阻塞等待的過程。

Client端關鍵元件：

關於Client負載均衡

Grpc分層設計

參考文章：