前言
一、gRPC的请求模型
二、HTTP/2
三、gRPC Streaming, Client and Server
- 1、为什么我们要用流式传输，简单的一元RPC不行么？
- 2、目录结构
- 3、编写IDL
- 4、Makefile
- 5、写出基础模板和空定义
- - 1）server.go
  - 2）client.go
- 6、Server-side streaming RPC：服务器端流式 RPC
- - 1）server
  - 2）client
  - 3）启动 & 请求
- 7、Client-side streaming RPC：客户端流式 RPC
- - 1）server
  - 2）client
  - 3）启动 & 请求
- 8、Bidirectional streaming RPC：双向流式 RPC
- - 1）server
  - 2）client
  - 3）启动 & 请求
四、小结

前言

这章的内容需要安装好插件和protoc，建议阅读我的上一篇grpc使用篇
个人网站：https://linzyblog.netlify.app/
示例代码已经上传到github：点击跳转
gRPC官方文档：点击跳转

一、gRPC的请求模型

gRPC 有两种类型的请求模型：

一元 - 直接的请求响应映射在 HTTP/2 请求响应之上。
- 简单来说一元就是一个简单的 RPC，其中客户端使用存根向服务器发送请求并等待响应返回，就像正常的函数调用一样。

rpc SayHi(Request) returns (Response);

流式传输——多个请求和响应通过长寿命 HTTP/2 流进行交换，可以是单向或双向的。
- 其中许多进程可以通过 HTTP/2 的多路复用能力（通过单个 TCP 连接一起发送多个响应或接收多个请求）在单个请求中发生。
- Server-side streaming RPC—— 客户端向服务器发送单个请求并接收回数据序列流（读回一系列消息）。客户端从返回的流中读取，直到没有更多消息为止。
- Client-side streaming RPC—— 客户端向服务器发送数据序列流（写入一系列消息），一旦客户端完成了消息的写入，它会等待服务器读取所有消息并返回其响应结果。
- Bidirectional streaming RPC—— 它是双向流式传输，客户端和服务器使用读写流发送一系列消息。两个流独立运行；因此，因此客户端和服务器可以按照他们喜欢的任何顺序读取和写入。保留每个流中消息的顺序。例如，服务器可以在写入响应之前等待接收所有客户端消息，或者它可以交替读取消息然后写入消息，或其他一些读取和写入的组合。

Server-side streaming RPC：服务器端流式 RPC
Client-side streaming RPC：客户端流式 RPC
Bidirectional streaming RPC：双向流式 RPC
stream可以通过将关键字放在请求类型之前来指定流式处理方法。

二、HTTP/2

gRPC 是基于HTTP/2开发的，该协议于 2015 年发布，以克服 HTTP/1.1 的限制。在兼容 HTTP/1.1 的同时，我们来了解一下HTTP/2 带来了许多高级功能，例如：

二进制分帧层 —— 与 HTTP/1.1 不同，HTTP/2 请求/响应分为小消息并以二进制格式分帧，使消息传输高效。通过二进制帧，HTTP/2 协议使请求/响应多路复用成为可能，而不会阻塞网络资源。
流式传输 —— 客户端可以请求并且服务器可以同时响应的双向全双工流式传输。
流控制 —— HTTP/2 中使用流控制机制，可以对用于缓冲动态消息的内存进行详细控制。
标头压缩 —— HTTP/2 中的所有内容，包括标头，都在发送前进行编码，显着提高了整体性能。使用 HPACK 压缩方式，HTTP/2 只共享与之前的 HTTP 头包不同的值。
处理 —— 使用 HTTP/2，gRPC 支持同步和异步处理，可用于执行不同类型的交互和流式 RPC。

HTTP/2 的所有这些特性使 gRPC 能够使用更少的资源，从而减少在云中运行的应用程序和服务之间的响应时间，并延长运行移动设备的客户端的电池寿命。

三、gRPC Streaming, Client and Server

