gRPC(1):入门及简单使用(go) 中,我们实现了一个简单的 gRPC 应用程序,其中双方通信是简单的请求—响应模式,没发出一个请求都会得到一个响应,然而,借助 gRPC 可以实现不同的通信模式,这里介绍四种 gRPC 应用程序的基础通信模式:一元RPC、服务端流RPC、客户端流RPC、双向流RPC

1、一元RPC

一元 RPC 也被称为简单 RPC, 其实就是 gRPC(1):入门及简单使用(go) 中实现的请求—响应模式,每调用一次得到一个结果,这里再以一个简单的订单管理程序做说明,实现两个服务:addOrder 用于添加订单;getOrder 用于根据 id 获取订单:

  • 服务定义
syntax = "proto3";
package proto;
option go_package = "./proto"; service OrderManagement {
rpc addOrder(Order) returns (StringValue);
rpc getOrder(StringValue) returns (Order);
} message Order {
string id = 1;
repeated string items = 2; // repeated 表示列表
string description = 3;
float price = 4;
string destination = 5;
} message StringValue {
string value = 1;
}
  • 服务端实现
package main

import (
"context"
"fmt"
"log"
"net"
"strings" pb "order/proto" "github.com/gofrs/uuid"
"google.golang.org/grpc"
"google.golang.org/grpc/codes"
"google.golang.org/grpc/status"
) const (
port = ":50051"
) type server struct {
pb.UnimplementedOrderManagementServer
} // 模拟存储
var orderMap = make(map[string]*pb.Order) func (s *server) AddOrder(ctx context.Context, order *pb.Order) (*pb.StringValue, error) {
id, err := uuid.NewV4()
if err != nil {
return nil, status.Errorf(codes.Internal, "Error while generating Product ID", err)
}
order.Id = id.String()
orderMap[order.Id] = order
log.Printf("Order %v : %v - Added.", order.Id, order.Description)
return &pb.StringValue{Value: order.Id}, nil
} func (s *server) GetOrder(ctx context.Context, orderID *pb.StringValue) (*pb.Order, error) {
order, exists := orderMap[orderID.Value]
if exists && order != nil {
log.Printf("Order %v : %v - Retrieved.", order.Id, order.Description)
return order, nil
}
return nil, status.Errorf(codes.NotFound, "Order does not exist.", orderID.Value)
} func main() {
lis, err := net.Listen("tcp", port)
if err != nil {
log.Fatalf("failed to listen: %v", err)
}
s := grpc.NewServer()
pb.RegisterOrderManagementServer(s, &server{})
if err := s.Serve(lis); err != nil {
log.Fatalf("failed to serve: %v", err)
}
}
  • 客户端实现
package main

import (
"context"
"io"
"log"
"time" pb "order/proto" "google.golang.org/grpc"
) const (
address = "localhost:50051"
) func main() {
conn, err := grpc.Dial(address, grpc.WithInsecure())
if err != nil {
log.Fatalf("did not connect: %v", err)
}
defer conn.Close() c := pb.NewOrderManagementClient(conn) orderID, err := c.AddOrder(context.Background(),
&pb.Order{
Items: []string{"XiaoMI 11"},
Description: "XiaoMI 11",
Price: 3999,
Destination: "suzhou",
})
if err != nil {
log.Fatalf("could not add order: %v", err)
}
log.Printf("Added order: %v", orderID.Value)
}

2、服务端流RPC

与一元 RPC 不同的是,流模式下响应或者请求都可以是一个序列,这个序列也被称为”流“,服务端流 RPC 下,客户端发出一个请求,但不会立即得到一个响应,而是在服务端与客户端之间建立一个单向的流,服务端可以随时向流中写入多个响应消息,最后主动关闭流,而客户端需要监听这个流,不断获取响应直到流关闭

下面以一个简单的关键词搜索功能为例,客户端发送关键字,服务端进行匹配,每找到一个就写进流中,在之前的基础上添加代码:

  • 服务定义
service OrderManagement {
...
// stream 将返回参数指定为订单流
rpc searchOrders(StringValue) returns (stream Order);
}
  • 服务端实现
func (s *server) SearchOrders(searchQuery *pb.StringValue, stream pb.OrderManagement_SearchOrdersServer) error {
for key, order := range orderMap {
for _, item := range order.Items {
if strings.Contains(item, searchQuery.Value) {
err := stream.Send(&order)
if err != nil {
return fmt.Errorf("error sending message to stream: %v", err)
}
log.Printf("order found: " + key)
break
}
}
}
return nil
}
  • 客户端实现
