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. 自定义元类 __call__,__init__,__new__总结

    只要对象能被调用 产生对象的类里必然有__call__方法 在调用类时,必定先触发type里的__call__ __call__下有: 1.产生对象的object.__new__ 2..被调用的类自己 ...

  2. (Dubbo架构)基于MDC+Filter的跨应用分布式日志追踪解决方案

    在单体应用中,日志追踪通常的解决方案是给日志添加 tranID(追踪ID),生成规则因系统而异,大致效果如下: 查询时只要使用 grep 命令进行追踪id筛选即可查到此次调用链中所有日志,但是在 du ...

  3. [java] Maven安装本地jar包

    命令 mvn install:install-file -Dfile="E:\software\Apache\repository\org\apache\flink\flink-connec ...

  4. Zabbix 自动发现并监控磁盘IO、报警 引言

    引言 Zabbix并没有提供模板来监控磁盘的IO性能,所以我们需要自己来创建一个,由于一台服务器中磁盘众多,如果只有一两台可以手动添加,但服务集群达到几十那就非常麻烦,因此需要利用自动发现这个功能,自 ...

  5. 001.Ansible简介与基本安装

    一 自动化运维 1.1 运维的自动化发展历程 IAAS:infratructure as a Service PAAS:platform as a Service 平台及服务 SAAS:softwar ...

  6. IT菜鸟之OSI七层模型

    OSI七层模型从下到上分别是: 应用层 表示层 会话层 传输层 网络层 数据链路层 物理层 第一层物理层: 物理层是传输媒介(网线.无线.光纤) 在线路中起到的作用:是将0/1转换成电信号或光信号 物 ...

  7. python基础之错误、调试(异常处理)

    在程序运行过程中,总会遇到各种各样的错误. 有的错误是程序编写有问题造成的,比如本来应该输出整数结果输出了字符串,这种错误我们通常称之为bug,bug是必须修复的. 有的错误是用户输入造成的,比如让用 ...

  8. Django 基本操作

    www.djangobook.comdjangobook.py3k.cn 1.django-admin.py startproject mysite2.manage.py startapp blog3 ...

  9. 入坑java工程师那些事

    最近在知乎上看到好多关于转行做java的朋友,有的在担心学历,有的在想着如何学习java,有的在纠结如何面试.作为一个工作了近10年的java程序员来聊聊我的一些想法,主要从学历.个人能力.工作环境等 ...

  10. Java常用集合笔记

    最近事情比较少,闲暇之余温习巩固一下Java的一些基础知识,并做一些笔记, Java常用集合, 主要参考的这篇文章:Java常用集合 ArrayList/Vertor 1. ArrayList 的主要 ...