1、为什么我们要用流式传输，简单的一元RPC不行么？

流式为什么要存在呢？我们在使用一元请求的时候可能会遇到以下问题：

数据包过大会造成的瞬时压力。
接收数据包时，需要所有数据包都接受成功且正确后，才能够回调响应，进行业务处理（无法客户端边发送，服务端边处理）

而流式传输却可以：

HTTP2 通过长期 TCP 连接多路复用流，因此新请求没有 TCP 连接开销。HTTP2 成帧允许在单个 TCP 数据包中发送多个 gRPC 消息。
对于长期连接，流式请求应该在每条消息的基础上具有最佳性能。一元请求需要为每个请求建立一个新的 HTTP2 流，包括通过网络发送的附加标头帧。一旦建立，通过流式请求发送的每条新消息只需要通过连接发送消息的数据帧。

2、目录结构

go-grpc-example
├── client
│   └──hello_client
│   │   └── client.go
│   └── stream_client
│       └── client.go
├── proto
│   └──hello
│   │   └── hello.proto
│   └──stream
│   │   └── stream.proto
├── server
│   └──hello_server
│   │   └── server.go
│   └──stream_server
│   │   └── server.go
├── Makefile

增加 stream_server、stream_client 存放服务端和客户端文件，proto/stream/stream.proto 用于编写 IDL

3、编写IDL

在 proto/stream 文件夹下的 stream.proto 文件中，写入如下内容：

syntax = "proto3";option go_package="./proto/stream;stream";
package proto;service StreamService {//List：服务器端流式 RPCrpc List(StreamRequest) returns (stream StreamResponse) {};//Record：客户端流式 RPCrpc Record(stream StreamRequest) returns (StreamResponse) {};//Route：双向流式 RPCrpc Route(stream StreamRequest) returns (stream StreamResponse) {};
}message StreamPoint {string name = 1;int32 value = 2;
}message StreamRequest {StreamPoint pt = 1;
}message StreamResponse {StreamPoint pt = 1;
}

注意关键字 stream，声明其为一个流方法。这里共涉及三个方法，对应关系为

List：服务器端流式 RPC
Record：客户端流式 RPC
Route：双向流式 RPC

4、Makefile

这是我拖了很久的关于Makefile的用法，感觉Makefile更适合在项目使用中穿插讲解一下。

有一篇很不错的Makefile文档：点击跳转

作用：Makefile 用于帮助决定大型程序的哪些部分需要重新编译。

这里我们用make gen指令代替proto插件从我们的.proto 服务定义中生成 gRPC 客户端和服务器接口。

在Makefile文件中写入：