...
// 获得建立的流对象
stream, err := c.SearchOrders(context.Background(), &pb.StringValue{Value: "XiaoMI"})
if err != nil {
log.Fatalf("search error: %v", err)
}
for {
// 循环读取
order, err := stream.Recv()
if err == io.EOF {
log.Print("EOF")
break
}
if err != nil {
log.Fatal("error: ", err)
}
log.Print(order)
}

3、客户端流RPC

客户端流,和服务端流一样的道理,只不过流的方向变为从客户端到服务端,可以发送多条响应,服务端只会响应一次,但何时响应取决于服务端的逻辑,以更新订单序列为例,客户端可以发送一系列订单,服务端可以选择在任意时候停止读取并发送响应:

  • 服务定义
service OrderManagement {
...
rpc updateOrders(stream Order) returns (StringValue);
}
  • 服务端实现
func (s *server) UpdateOrders(stream pb.OrderManagement_UpdateOrdersServer) error {
for {
order, err := stream.Recv()
if err == io.EOF {
return stream.SendAndClose(&pb.StringValue{Value: "finished"})
}
if err != nil {
return err
}
orderMap[order.Id] = order
log.Print("OrderID " + order.Id + " updated")
}
}
  • 客户端实现
// 取得流
updateStream, err := c.UpdateOrders(context.Background())
if err != nil {
log.Fatalf("update err: %v", err)
}
// 发送 Order1
if err = updateStream.Send(&pb.Order{
Id: "1",
Items: []string{"Huawei P50"},
Description: "Huawei P50",
Price: 5999,
Destination: "suzhou",
}); err != nil {
log.Fatalf("send error: %v", err)
}
// 发送 Order2
if err = updateStream.Send(&pb.Order{
Id: "2",
Items: []string{"iphone 12"},
Description: "iphone 12",
Price: 8999,
Destination: "suzhou",
}); err != nil {
log.Fatalf("send error: %v", err)
}
...
// 关闭流,结束发送
updateRes, err := updateStream.CloseAndRecv()
if err != nil {
log.Fatalf("update stream close error: %v", err)
}
log.Printf("update res: %v", updateRes)

4、双向流RPC

双向流,顾名思义,由客户端发起调用后,将建立起双向的流,在这之后,通信将完全基于双方的应用逻辑,流的操作完全独立,客户端和服务端可以按照任意顺序进行读取和写入,以一个订单筛选过程为例,客户端发送一串订单 ID 序列,服务端进行检查,每遇到一个有效的 ID 就写入流中响应:

  • 服务定义
service OrderManagement {
...
rpc processOrders(stream StringValue) returns (stream StringValue);
}
  • 服务端实现
func (s *server) ProcessOrders(stream pb.OrderManagement_ProcessOrdersServer) error {
for {
orderId, err := stream.Recv()
if err == io.EOF {
return nil
}
if err != nil {
return err
}
order, exists := orderMap[orderId.Value]
if exists && order != nil {
stream.Send(&pb.StringValue{Value: order.Id})
}
}
}
  • 客户端实现
...
// 取得双向流
processStream, err := c.ProcessOrders(context.Background())
// 同步channel,防止主程序提前退出
waitc := make(chan struct{})
// 双向流是完全异步的,开一个协程用于读取响应
go func() {
for {
orderId, err := processStream.Recv()
if err == io.EOF {
close(waitc)
return
}
if err != nil {
log.Fatalf("recv error: %v", err)
}
log.Print("recv " + orderId.Value)
}
}()
// 请求
if err = processStream.Send(&pb.StringValue{Value: "1"}); err != nil {
log.Fatalf("1 send error: %v", err)
}
if err = processStream.Send(&pb.StringValue{Value: "2"}); err != nil {
log.Fatalf("2 send error: %v", err)
}
if err = processStream.Send(&pb.StringValue{Value: "3"}); err != nil {
log.Fatalf("3 send error: %v", err)
}
if err = processStream.CloseSend(); err != nil {
log.Fatal(err)
}
// 等待读取结束
<-waitc

这就是 gRPC 中主要的四种通信模式,基于它们可以实现各种 gRPC 场景下的交互,至于选择哪种,还需根据具体的场景考虑

