При использовании пошаговых функций с лямбда-микросервисами в некоторых случаях может потребоваться выполнение определенных версий лямбда-выражений. Короче говоря, лямбда-микросервисы с полиморфным поведением.

Такого рода требования могут быть распространены в машинном обучении. В этом я не совсем уверен, так как я все еще новичок в ML. Однако эта проблема интересна, так как в противном случае вам потребуется запускать разные экземпляры одних и тех же лямбда-выражений в вашей среде для обслуживания разных источников. Мы столкнулись с таким требованием, когда источник диктует, какие алгоритмы запускать в потоке.

Алгоритмы в основном похожи с несколькими настройками, поэтому в зависимости от каждого источника выполняемая функция выбирается на основе контекста или источника.

Вот несколько шагов, которые вы можете легко выполнить, чтобы решить эту проблему: –

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

Создать версию для каждой лямбды

VERSION=$(aws lambda list-versions-by-function \     
    --function-name microservice_1 \     
    --no-paginate \     
    --query "max_by(Versions, &to_number(to_number(Version) \
      || '0'))" | jq -r '.Version')

Создать псевдоним

aws lambda create-alias \     
    --function-name microservice_1 \     
    --name v1 \     
    --function-version $VERSION \     
    --description " "

Сопоставление источника с версией

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

source 1   ->   {
                    microservice 1 -> v1
                    microservice 2 -> v6
                    microservice 3 -> v4
                }
source 2   ->   {
                    microservice 1 -> v2
                    microservice 2 -> v5
                    microservice 3 -> v7
                }

Создайте карту версий как часть полезной нагрузки

Например, если у вас есть набор версий для выполнения, как показано ниже, для данного источника 1.

{
    "microservice_1" : "v1",
    "microservice_2" : "v6",
    "microservice_3" : "v4"
}

Просто упакуйте это как часть полезной нагрузки

{
......
  "release_versions" : {
    "microservice_1" : "v1",
    "microservice_2" : "v6",
    "microservice_3" : "v4"
  }
}

Настройте свое состояние в пошаговых функциях

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

{
  ....
  "States": {
    ....
    "microservice 1": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "microservice_1",
        "Qualifier.$": "$.release_versions.microservice_1"
      },
      "Next": "microservice 2"
    },
    "microservice 2": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "microservice_2",
        "Qualifier.$": "$.Payload.release_versions.microservice_2"
      },
      "Next": "microservice 3"
    },
    "microservice 3": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Parameters": {
        "FunctionName": "microservice_3",
        "Qualifier.$": "$.Payload.release_versions.microservice_3"
      },
      "End": true
    }
  }
}

Вот и все! Правильные версии лямбды будут выполняться.

Обратите внимание на .Payload во втором и третьем состояниях. Это связано с тем, что когда вы выполняете лямбду с псевдонимом, она завершает вывод метаданными. Метаданные содержат информацию о выполнении, например, какая версия использовалась для выполнения лямбды и многое другое. Таким образом, последующим лямбда-выражениям требуется дополнительная .Payload для доступа к фактической полезной нагрузке, возвращенной на предыдущем шаге.