Как решить эту привязку узла с посланником - PullRequest
Новая
       47

Как решить эту привязку узла с посланником

0 голосов
/ 01 октября 2018

Я предоставляю услугу gRPC, которая, к сожалению, должна иметь сходство узлов между BeginTransaction и Commit Вызовами API.

Последовательность вызовов API потребителя обычно:

  1. BeginTransaction() возврат txnID
  2. DoStuff(txnID, moreParams...)
  3. DoStuff(txnID, moreParams...)
  4. ...
  5. Commit(txnID)

Потребители могут быть многопоточными процессами, которые выполняют одновременные вызовы моего API, поэтому они могут использовать сотни транзакций в любой момент времени.

Если я использую прокси Envoy в качестве точки входа моей службы, BeginTransaction должно бытьмаршрутизируется на любой исправный узел в кластере, но он должен гарантировать, что последующие вызовы, использующие возвращенный txnID, будут направлены на тот же узел.

Передача любой контекстной информации в заголовки http или в любую частьсообщения, это приемлемо в моем случае.

1 Ответ

0 голосов
/ 08 октября 2018

Я добился определенного прогресса, используя балансировщик Ring Hash

На прокси-сервере-посреднике (ищите "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 каждый раз, пока Commit(txnId)

Это работает, но имеет некоторые ограничения:

Когда я масштабирую службу,При добавлении большего количества узлов некоторые операции завершаются с ошибкой upstream connect error or disconnect/reset before headers.Сбои абсолютно нормальны, когда один узел потерян, но они вряд ли приемлемы, когда добавляется узел !!!Хорошая новость заключается в том, что в обоих случаях нагрузка перебалансируется.

Клиент должен сгенерировать хэш до того, как будет сделан первый вызов (BeginTransaction), так же как и клиент, который непреднамеренно диктует, какой узел будет обслуживать запросы.для этой транзакции.

Я буду продолжать расследование.

...