gen:protoc --go_out=. --go-grpc_out=. ./proto/stream/*.proto

用make gen指令生成Go代码：

➜ make gen
protoc --go_out=. --go-grpc_out=. ./proto/stream/*.proto

注意使用Makefile生成的时候，要注意.proto文件 go_package 指定生成的位置。

5、写出基础模板和空定义

我们先把基础的模板和空定义写出来在进行完善，不太懂的看我上一篇文章

1）server.go

type StreamService struct {pb.UnimplementedStreamServiceServer
}const PORT = "8888"func main() {server := grpc.NewServer() //创建 gRPC Server 对象pb.RegisterStreamServiceServer(server, &StreamService{})lis, err := net.Listen("tcp", ":"+PORT)if err != nil {log.Fatalf("net.Listen err: %v", err)}server.Serve(lis)
}//服务端流式RPC，Server是Stream，Client为普通RPC请求
//客户端发送一次普通的RPC请求，服务端通过流式响应多次发送数据集
func (s *StreamService) List(r *pb.StreamRequest, stream pb.StreamService_ListServer) error {return nil
}//客户端流式RPC，单向流
//客户端通过流式多次发送RPC请求给服务端，服务端发送一次普通的RPC请求给客户端
func (s *StreamService) Record(stream pb.StreamService_RecordServer) error {return nil
}//双向流，由客户端发起流式的RPC方法请求，服务端以同样的流式RPC方法响应请求
//首个请求一定是client发起，具体交互方法（谁先谁后，一次发多少，响应多少，什么时候关闭）根据程序编写方式来确定（可以结合协程）
func (s *StreamService) Route(stream pb.StreamService_RouteServer) error {return nil
}

2）client.go

const PORT = "8888"func main() {conn, err := grpc.Dial(":"+PORT, grpc.WithInsecure())if err != nil {log.Fatalf("grpc.Dial err: %v", err)}defer conn.Close()client := pb.NewStreamServiceClient(conn)err = printLists(client, &pb.StreamRequest{Pt: &pb.StreamPoint{Name: "gRPC Stream Client: List", Value: 1234}})if err != nil {log.Fatalf("printLists.err: %v", err)}err = printRecord(client, &pb.StreamRequest{Pt: &pb.StreamPoint{Name: "gRPC Stream Client: Record", Value: 9999}})if err != nil {log.Fatalf("printRecord.err: %v", err)}err = printRoute(client, &pb.StreamRequest{Pt: &pb.StreamPoint{Name: "gRPC Stream Client: Route", Value: 1111}})if err != nil {log.Fatalf("printRoute.err: %v", err)}
}func printLists(client pb.StreamServiceClient, r *pb.StreamRequest) error {return nil
}func printRecord(client pb.StreamServiceClient, r *pb.StreamRequest) error {return nil
}func printRoute(client pb.StreamServiceClient, r *pb.StreamRequest) error {return nil
}

6、Server-side streaming RPC：服务器端流式 RPC

服务端流式RPC，Server是Stream，Client为普通RPC请求，客户端发送一次普通的RPC请求，服务端通过流式响应多次发送数据集。

1）server

/*
1. 建立连接 获取client
2. 通过 client 获取stream
3. for循环中通过stream.Recv()依次获取服务端推送的消息
4. err==io.EOF则表示服务端关闭stream了
*/
func (s *StreamService) List(r *pb.StreamRequest, stream pb.StreamService_ListServer) error {// 具体返回多少个response根据业务逻辑调整for n := 0; n <= 6; n++ {// 通过 send 方法不断推送数据err := stream.Send(&pb.StreamResponse{Pt: &pb.StreamPoint{Name:  r.Pt.Name,Value: r.Pt.Value + int32(n),},})if err != nil {return err}time.Sleep(time.Second)}// 返回nil表示已经完成响应return nil
}

在 Server，主要留意 stream.Send 方法。它看上去能发送 N 次？有没有大小限制？

type StreamService_ListServer interface {Send(*StreamResponse) errorgrpc.ServerStream
}func (x *streamServiceListServer) Send(m *StreamResponse) error {return x.ServerStream.SendMsg(m)
}

通过阅读源码，可得知是 protoc 在生成时，根据定义生成了各式各样符合标准的接口方法。最终再统一调度内部的 SendMsg 方法，该方法涉及以下过程:

消息体（对象）序列化
压缩序列化后的消息体
对正在传输的消息体增加 5 个字节的 header
判断压缩+序列化后的消息体总字节长度是否大于预设的 maxSendMessageSize（预设值为 math.MaxInt32），若超出则提示错误
写入给流的数据集

2）client

/*
1. 建立连接 获取client
2. 通过 client 获取stream
3. for循环中通过stream.Recv()依次获取服务端推送的消息
4. err==io.EOF则表示服务端关闭stream了
*/
func printLists(client pb.StreamServiceClient, r *pb.StreamRequest) error {// 调用获取streamstream, err := client.List(context.Background(), r)if err != nil {return err}// for循环获取服务端推送的消息for {// 通过 Recv() 不断获取服务端send()推送的消息resp, err := stream.Recv()// err==io.EOF则表示服务端关闭stream了if err == io.EOF {break}if err != nil {return err}log.Printf("resp: pj.name: %s, pt.value: %d", resp.Pt.Name, resp.Pt.Value)}return nil
}