gRPC(2):四种基本通信模式的更多相关文章

  1. Activity有四种加载模式(转)

    Activity有四种加载模式: standard singleTop singleTask singleInstance 在多Activity开发中,有可能是自己应用之间的Activity跳转,或者 ...

  2. 活动 Activity 四种加载模式

    singleTop要求如果创建intent的时候栈顶已经有要创建的Activity的实例,则将intent发送给该实例,而不发送给新的实例.(注意是栈顶,不在栈顶照样创建新实例!) singleTas ...

  3. 【Android进阶】Activity的四种加载模式

    Activity的四种加载模式: 1.standard :系统的默认模式,一次跳转即会生成一个新的实例.假设有一个activity命名为Act1, 执行语句:startActivity(new Int ...

  4. android中的LaunchMode详解----四种加载模式

    Activity有四种加载模式: standard singleTop singleTask singleInstance 配置加载模式的位置在AndroidManifest.xml文件中activi ...

  5. 区分Activity的四种加载模式

    在多Activity开发中,有可能是自己应用之间的Activity跳转,或者夹带其他应用的可复用Activity.可能会希望跳转到原来某个Activity实例,而不是产生大量重复的Activity. ...

  6. activity的四种加载模式介绍

      四种加载模式的介绍: a) Standard : 系统默认模式,一次跳转即会生成一个新的实例:    b) SingleTop : 和 standard 类似,唯一的区别就是当跳转的对象是位于栈顶 ...

  7. Android学习记录(8)—Activity的四种加载模式及有关Activity横竖屏切换的问题

    Activity有四种加载模式:standard(默认), singleTop, singleTask和 singleInstance.以下逐一举例说明他们的区别: standard:Activity ...

  8. 区分Activity的四种加载模式【转载】

    此文为转载,文章来源:http://marshal.easymorse.com/archives/2950 文章作者:   Marshal's Blog 参考文章:http://blog.csdn.n ...

  9. 四种软件开发模式:tdd、bdd、atdd和ddd的概念

    看一些文章会看到TDD开发模式,搜索后发现有主流四种软件开发模式,这里对它们的概念做下笔记. TDD:测试驱动开发(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心 ...

随机推荐

  1. Spring Boot 2.5.0 发布:支持Java16、Gradle 7、Datasource初始化机制调整

    今年520的事情是真的多,娱乐圈的我们不管,就跟DD一起来看看 Spring Boot 2.5.0 的发布吧!看看都带来了哪些振奋人心的新特性和改动! 主要更新 支持 Java 16 支持 Gradl ...

  2. ES系列(五):获取单条数据get处理过程实现

    前面讲的都是些比较大的东西,即框架层面的东西.今天咱们来个轻松点的,只讲一个点:如题,get单条记录的es查询实现. 1. get语义说明 get是用于搜索单条es的数据,是根据主键id查询数据方式. ...

  3. 真正的原生JS数据双向绑定(实时同步)

    真正的原生JS数据双向绑定(实时同步) 接触过vue之后我感觉数据双向绑定实在是太好用了,然后就想着到底是什么原理,今天在简书上看到了一位老师的文章 js实现数据双向绑定 然后写出了我自己的代码 wi ...

  4. JAVA基础——运算符号

    运算符(java) 算数运算符:+,-,*,/,%(取余),++,-- 赋值运算符:= 关系运算符:<, >, >= ,<= ,== , != 逻辑运算符:&& ...

  5. [bug] PowerDesigner的association按钮灰色不能使用

    参考 https://blog.csdn.net/markely/article/details/44873301

  6. [bug] HDFS:DataXceiver error processing WRITE_BLOCK operation

    文件格式有误,导致读取错误,我的是把制表符敲成了空格

  7. 查看linux系统是多少位,使用 getconf LONG_BIT

    查看linux系统是多少位,使用 getconf LONG_BIT echo $HOSTTYPE

  8. Centos7 docker容器启动后添加端口映射

    docker容器启动后添加端口映射的两种方法: 一.通过修改防火墙策略添加端口映射 docker容器已创建好,但是想在容器内配置tomcat监控,需要新的端口去访问,但是映射时没有映射多余端口,此时, ...

  9. Ubuntu 16.04安装PyCharm

    PyCharm一个是Python集成开发环境,它既提供收费的专业版,也提供免费的社区版本.PyCharm带有一整套可以帮助用户在使用Python语言开发时提高其效率的工具,比如调试.语法高亮.Proj ...

  10. java面试一日一题:java中的垃圾回收器

    问题:请讲下java中垃圾回收器有哪些? 分析:该问题主要考察hotspot虚拟机下实现的垃圾回收器 回答要点: 主要从以下几点去考虑, 1.垃圾回收器的种类 2.每种垃圾回收器的着重点是什么 前边的 ...