我正在使用gRPC对一个调用进行分页，并试图弄清楚它的选项/近似值。这是一个明智的问题吗？我可以用什么资源来做这件事？
答案 0 :(得分：4)
这个问题很陈旧，但我觉得答案中缺少一些东西。
虽然流媒体是恕我直言的首选，但我的情况是＆＃34;传统＆＃34;分页非常有用。让我们设想一个user服务，它允许CRUD访问用户存储，并具有ListUsers和SearchUsers rpc。将结果分成页面会更方便。
我个人使用Googles方法：https://github.com/googleapis/googleapis/blob/master/google/cloud/resourcemanager/v2/folders.proto
答案 1 :(得分：2)
分页与分块二进制有效负载非常相似。我在gRPC + Image Upload中的回答可能值得一读。
也就是说，分页可能会有不同的权衡，因为它通常会降低吞吐量，有时候使用单独的请求并不困难。低吞吐量可以很快阻止流量控制，使其有用。使用单独的请求对于完全动态的结果（如搜索结果）来说更难，但对于更多静态数据（如资源的子项）可能不是一个大问题。
由于gRPC流控制可能会缓冲太多，因此另一个选择是使用流式传输但引入应用级流控制。使用应用程序级流控制，您可以使用流上的消息请求您需要多少响应，这不是很难使用或实现。有人一直在谈论在gRPC中支持精确的基于消息的流量控制（在这种情况下会产生类似的结果），但不清楚是否以及何时会发生这种情况。
答案 2 :(得分：1)
Google自己为此编写了一份出色的设计文档： https://cloud.google.com/apis/design/design_patterns#list_pagination
string方法的请求消息中定义page_token字段List。客户端使用此字段来请求列表结果的特定页面。int32方法的请求消息中定义page_size字段List。客户端使用此字段来指定服务器要返回的最大结果数。服务器可以进一步限制单个页面中返回的最大结果数。如果page_size为0，则服务器将决定要返回的结果数。string方法的响应消息中定义next_page_token字段List。此字段表示用于检索结果下一页的分页令牌。如果值为“”，则表示该请求没有其他结果。关于使用FieldMask进行部分响应的部分也值得一读，因为这是一种常见的api设计模式