在 Client，主要留意 stream.Recv() 方法。什么情况下 io.EOF ？什么情况下存在错误信息呢?

type StreamService_ListClient interface {Recv() (*StreamResponse, error)grpc.ClientStream
}func (x *streamServiceListClient) Recv() (*StreamResponse, error) {m := new(StreamResponse)if err := x.ClientStream.RecvMsg(m); err != nil {return nil, err}return m, nil
}

RecvMsg 会从流中读取完整的 gRPC 消息体，另外通过阅读源码可得知：

（1）RecvMsg 是阻塞等待的

（2）RecvMsg 当流成功/结束（调用了 Close）时，会返回 io.EOF

（3）RecvMsg 当流出现任何错误时，流会被中止，错误信息会包含 RPC 错误码。而在 RecvMsg 中可能出现如下错误：

io.EOF
io.ErrUnexpectedEOF
transport.ConnectionError
google.golang.org/grpc/codes

3）启动 & 请求

# 启动服务端
$ go run server.go
API server listening at: 127.0.0.1:55149# 启动客户端
$ go run client.go
API server listening at: 127.0.0.1:55158
2022/11/03 09:35:03 resp: pj.name: gRPC Stream Client: List, pt.value: 1234
2022/11/03 09:35:04 resp: pj.name: gRPC Stream Client: List, pt.value: 1235
2022/11/03 09:35:05 resp: pj.name: gRPC Stream Client: List, pt.value: 1236
2022/11/03 09:35:06 resp: pj.name: gRPC Stream Client: List, pt.value: 1237
2022/11/03 09:35:07 resp: pj.name: gRPC Stream Client: List, pt.value: 1238
2022/11/03 09:35:08 resp: pj.name: gRPC Stream Client: List, pt.value: 1239
2022/11/03 09:35:09 resp: pj.name: gRPC Stream Client: List, pt.value: 1240

服务器流式 RPC 类似于一元 RPC，除了服务器返回消息流以响应客户端的请求。发送所有消息后，服务器的状态详细信息（状态代码和可选状态消息）和可选尾随元数据将发送到客户端。这样就完成了服务器端的处理。客户端在拥有服务器的所有消息后完成。

7、Client-side streaming RPC：客户端流式 RPC

客户端通过流式多次发送RPC请求给服务端，服务端发送一次响应给客户端。

1）server

/*
1. for循环中通过stream.Recv()不断接收client传来的数据
2. err == io.EOF表示客户端已经发送完毕关闭连接了,此时在等待服务端处理完并返回消息
3. stream.SendAndClose() 发送消息并关闭连接(虽然在客户端流里服务器这边并不需要关闭 但是方法还是叫的这个名字，内部也只会调用Send())
*/
func (s *StreamService) Record(stream pb.StreamService_RecordServer) error {// for循环接收客户端发送的消息for {// 通过 Recv() 不断获取客户端 send()推送的消息r, err := stream.Recv()// err == io.EOF表示已经获取全部数据if err == io.EOF {// SendAndClose 返回并关闭连接// 在客户端发送完毕后服务端即可返回响应return stream.SendAndClose(&pb.StreamResponse{Pt: &pb.StreamPoint{Name: "gRPC Stream Server: Record", Value: 1}})}if err != nil {return err}log.Printf("stream.Recv pt.name: %s, pt.value: %d", r.Pt.Name, r.Pt.Value)time.Sleep(time.Second)}return nil
}

stream.SendAndClose：我们对每一个 Recv 都进行了处理，当发现 io.EOF (流关闭) 后，需要将最终的响应结果发送给客户端，同时关闭正在另外一侧等待的 Recv

2）client

