1 通信模型

设计宗旨

• 覆盖gRPC的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}值显式展示流量管理的配置效果。

2 协议设计

设计宗旨

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

请求协议

只使用字符串类型，包含请求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;
}

3 实现要点

环境变量

我们需要为GRPC的client提供一个变量GRC_SERVER，在本地开发调试时其值为localhost，在POD启动时动态定义为GRPC Service的值，以便client调用。

随机数

在Client streaming和Bidirectional streaming两种通信方式下，客户端需要随机产生一个整型数值，取值要求在hello数组下标的范围内。

时间戳

TalkResult.id是int64类型的唯一标识，通过时间戳来实现。

UUID

TalkResult.kv[id]是字符串类型的唯一标识，我们通过UUID来实现。

sleep

在streaming方式下，为了更好地观察，通过sleep方式设置两次请求的间隔。