服务网格 ASM：gRPC协议实践的设计原理

通信模型

设计宗旨

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

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

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;
}

功能函数