Масштабирование приложений Dapr с помощью масштабировщиков KEDA

Приложения контейнеров Azure автоматически масштабирует HTTP-трафик до нуля. Однако для масштабирования трафика, отличного от HTTP (например, dapr pub/sub и привязок), можно использовать масштабировщики KEDA для масштабирования приложения и его боковой карды Dapr вверх и вниз на основе количества ожидающих событий и сообщений.

В этом руководстве показано, как настроить правила масштабирования приложения Dapr pub/sub с масштабировщиком обмена сообщениями KEDA. Для контекста см. соответствующие примеры пабов и вложенных приложений:

• Обмен данными микрослужб с помощью pub/sub в C#
• Обмен данными микрослужб с помощью pub/sub в JavaScript
• Обмен данными микрослужб с помощью pub/sub в Python

В приведенных выше примерах приложение использует следующие элементы:

1. Издатель checkout — это приложение, которое предназначено для неограниченного выполнения и никогда не уменьшайте масштаб до нуля, несмотря на то, что никогда не получает входящий HTTP-трафик.
2. Компонент dapr Служебная шина Azure pub/sub.
3. order-processor Приложение-контейнер подписчика получает сообщения, полученные через orders раздел, и обрабатывается по мере их поступления.
4. Правило масштабирования для Служебная шина Azure, которое отвечает за масштабирование order-processor службы и его боковой кареты Dapr, когда сообщения начинают поступать в orders раздел.

Давайте рассмотрим, как применить правила масштабирования в приложении Dapr.

Приложение контейнера издателя

Издатель checkout — это бессерверная служба, которая выполняется неограниченно и никогда не масштабируется до нуля.

По умолчанию среда выполнения контейнерных приложений назначает приложению правило масштабирования на основе HTTP, которое выполняет масштабирование на основе количества входящих HTTP-запросов. В следующем примере minReplicas задано значение 1. Эта конфигурация гарантирует, что приложение-контейнер не соответствует по умолчанию масштабированию до нуля без входящего HTTP-трафика.

resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
  name: 'ca-checkout-${resourceToken}'
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    //...
    template: {
      //...
      // Scale the minReplicas to 1
      scale: {
        minReplicas: 1
        maxReplicas: 1
      }
    }
  }
}

Приложение контейнера подписчика

Следующее order-processor приложение подписчика включает пользовательское правило масштабирования, которое отслеживает ресурс типа azure-servicebus. В этом правиле приложение (и его боковинка) масштабируется вверх и вниз по мере необходимости на основе количества ожидающих сообщений в шине.

resource orders 'Microsoft.App/containerApps@2022-03-01' = {
  name: 'ca-orders-${resourceToken}'
  location: location
  tags: union(tags, {
      'azd-service-name': 'orders'
    })
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    managedEnvironmentId: containerAppsEnvironment.id
    configuration: {
      //...
      // Enable Dapr on the container app
      dapr: {
        enabled: true
        appId: 'orders'
        appProtocol: 'http'
        appPort: 5001
      }
      //...
    }
    template: {
      //...
      // Set the scale property on the order-processor resource
      scale: {
        minReplicas: 0
        maxReplicas: 10
        rules: [
          {
            name: 'topic-based-scaling'
            custom: {
              type: 'azure-servicebus'
              identity: 'system'
              metadata: {
                topicName: 'orders'
                subscriptionName: 'membership-orders'
                messageCount: '30'
              }
            }
          }
        ]
      }
    }
  }
}

Как работает масштабировщик

Обратите внимание, что messageCount свойство в конфигурации масштабировщика в приложении подписчика:

{
  //...
  properties: {
    //...
    template: {
      //...
      scale: {
        //...
        rules: [
          //...
          custom: {
            //...
            metadata: {
              //...
              messageCount: '30'
            }
          }
        ]
      }
    }
  }
}

Это свойство сообщает масштабировщику, сколько сообщений каждый экземпляр приложения может обрабатывать одновременно. В этом примере задано 30значение, указывающее, что для каждой группы сообщений, ожидающих в этом разделе, должно быть один экземпляр приложения.

Например, если ожидается 150 сообщений, KEDA масштабирует приложение до пяти экземпляров. Свойство maxReplicas имеет значение 10. Даже при большом количестве сообщений в разделе масштабировщик никогда не создает больше 10 экземпляров этого приложения. Этот параметр гарантирует, что вы не масштабируете слишком много и начисляете слишком много затрат.

Следующие шаги

Дополнительные сведения об использовании компонентов Dapr с приложениями контейнеров Azure.