【问题标题】:GRPC Client Side Load Balancing: How to measure response time per target address?GRPC 客户端负载平衡:如何测量每个目标地址的响应时间?
【发布时间】:2021-12-01 10:09:39
【问题描述】:

我正在为 GRPC 实施自定义负载平衡器,以在我的应用中启用客户端负载平衡。由于业务需求,我需要在负载平衡算法中使用基于响应时间的指标。

问题在于 GRPC Picker 接口(用于在负载均衡器中选择子通道)没有在请求处理后调用的任何回调。所以我无法测量 Picker 内部的执行时间。为了绕过这一点,我尝试使用客户端拦截器来测量 RPC 的确切时间,但似乎拦截器没有任何关于作为负载平衡结果选择的服务器地址的信息。

是否有任何其他机制可以将负载平衡与测量 GRPC 中的 RPC 响应时间相结合?

【问题讨论】:

    标签: load-balancing grpc grpc-python


    【解决方案1】:

    需要注意的一点是,C-core 内部的 LB 策略接口目前不是公共 API。它不是一个稳定的 API,很可能会随着版本的变化而变化,因此如果您实施自己的 LB 策略,则很可能需要进行更改以在升级 gRPC 时使其正常工作。我们希望最终提供一个公共的、稳定的 LB 策略 API,但在我们完成 EventEngine 工作之前我们不能这样做,因为当前(可怕的)轮询 API 直接暴露于 LB 策略。即使发生这种情况,我们也可能决定在稳定当前 API 之前对其进行一些结构更改。

    除此之外,请注意,在我们当前的实现中,LB 策略实际上可以在调用完成时获得回调。他们可以通过让选择器返回一个recv_trailing_metadata_ready 回调来做到这一点。调用完成时,通道将调用该回调。请注意,通道不为此回调提供任何同步;它不会在 WorkSerializer(用于所有 LB 策略控制平面操作)和数据平面互斥体(在调用选择器时保持)中调用,因此 LB 策略实现必须在回调中进行自己的同步。此外,当丢弃选择结果时,目前可能存在一些边缘案例,其中丢弃了回调,但这是我们需要在某个点修复的东西,因此如果您遇到它,请提交问题它。

    希望这些信息对您有所帮助!

    【讨论】:

      猜你喜欢
      • 2018-01-31
      • 2022-01-17
      • 1970-01-01
      • 1970-01-01
      • 2020-01-03
      • 2019-06-18
      • 1970-01-01
      相关资源
      最近更新 更多