При использовании пошаговых функций с лямбда-микросервисами в некоторых случаях может потребоваться выполнение определенных версий лямбда-выражений. Короче говоря, лямбда-микросервисы с полиморфным поведением.
Такого рода требования могут быть распространены в машинном обучении. В этом я не совсем уверен, так как я все еще новичок в 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 для доступа к фактической полезной нагрузке, возвращенной на предыдущем шаге.