/*
1. 建立连接并获取client
2. 获取 stream 并通过 Send 方法不断推送数据到服务端
3. 发送完成后通过stream.CloseAndRecv() 关闭stream并接收服务端返回结果
*/
func printRecord(client pb.StreamServiceClient, r *pb.StreamRequest) error {// 获取 streamstream, err := client.Record(context.Background())if err != nil {return err}for i := 0; i <= 6; i++ {// 通过 Send 方法不断推送数据到服务端err := stream.Send(r)if err != nil {return err}}// 发送完成后通过stream.CloseAndRecv() 关闭stream并接收服务端返回结果// (服务端则根据err==io.EOF来判断client是否关闭stream)resp, err := stream.CloseAndRecv()if err != nil {return err}log.Printf("resp: pj.name: %s, pt.value: %d", resp.Pt.Name, resp.Pt.Value)return nil
}

stream.CloseAndRecv 和 stream.SendAndClose 是配套使用的流方法

3）启动 & 请求

# 启动服务端
$ go run server.go
API server listening at: 127.0.0.1:57789
2022/11/03 11:59:31 stream.Recv pt.name: gRPC Stream Client: Record, pt.value: 9999
2022/11/03 11:59:32 stream.Recv pt.name: gRPC Stream Client: Record, pt.value: 9999
2022/11/03 11:59:33 stream.Recv pt.name: gRPC Stream Client: Record, pt.value: 9999
2022/11/03 11:59:34 stream.Recv pt.name: gRPC Stream Client: Record, pt.value: 9999
2022/11/03 11:59:35 stream.Recv pt.name: gRPC Stream Client: Record, pt.value: 9999
2022/11/03 11:59:36 stream.Recv pt.name: gRPC Stream Client: Record, pt.value: 9999
2022/11/03 11:59:37 stream.Recv pt.name: gRPC Stream Client: Record, pt.value: 9999# 启动客户端
$ go run client.go
API server listening at: 127.0.0.1:57793
2022/11/03 11:59:38 resp: pj.name: gRPC Stream Server: Record, pt.value: 1

8、Bidirectional streaming RPC：双向流式 RPC

双向流，由客户端发起流式的RPC方法请求，服务端以同样的流式RPC方法响应请求首个请求一定是client发起，具体交互方法（谁先谁后，一次发多少，响应多少，什么时候关闭）根据程序编写方式来确定（可以结合协程）。

1）server

一般是使用两个 Goroutine，一个接收数据，一个推送数据。最后通过 return nil 表示已经完成响应。

