在 gRPC 中返回多个项目：重复列表或流单个对象？

Question

gRPC 新手。我有一个简单的 api：

Customer getCustomer(int id)
List<Customer> getCustomers()

所以我的原型看起来像这样：

message ListCustomersResponse {
  repeated Customer customer = 1;
}

rpc ListCustomers (google.protobuf.Empty) returns (ListCustomersResponse);
rpc GetCustomer (GetCustomerRequest) returns (Customer);

我试图追随 Google 在风格上的领先。最初我有 returns (stream Customer) 用于 GetCustomers，但 Google 似乎更喜欢 ListxxxResponse 样式。当我生成代码时，它最终是：

public void getCustomers(com.google.protobuf.Empty request,
        StreamObserver<ListCustomersResponse> responseObserver) {

对比：

public void getCustomers(com.google.protobuf.Empty request,
        StreamObserver<Customer> responseObserver) {

我错过了什么吗？当我可以流式传输 Customer 并获得流式传输功能时，为什么还要麻烦创建 ListCustomersResponse？

ListCustomersResponse 只是一次流式传输整个列表，而不是流式传输每个客户。 Google 的偏好似乎是一直返回 ListCustomersResponse 样式。

什么时候使用 ListxxxResponse 与流响应比较合适？

Answer 1

如果不知道您使用的是什么参考资料，这个问题很难回答。可能存在沟通不畅，或者引用完全错误。

如果您正在查看gRPC Basics tutorial，那么我可能对导致误传的原因有所了解。 如果确实是您的参考，那么它确实不建议返回 repeated 字段以获取流式响应；您的直觉是正确的：您只想流式传输单个客户。

它是这样说的（故意截屏）：

您可能将 rpc ListFeatures(Rectangle) 理解为 返回特征列表 [名词] 的端点。如果是这样，那就是沟通不畅。该指南实际上意味着一个端点列出 [动词] 功能。如果他们只写 rpc GetFeatures(Rectangle)，就不会那么混乱了。

所以，你的原型应该看起来更像这样，

rpc GetCustomers (google.protobuf.Empty) returns (stream Customer);
rpc GetCustomer (GetCustomerRequest) returns (Customer);

准确地生成您怀疑的内容更有意义。

---

更新

啊，我明白了，所以您正在 googleapis 中查看此示例：

  // Lists shelves. The order is unspecified but deterministic. Newly created
  // shelves will not necessarily be added to the end of this list.
  rpc ListShelves(ListShelvesRequest) returns (ListShelvesResponse) {
    option (google.api.http) = {
      get: "/v1/shelves"
    };
  }

...

// Response message for LibraryService.ListShelves.
message ListShelvesResponse {
  // The list of shelves.
  repeated Shelf shelves = 1;

  // A token to retrieve next page of results.
  // Pass this value in the
  // [ListShelvesRequest.page_token][google.example.library.v1.ListShelvesRequest.page_token]
  // field in the subsequent call to `ListShelves` method to retrieve the next
  // page of results.
  string next_page_token = 2;
}

是的，我想您现在可能已经想到了相同的想法，但这里他们选择使用简单的 RPC，而不是服务器端流式 RPC（请参阅 here） .我强调这一点是因为，我认为重要的选择不是 repeated 与 stream 之间的风格差异，而是 简单的请求-响应 API 之间的差异 strong> 与更复杂且不那么普遍的流式 API。

在上面的 googleapis 示例中，他们定义了一个 API，该 API 返回每个页面的固定和静态数量的项目，例如 10 或 50。这只是过于复杂 使用流式传输，因为分页在软件架构和 REST API 中已经得到了很好的理解和流行。我认为这是他们应该说的，而不是“少数”。因此，流式传输的复杂性（以及您和未来维护者的学习成本）必须证明是合理的，仅此而已。假设您实际上正在为 Point Cloud 获取数千个 (x, y, z) 项目，或者您正在为某些加密货币创建实时更新的买卖可视化工具，例如

然后你会开始问自己，“简单的请求-响应 API 是我最好的选择吗？” 所以往往需要返回的项目数量越多，越多的流式 API 开始变得有意义。这可能是出于概念上的原因，例如这些项目是 time 中的实时更新流，就像上面的加密示例或架构，例如开始在 UI 中将结果作为部分数据流返回会更高效。我认为您阅读的“少量”内容过于简单化了。