load-balancing - 如何解决这个节点与 Envoy 的亲和性

Question

我提供了一个 gRPC 服务，不幸的是必须在 BeginTransaction 之间具有节点亲和性。和 Commit API 调用。

Consumer API 调用顺序通常是:

1. BeginTransaction()返回 txnID
2. DoStuff(txnID, moreParams...)
3. DoStuff(txnID, moreParams...)
4. ...
5. Commit(txnID)

消费者可以是同时调用我的 API 的多线程进程，因此他们可能在任何时间点使用数百个事务。

如果我使用 Envoy 代理作为我的服务入口点，BeginTransaction应该路由到集群中任何健康的节点，但它必须确保使用返回的 txnID 的后续调用被路由到同一个节点。

在我的情况下，在 http header 或消息的任何部分中传递任何上下文信息都是可以接受的。

Answer 1

我在使用 Ring Hash 平衡器方面取得了一些进展

在 envoy 代理服务器中(查找“hash”):

static_resources:
  listeners:
  - address:
      socket_address:
        address: 0.0.0.0
        port_value: 80
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          codec_type: http2
          stat_prefix: ingress_http #just for statistics
          route_config:
            name: local_route
            virtual_hosts:
            - name: samplefront_virtualhost
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/mycompany.sample.v1"
                  grpc: {}
                route:
                  cluster: sampleserver
                  hash_policy:
                    header:
                      header_name: "x-session-hash"
              - match:
                  prefix: "/bbva.sample.admin"
                  grpc: {}
                route:
                  cluster: sampleadmin
          http_filters:
          - name: envoy.router
            config: {}
  clusters:
  - name: sampleserver
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: ring_hash
    http2_protocol_options: {}
    hosts:
    - socket_address:
        address: sampleserver
        port_value: 80 #Connect to the Sidecard Envoy
  - name: sampleadmin
    connect_timeout: 0.25s
    type: strict_dns
    lb_policy: round_robin
    http2_protocol_options: {}
    hosts:
    - socket_address:
        address: sampleadmin
        port_value: 80 #Connect to the Sidecard Envoy
admin:
  access_log_path: "/dev/null"
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 8001

在我的消费者中，我在 BeginTransaction() 之前创建了一个随机散列，我确保它每次都在 x-session-hash header 中发送，直到提交(txnId)

它可以工作，但有一些限制:

当我扩展服务、添加更多节点时，一些操作失败并出现错误 upstream connect error or disconnect/reset before headers。当一个节点丢失时，失败是绝对可以的，但是当添加一个节点时，它们几乎是 Not Acceptable !好消息是负载在这两种情况下都得到了重新平衡。

客户端必须在第一次调用 (BeginTransaction) 之前生成哈希，无意中指示哪个节点将参与此交易请求的客户端也是如此。

我会继续调查。