/*
// 1. 建立连接 获取client
// 2. 通过client调用方法获取stream
// 3. 开两个goroutine（使用 chan 传递数据） 分别用于Recv()和Send()
// 3.1 一直Recv()到err==io.EOF(即客户端关闭stream)
// 3.2 Send()则自己控制什么时候Close 服务端stream没有close 只要跳出循环就算close了。 具体见https://github.com/grpc/grpc-go/issues/444
*/
func (s *StreamService) Route(stream pb.StreamService_RouteServer) error {var (wg    sync.WaitGroup //任务编排msgCh = make(chan *pb.StreamPoint))wg.Add(1)go func() {n := 0defer wg.Done()for v := range msgCh {err := stream.Send(&pb.StreamResponse{Pt: &pb.StreamPoint{Name:  v.GetName(),Value: int32(n),},})if err != nil {fmt.Println("Send error :", err)continue}n++}}()wg.Add(1)go func() {defer wg.Done()for {r, err := stream.Recv()if err == io.EOF {break}if err != nil {log.Fatalf("recv error :%v", err)}log.Printf("stream.Recv pt.name: %s, pt.value: %d", r.Pt.Name, r.Pt.Value)msgCh <- &pb.StreamPoint{Name: "gRPC Stream Server: Route",}}close(msgCh)}()wg.Wait() //等待任务结束return nil
}

2）client

和服务端类似，不过客户端推送结束后需要主动调用 stream.CloseSend() 函数来关闭Stream。

/*
1. 建立连接 获取client
2. 通过client获取stream
3. 开两个goroutine 分别用于Recv()和Send()3.1 一直Recv()到err==io.EOF(即服务端关闭stream)3.2 Send()则由自己控制
4. 发送完毕调用 stream.CloseSend()关闭stream 必须调用关闭 否则Server会一直尝试接收数据 一直报错...
*/
func printRoute(client pb.StreamServiceClient, r *pb.StreamRequest) error {var wg sync.WaitGroup// 调用方法获取streamstream, err := client.Route(context.Background())if err != nil {return err}// 开两个goroutine 分别用于Recv()和Send()wg.Add(1)go func() {defer wg.Done()for {resp, err := stream.Recv()if err == io.EOF {fmt.Println("Server Closed")break}if err != nil {continue}log.Printf("resp: pj.name: %s, pt.value: %d", resp.Pt.Name, resp.Pt.Value)}}()wg.Add(1)go func() {defer wg.Done()for n := 0; n <= 6; n++ {err := stream.Send(r)if err != nil {log.Printf("send error:%v\n", err)}time.Sleep(time.Second)}// 发送完毕关闭streamerr = stream.CloseSend()if err != nil {log.Printf("Send error:%v\n", err)return}}()wg.Wait()return nil
}

3）启动 & 请求

# 启动服务端
$ go run server.go
API server listening at: 127.0.0.1:55108
2022/11/03 12:29:35 stream.Recv pt.name: gRPC Stream Client: Route, pt.value: 1111
2022/11/03 12:29:36 stream.Recv pt.name: gRPC Stream Client: Route, pt.value: 1111
2022/11/03 12:29:37 stream.Recv pt.name: gRPC Stream Client: Route, pt.value: 1111
2022/11/03 12:29:38 stream.Recv pt.name: gRPC Stream Client: Route, pt.value: 1111
2022/11/03 12:29:39 stream.Recv pt.name: gRPC Stream Client: Route, pt.value: 1111
2022/11/03 12:29:40 stream.Recv pt.name: gRPC Stream Client: Route, pt.value: 1111
2022/11/03 12:29:41 stream.Recv pt.name: gRPC Stream Client: Route, pt.value: 1111# 启动客户端
$ go run client.go
API server listening at: 127.0.0.1:55113
2022/11/03 12:29:35 resp: pj.name: gRPC Stream Server: Route, pt.value: 0
2022/11/03 12:29:36 resp: pj.name: gRPC Stream Server: Route, pt.value: 1
2022/11/03 12:29:37 resp: pj.name: gRPC Stream Server: Route, pt.value: 2
2022/11/03 12:29:38 resp: pj.name: gRPC Stream Server: Route, pt.value: 3
2022/11/03 12:29:39 resp: pj.name: gRPC Stream Server: Route, pt.value: 4
2022/11/03 12:29:40 resp: pj.name: gRPC Stream Server: Route, pt.value: 5
2022/11/03 12:29:41 resp: pj.name: gRPC Stream Server: Route, pt.value: 6
Server Closed

四、小结

客户端或者服务端都有对应的推送或者接收对象，我们只要不断循环 Recv()或者 Send() 就能接收或者推送了！

gRPC Stream 和 goroutine 配合简直完美。通过 Stream 我们可以更加灵活的实现自己的业务。如订阅，大数据传输等。

Client发送完成后需要手动调用Close()或者CloseSend()方法关闭stream，Server端则return nil就会自动 Close。

1）ServerStream

服务端处理完成后return nil代表响应完成
客户端通过 err == io.EOF判断服务端是否响应完成

2）ClientStream

客户端发送完毕通过CloseAndRecv关闭stream 并接收服务端响应
服务端通过 err == io.EOF判断客户端是否发送完毕，完毕后使用SendAndClose关闭 stream并返回响应。

3）BidirectionalStream

客户端服务端都通过stream向对方推送数据
客户端推送完成后通过CloseSend关闭流，通过err == io.EOF判断服务端是否响应完成
服务端通过err == io.EOF判断客户端是否响应完成,通过return nil表示已经完成响应
通过err == io.EOF来判定是否把对方推送的数据全部获取到了。

客户端通过CloseAndRecv或者CloseSend关闭 Stream，服务端则通过SendAndClose或者直接 return nil来返回响应。

参考文章：
https://www.lixueduan.com/posts/grpc/03-stream/#4-serverstream

gRPC（四）基础：gRPC流相关推荐

gRPC四种模式、认证和授权实战演示
前言上一篇对gRPC进行简单介绍,并通过示例体验了一下开发过程.接下来说说实际开发常用功能,如:gRPC的四种模式.gRPC集成JWT做认证和授权等. 正文 1. gRPC四种模式服务以下案例演示 ...
grpc java 基础教程
1 RPC 框架原理 RPC 框架的目标就是让远程服务调用更加简单.透明,RPC 框架负责屏蔽底层的传输方式(TCP 或者 UDP).序列化方式(XML/Json/ 二进制)和通信细节.服务调用者可以 ...
C++基础（四）文件流 I/O流文件指针 tellg tellp seekp seekg
C++中的有关文件的设计,由于历史原因,着实不太好用,里面的坑很多. 一.常见文件打开方式文件模式常量含义常量含义 ios_base::in 以读的方式打开文件 ios_base::out 以写 ...
grpc python stream_Python gRPC笔记
简介: gRPC 是Google发布的一个高性能.开源和通用的 RPC 框架,面向移动和 HTTP/2 设计.gRPC提供了支持多种编程语言的.对网络设备进行配置和纳管的方法.目前提供 C.Java ...
深入浅出 gRPC 04：gRPC 服务调用原理
目录 1. 常用的服务调用方式 1.1 同步服务调用 1.2 并行服务调用 1.3 异步服务调用 2. 服务调用的一些误区和典型问题 2.1 理解误区 2.1.1 I/O 异步服务就是异步 2.1.2 ...
深入浅出 gRPC 01：gRPC 服务端创建和调用原理
目录 1. RPC 入门 1.1 RPC 框架原理 1.2 业界主流的 RPC 框架 1.3 gRPC 简介 1.3.1 gRPC 概览 1.3.2 gRPC 特点 2. gRPC 服务端创建 2.1 ...
grpc：hello grpc
安装grpc gRPC,即google Remote Procedure Call Protocol:在gRPC里,客户端可以直接调用不同机器上的服务应用的方法,就像本地对象一样,所以创建分布式应用和 ...
# Java基础——IO流
Java基础--IO流 File类的使用(熟悉构造器和方法的使用) File类的一个对象,代表一个文件或一个文件目录(俗称:文件夹) File类的声明在java.io包下文件和文件目录路径的抽象表示 ...
弘辽科技：适合淘宝新手的三种基础引流技巧
原标题<弘辽科技:适合淘宝新手的三种基础引流技巧> 要想网店生意好,那流量是必不可缺少的因素,因为流量是一家网店运营的基础,没有流量的店铺基本上无法维持正常运营的.作为一家网店的运营者,大 ...
Java IO流学习总结四：缓冲流-BufferedReader、BufferedWriter
Java IO流学习总结四:缓冲流-BufferedReader.BufferedWriter 转载请标明出处:http://blog.csdn.net/zhaoyanjun6/article/det ...

gRPC（四）基础：gRPC流

目录

前言

一、gRPC的请求模型

二、HTTP/2

三、gRPC Streaming, Client and Server

1、为什么我们要用流式传输，简单的一元RPC不行么？

2、目录结构

3、编写IDL

4、Makefile

5、写出基础模板和空定义

1）server.go

2）client.go

6、Server-side streaming RPC：服务器端流式 RPC

1）server

2）client

3）启动 & 请求

7、Client-side streaming RPC：客户端流式 RPC

1）server

2）client

3）启动 & 请求

8、Bidirectional streaming RPC：双向流式 RPC

1）server

2）client

3）启动 & 请求

四、小结

gRPC（四）基础：gRPC流相关推荐

最新文章

热门文章