gRPC learning four: four types of service methods in actual combat

Welcome to my GitHub

https://github.com/zq2599/blog_demos

Content: Classification and summary of all original articles and supporting source code, involving Java, Docker, Kubernetes, DevOPS, etc.;

Links to gRPC learning series articles

1. deploy and set up GO
2. GO's gRPC development environment preparation
3. first trial GO version gRPC development
4. Actual combat four types of service methods
5. gRPC-Gateway actual combat
6. gRPC-Gateway integrated swagger

Overview of this article

• This article is the fourth part of the "gRPC learning" series. In the previous article, we experienced the simplest gRPC development, writing the client to call the server, but this is only the simplest one, and it is far from enough when solving practical problems;
• In fact, gRPC allows you to define the following four types of service methods (the following description comes from <font color="blue"> http://doc.oschina.net/grpc </font>):
• Single RPC, that is, the client sends a request to the server, and gets a response from the server, just like an ordinary function call (this is the case in the previous article);
• Server-side streaming RPC, that is, the client sends a request to the server to obtain a data stream to read a series of messages. The client keeps reading from the returned data stream until there are no more messages;
• Client streaming RPC, that is, the client writes and sends a series of messages to the server with a data stream provided. Once the client finishes writing the message, it waits for the server to read these messages and return a response;
• Two-way streaming RPC, that is, both sides can send a series of messages through a read and write data stream. These two data stream operations are independent of each other, so the client and server can read and write in any order they want, for example: the server can wait for all client messages before writing a response, or it can read a message first Write another message, or other ways of combining reading and writing. The order of messages in each data stream will be maintained.
• The content of this article is to code to implement the above four types of service methods and write client code calls. The entire development process is shown in the following figure:

Source download

• The source code in this actual combat can be downloaded from GitHub. The address and link information are shown in the following table ( https://github.com/zq2599/blog_demos):

name	link	Remarks
Project homepage	https://github.com/zq2599/blog_demos	The project's homepage on GitHub
git warehouse address (https)	https://github.com/zq2599/blog_demos.git	The warehouse address of the source code of the project, https protocol
git warehouse address (ssh)	[e-mail]:zq2599/blog_demos.git	The warehouse address of the source code of the project, ssh protocol

• There are multiple folders in this git project. The application of this chapter is under the <font color="blue">go-source</font> folder, as shown in the red box below:

• There are multiple subfolders in <font color="blue">go-source</font>. The source code of this article is in <font color="red">grpcstream</font>, as shown in the red box in the following figure:

Specify files and directories in advance

• In this actual combat, a new folder <font color="red">grpcstream</font> is added under the <font color="blue">$GOPATH/src</font> directory, which contains the following contents in total:

[golang@centos7 src]$ tree grpcstream/
grpcstream/
├── client
│   └── client.go
├── grpcstream.pb.go
├── grpcstream.proto
└── server
    └── server.go

• The preparation work is completed, and then the development will officially start;

Write proto file

• The proto file is used to describe information related to remote services, such as method signatures, data structures, etc. The proto file in this article is named <font color="blue">grpcstream.proto</font>, and the location is <font color="red ">$GOPATH/src/grpcstream</font>, the content is as follows (I will point out a few points to pay attention to later):

// 协议类型
syntax = "proto3";

// 包名
package grpcstream;

// 服务端请求的数据结构
message SingleRequest {
  int32 id = 1;
}

// 服务端响应的数据结构
message SingleResponse {
  int32 id = 1;
  string name = 2;
}

// 定义的服务名
service IGrpcStremService {
  // 单项RPC ：单个请求，单个响应
  rpc SingleReqSingleResp (SingleRequest) returns (SingleResponse);

  // 服务端流式 ：单个请求，集合响应
  rpc SingleReqMultiResp (SingleRequest) returns (stream SingleResponse);

  // 客户端流式 ：集合请求，单个响应
  rpc MultiReqSingleResp (stream SingleRequest) returns (SingleResponse);

  // 双向流式 ：集合请求，集合响应
  rpc MultiReqMultiResp (stream SingleRequest) returns (stream SingleResponse);
}

• This <font color="blue">grpcstream.proto</font> file has the following points to note:
• The method <font color="blue">SingleReqSingleResp</font> is very simple. Like the demo in the previous article, the input parameter is a data structure, and the server returns a data structure;
• The method <font color="blue">SingleReqSingleResp</font> is a server-side streaming type, and its characteristic is that the return value is decorated with <font color="red">stream</font>;
• The method <font color="blue">MultiReqSingleResp</font> is a client-side streaming type, and its characteristic is that the input parameter is decorated with <font color="red">stream</font>;
• The method <font color="blue">MultiReqMultiResp</font> is a bidirectional type, and its characteristic is that the input parameter and return value are both decorated with <font color="red">stream</font>;
• There seems to be a pattern to follow: If the client wants to establish a channel with the server to transmit continuous data, it should be decorated with <font color="red">stream</font> in the channel position. There are two positions in total, the first is Enter the input parameters of the server, the second is the return value from the server;

Generate go source code according to proto

1. In the directory where <font color="blue">grpcstream.proto</font> is located, execute the following command:

protoc --go_out=plugins=grpc:. grpcstream.proto

2. If grpcstream.proto has no syntax errors, the file <font color="blue">grpcstream.pb.go</font> will be generated in the current directory, which is the code automatically generated by the tool protoc-gen-go, and the generated code It will be used in the development of server and client;
3. For the server, the most important of <font color="blue">grpcstream.pb.go</font> is the <font color="blue">IGrpcStremServiceServer</font> interface, and the server needs to implement all of this interface The method as business logic, the interface is defined as follows:

type IGrpcStremServiceServer interface {
    // 单项流式 ：单个请求，单个响应
    SingleReqSingleResp(context.Context, *SingleRequest) (*SingleResponse, error)
    // 服务端流式 ：单个请求，集合响应
    SingleReqMultiResp(*SingleRequest, IGrpcStremService_SingleReqMultiRespServer) error
    // 客户端流式 ：集合请求，单个响应
    MultiReqSingleResp(IGrpcStremService_MultiReqSingleRespServer) error
    // 双向流式 ：集合请求，集合响应
    MultiReqMultiResp(IGrpcStremService_MultiReqMultiRespServer) error
}

4. For the client, the most important of <font color="blue">grpcstream.pb.go</font> is the <font color="blue">IGrpcStremServiceClient</font> interface, as shown below, which means this What remote calls can the client initiate:

type IGrpcStremServiceClient interface {
    // 单项流式 ：单个请求，单个响应
    SingleReqSingleResp(ctx context.Context, in *SingleRequest, opts ...grpc.CallOption) (*SingleResponse, error)
    // 服务端流式 ：单个请求，集合响应
    SingleReqMultiResp(ctx context.Context, in *SingleRequest, opts ...grpc.CallOption) (IGrpcStremService_SingleReqMultiRespClient, error)
    // 客户端流式 ：集合请求，单个响应
    MultiReqSingleResp(ctx context.Context, opts ...grpc.CallOption) (IGrpcStremService_MultiReqSingleRespClient, error)
    // 双向流式 ：集合请求，集合响应
    MultiReqMultiResp(ctx context.Context, opts ...grpc.CallOption) (IGrpcStremService_MultiReqMultiRespClient, error)
}

Write server code server.go and start

• Create a new folder <font color="red">server</font> in the <font color="blue">$GOPATH/src/grpcstream</font> directory, and create a new <font color="red under this folder ">server.go</font>, the content is as follows (I will point out a few points to pay attention to later):

package main

import (
    "context"
    "google.golang.org/grpc"
    pb "grpcstream"
    "io"
    "log"
    "net"
    "strconv"
)

// 常量：监听端口
const (
    port = ":50051"
)

// 定义结构体，在调用注册api的时候作为入参，
// 该结构体会带上proto中定义的方法，里面是业务代码
// 这样远程调用时就执行了业务代码了
type server struct {
    // pb.go中自动生成的，是个空结构体
    pb.UnimplementedIGrpcStremServiceServer
}

// 单项流式 ：单个请求，单个响应
func (s *server) SingleReqSingleResp(ctx context.Context, req *pb.SingleRequest) (*pb.SingleResponse, error) {
    id := req.GetId()

    // 打印请求参数
    log.Println("1. 收到请求:", id)
    // 实例化结构体SingleResponse，作为返回值
    return &pb.SingleResponse{Id: id, Name: "1. name-" + strconv.Itoa(int(id))}, nil
}

// 服务端流式 ：单个请求，集合响应
func (s *server) SingleReqMultiResp(req *pb.SingleRequest, stream pb.IGrpcStremService_SingleReqMultiRespServer) error {
    // 取得请求参数
    id := req.GetId()

    // 打印请求参数
    log.Println("2. 收到请求:", id)

    // 返回多条记录
    for i := 0; i < 10; i++ {
        stream.Send(&pb.SingleResponse{Id: int32(i), Name: "2. name-" + strconv.Itoa(i)})
    }

    return nil
}

// 客户端流式 ：集合请求，单个响应
func (s *server) MultiReqSingleResp(reqStream pb.IGrpcStremService_MultiReqSingleRespServer) error {
    var addVal int32 = 0

    // 在for循环中接收流式请求
    for {
        // 一次接受一条记录
        singleRequest, err := reqStream.Recv()

        // 不等于io.EOF表示这是条有效记录
        if err == io.EOF {
            log.Println("3. 客户端发送完毕")
            break
        } else if err != nil {
            log.Fatalln("3. 接收时发生异常", err)
            break
        } else {
            log.Println("3. 收到请求:", singleRequest.GetId())
            // 收完之后，执行SendAndClose返回数据并结束本次调用
            addVal += singleRequest.GetId()
        }
    }

    return reqStream.SendAndClose(&pb.SingleResponse{Id: addVal, Name: "3. name-" + strconv.Itoa(int(addVal))})
}

// 双向流式 ：集合请求，集合响应
func (s *server) MultiReqMultiResp(reqStream pb.IGrpcStremService_MultiReqMultiRespServer) error {
    // 简单处理，对于收到的每一条记录都返回一个响应
    for {
        singleRequest, err := reqStream.Recv()

        // 不等于io.EOS表示这是条有效记录
        if err == io.EOF {
            log.Println("4. 接收完毕")
            return nil
        } else if err != nil {
            log.Fatalln("4. 接收时发生异常", err)
            return err
        } else {
            log.Println("4. 接收到数据", singleRequest.GetId())

            id := singleRequest.GetId()

            if sendErr := reqStream.Send(&pb.SingleResponse{Id: id, Name: "4. name-" + strconv.Itoa(int(id))}); sendErr != nil {
                log.Println("4. 返回数据异常数据", sendErr)
                return sendErr
            }
        }
    }
}

func main() {
    // 要监听的协议和端口
    lis, err := net.Listen("tcp", port)
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }

    // 实例化gRPC server结构体
    s := grpc.NewServer()

    // 服务注册
    pb.RegisterIGrpcStremServiceServer(s, &server{})

    log.Println("开始监听，等待远程调用...")

    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

• This <font color="blue">server.go</font> file has the following points to note:
• The function of the SingleReqMultiResp method is to receive a request parameter from the client, and then send multiple responses to the client. It can be seen that multiple calls to the <font color="blue">stream.Send</font> method can send data to the client multiple times end;
• The MultiReqSingleResp method can receive multiple pieces of data from the client. It can be seen that the <font color="blue">reqStream.Recv()</font> method is repeatedly called in the for loop until the client’s <font color="red is received. ">io.EOF</font>, this requires the client to send a <font color="red">io.EOF</font> after sending the data, and the client code will be displayed later How to do;
• The MultiReqMultiResp method continuously accepts client data and continuously sends data to the client. The order must be considered clearly, otherwise it will fall into an abnormality (such as an infinite loop). My logic here is to receive the client's <font color="red ">io.EOF</font>, this requires the client to send a <font color="red">io.EOF</font> after sending the data, if the client is also using a for loop Keep waiting for data, that is, both parties are waiting for data and cannot terminate the program. Later client code will show how to do it;
• Execute <font color="blue">go run server.go</font> in the directory where server.go is located, and the console prompt is as follows:

[golang@centos7 server]$ go run server.go 
2020/12/13 21:29:19 开始监听，等待远程调用...

• At this point, the gRPC server has been started and can respond to remote calls. Next, develop the client code;

Write client code client.go

• Open another console;
• Create a new folder <font color="red">client</font> in the <font color="blue">$GOPATH/src/grpcstream</font> directory, and create a new <font color="red under this folder ">client.go</font>, the content is as follows (I will point out a few points to pay attention to later):

package main

import (
    "context"
    "google.golang.org/grpc"
    "io"
    "log"
    "time"

    pb "grpcstream"
)

const (
    address     = "localhost:50051"
    defaultId = "666"
)

func main() {
    // 远程连接服务端
    conn, err := grpc.Dial(address, grpc.WithInsecure(), grpc.WithBlock())
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }

    // main方法执行完毕后关闭远程连接
    defer conn.Close()

    // 实例化数据结构
    client := pb.NewIGrpcStremServiceClient(conn)

    // 超时设置
    ctx, cancel := context.WithTimeout(context.Background(), time.Second)

    defer cancel()

    log.Println("测试单一请求应答，一对一")
    singleReqSingleResp(ctx, client)

    log.Println("测试服务端流式应答，一对多")
    singleReqMultiResp(ctx, client)

    log.Println("测试客户端流式请求，多对一")
    multiReqSingleResp(ctx, client)

    log.Println("测试双向流式请求应答，多对多")
    multiReqMultiResp(ctx, client)

    log.Println("测试完成")
}


func singleReqSingleResp(ctx context.Context, client pb.IGrpcStremServiceClient) error {
    // 远程调用
    r, err := client.SingleReqSingleResp(ctx, &pb.SingleRequest{Id: 101})

    if err != nil {
        log.Fatalf("1. 远程调用异常 : %v", err)
        return err
    }

    // 将服务端的返回信息打印出来
    log.Printf("response, id : %d, name : %s", r.GetId(), r.GetName())

    return nil
}


func singleReqMultiResp(ctx context.Context, client pb.IGrpcStremServiceClient) error {
    // 远程调用
    recvStream, err := client.SingleReqMultiResp(ctx, &pb.SingleRequest{Id: 201})

    if err != nil {
        log.Fatalf("2. 远程调用异常 : %v", err)
        return err
    }

    for {
        singleResponse, err := recvStream.Recv()
        if err == io.EOF {
            log.Printf("2. 获取数据完毕")
            break
        }

        log.Printf("2. 收到服务端响应, id : %d, name : %s", singleResponse.GetId(), singleResponse.GetName())
    }

    return nil
}

func multiReqSingleResp(ctx context.Context, client pb.IGrpcStremServiceClient) error {
    // 远程调用
    sendStream, err := client.MultiReqSingleResp(ctx)

    if err != nil {
        log.Fatalf("3. 远程调用异常 : %v", err)
        return err
    }

    // 发送多条记录到服务端
    for i:=0; i<10; i++ {
        if err = sendStream.Send(&pb.SingleRequest{Id: int32(300+i)}); err!=nil {
            log.Fatalf("3. 通过流发送数据异常 : %v", err)
            return err
        }
    }

    singleResponse, err := sendStream.CloseAndRecv()

    if err != nil {
        log.Fatalf("3. 服务端响应异常 : %v", err)
        return err
    }

    // 将服务端的返回信息打印出来
    log.Printf("response, id : %d, name : %s", singleResponse.GetId(), singleResponse.GetName())

    return nil
}

func multiReqMultiResp(ctx context.Context, client pb.IGrpcStremServiceClient) error {
    // 远程调用
    intOutStream, err := client.MultiReqMultiResp(ctx)

    if err != nil {
        log.Fatalf("4. 远程调用异常 : %v", err)
        return err
    }

    // 发送多条记录到服务端
    for i:=0; i<10; i++ {
        if err = intOutStream.Send(&pb.SingleRequest{Id: int32(400+i)}); err!=nil {
            log.Fatalf("4. 通过流发送数据异常 : %v", err)
            return err
        }
    }

    // 服务端一直在接收，直到收到io.EOF为止
    // 因此，这里必须发送io.EOF到服务端，让服务端知道发送已经结束(很重要)
    intOutStream.CloseSend()

    // 接收服务端发来的数据
    for {
        singleResponse, err := intOutStream.Recv()
        if err == io.EOF {
            log.Printf("4. 获取数据完毕")
            break
        } else if err != nil {
            log.Fatalf("4. 接收服务端数据异常 : %v", err)
            break
        }

        log.Printf("4. 收到服务端响应, id : %d, name : %s", singleResponse.GetId(), singleResponse.GetName())
    }

    return nil
}

• This <font color="blue">client.go</font> file has the following points to note:
• The singleReqMultiResp method will receive multiple records from the server, and call <font color="blue">recvStream.Recv</font> in the for loop to receive all the data;
• The multiReqSingleResp method will send multiple pieces of data to the server. Since the server is waiting for <font color="red">io.EOF</font> as the end sign, it calls <font color="blue">sendStream.CloseAndRecv</ font> can send <font color="red">io.EOF</font>, and get the return value of the server;
• The multiReqMultiResp method continues to send data to the server, and also continues to obtain the data sent by the server. After sending the data, you must call the <font color="blue">intOutStream.CloseSend</font> method to send <font color="red">io.EOF</font>, so that the server no longer receives data, avoiding the aforementioned infinite loop;
• In the main method, four types of service method calls are initiated in turn;

Execute client

• After the coding is completed, execute <font color="blue">go run client.go</font> in the directory where client.go is located, and it will immediately initiate a remote call to the server. The console prompts as follows, showing that all four types of service methods are tested Success, the response data are in line with expectations:

[golang@centos7 client]$ go run client.go 
2020/12/13 21:39:35 测试单一请求应答，一对一
2020/12/13 21:39:35 response, id : 101, name : 1. name-101
2020/12/13 21:39:35 测试服务端流式应答，一对多
2020/12/13 21:39:35 2. 收到服务端响应, id : 0, name : 2. name-0
2020/12/13 21:39:35 2. 收到服务端响应, id : 1, name : 2. name-1
2020/12/13 21:39:35 2. 收到服务端响应, id : 2, name : 2. name-2
2020/12/13 21:39:35 2. 收到服务端响应, id : 3, name : 2. name-3
2020/12/13 21:39:35 2. 收到服务端响应, id : 4, name : 2. name-4
2020/12/13 21:39:35 2. 收到服务端响应, id : 5, name : 2. name-5
2020/12/13 21:39:35 2. 收到服务端响应, id : 6, name : 2. name-6
2020/12/13 21:39:35 2. 收到服务端响应, id : 7, name : 2. name-7
2020/12/13 21:39:35 2. 收到服务端响应, id : 8, name : 2. name-8
2020/12/13 21:39:35 2. 收到服务端响应, id : 9, name : 2. name-9
2020/12/13 21:39:35 2. 获取数据完毕
2020/12/13 21:39:35 测试客户端流式请求，多对一
2020/12/13 21:39:35 response, id : 3045, name : 3. name-3045
2020/12/13 21:39:35 测试双向流式请求应答，多对多
2020/12/13 21:39:35 4. 收到服务端响应, id : 400, name : 4. name-400
2020/12/13 21:39:35 4. 收到服务端响应, id : 401, name : 4. name-401
2020/12/13 21:39:35 4. 收到服务端响应, id : 402, name : 4. name-402
2020/12/13 21:39:35 4. 收到服务端响应, id : 403, name : 4. name-403
2020/12/13 21:39:35 4. 收到服务端响应, id : 404, name : 4. name-404
2020/12/13 21:39:35 4. 收到服务端响应, id : 405, name : 4. name-405
2020/12/13 21:39:35 4. 收到服务端响应, id : 406, name : 4. name-406
2020/12/13 21:39:35 4. 收到服务端响应, id : 407, name : 4. name-407
2020/12/13 21:39:35 4. 收到服务端响应, id : 408, name : 4. name-408
2020/12/13 21:39:35 4. 收到服务端响应, id : 409, name : 4. name-409
2020/12/13 21:39:35 4. 获取数据完毕
2020/12/13 21:39:35 测试完成

• Go to the console of the server again and look at it. The log finds that the business code is executed and the parameters of the remote request are received:

[golang@centos7 server]$ go run server.go 
2020/12/13 21:29:19 开始监听，等待远程调用...
2020/12/13 21:39:35 1. 收到请求: 101
2020/12/13 21:39:35 2. 收到请求: 201
2020/12/13 21:39:35 3. 收到请求: 300
2020/12/13 21:39:35 3. 收到请求: 301
2020/12/13 21:39:35 3. 收到请求: 302
2020/12/13 21:39:35 3. 收到请求: 303
2020/12/13 21:39:35 3. 收到请求: 304
2020/12/13 21:39:35 3. 收到请求: 305
2020/12/13 21:39:35 3. 收到请求: 306
2020/12/13 21:39:35 3. 收到请求: 307
2020/12/13 21:39:35 3. 收到请求: 308
2020/12/13 21:39:35 3. 收到请求: 309
2020/12/13 21:39:35 3. 客户端发送完毕
2020/12/13 21:39:35 4. 接收到数据 400
2020/12/13 21:39:35 4. 接收到数据 401
2020/12/13 21:39:35 4. 接收到数据 402
2020/12/13 21:39:35 4. 接收到数据 403
2020/12/13 21:39:35 4. 接收到数据 404
2020/12/13 21:39:35 4. 接收到数据 405
2020/12/13 21:39:35 4. 接收到数据 406
2020/12/13 21:39:35 4. 接收到数据 407
2020/12/13 21:39:35 4. 接收到数据 408
2020/12/13 21:39:35 4. 接收到数据 409
2020/12/13 21:39:35 4. 接收完毕

• So far, we have tried the server-side and client-side development of the four types of service methods of gRPC. These four types of methods can already cover most business scenario requirements. I hope this article can give you some reference. The next article will continue to learn. Rich functions of gRPC;

You are not lonely, Xinchen is with you all the way

1. Java series
2. Spring series
3. Docker series
4. kubernetes series
5. database + middleware series
6. DevOps series

Welcome to pay attention to the public account: programmer Xin Chen

Search "Programmer Xin Chen" on WeChat, I am Xin Chen, and I look forward to traveling the Java world with you...
https://github.com/zq2599/blog_demos