服务网格支持gRPC协议服务开发、容器化和网格化。本文介绍gRPC协议在ASM实践的设计原理。

通信模型

设计宗旨

  • 覆盖gRPC的4种通信模型。
  • 方法名和参数名不引入任何业务因素,避免额外思考,专注技术本身。

4种通信模型和实践方法的对应关系

通信模型 实践方法
Unary RPC talk
Server streaming RPC talkOneAnswerMore
Client streaming RPC talkMoreAnswerOne
Bidirectional streaming RPC talkBidirectional

Protobuf定义

service LandingService {
  //Unary RPC
  rpc talk (TalkRequest) returns (TalkResponse) {
  }
  //Server streaming RPC
  rpc talkOneAnswerMore (TalkRequest) returns (stream TalkResponse) {
  }
  //Client streaming RPC with random & sleep
  rpc talkMoreAnswerOne (stream TalkRequest) returns (TalkResponse) {
  }
  //Bidirectional streaming RPC
  rpc talkBidirectional (stream TalkRequest) returns (stream TalkResponse) {
  }

方法设计

  • 简单的主线逻辑:服务端将请求参数中的data字段的值作为hello数组的下标,并将相应的值返回给客户端。
  • 简化请求和响应形式,避免使用多个类型来区分单复数。
    • 请求统一使用字符串,复数形式使用逗号分开。
    • 响应统一使用数组,单数时数组只包含一条结果。
  • 客户端和服务端都传递编程语言信息,以lang值显式展示流量管理的配置效果。
协议

协议设计

设计宗旨

  • 请求参数足够简单,以方便调试,但要包含足够的信息。
  • 响应参数的数据类型要尽可能覆盖全面,以实现演示的目的。

请求协议

只使用字符串类型,包含请求Hello数组的下标值和编程语言信息。

message TalkRequest {
  //language index
  string data = 1;
  //clientside language
  string meta = 2;
}

响应协议

  • 响应只包含两个字段,整数类型的状态码和TalkResult类型的数组。
  • TalkResult类型内部,分别定义了长整型、枚举类型、键值类型(k/v的泛型为字符串)。
message TalkResponse {
  int32 status = 1;
  repeated TalkResult results = 2;
}

message TalkResult {
  //timestamp
  int64 id = 1;
  //enum
  ResultType type = 2;
  // result uuid
  // language index
  // data hello
  // meta serverside language (It's not good here, 
  //      but ok since I feel like to keep the response)
  map<string, string> kv = 3;
}

enum ResultType {
  OK = 0;
  FAIL = 1;
}

功能函数

功能函数 说明
环境变量 需要为gRPC的客户端提供一个变量GRC_SERVER,在本地开发调试时其值为Localhost,在Pod启动时动态定义为gRPC Service的值,以便客户端调用。
随机数 在Client streaming和Bidirectional streaming两种通信方式下,客户端需要随机产生一个整型数值,取值要求在Hello数组下标的范围内。
时间戳 TalkResult.id是int64类型的唯一标识,通过时间戳来实现。
UUID TalkResult.kv[id]是字符串类型的唯一标识,通过UUID来实现。
Sleep 在Streaming方式下,为了更好地观察,通过Sleep方式设置两次请求的间隔。