Предоставление сложного состояния фоновому заданию Hangfire

#c# #hangfire

#c# #hangfire

Вопрос:

Я пишу ASP.NET Базовый REST API, который возвращает 201s и 202s после запуска длительных асинхронных заданий с использованием Hangfire. Если задания завершаются неудачей на полпути, Hangfire восстановит данные, выполнит повторные попытки и т. Д. Очевидно, что для этого ему необходимо знать некоторое состояние.

Hangfire рекомендует, чтобы аргументы фоновых заданий оставались «маленькими и простыми«, и если фоновому заданию требуется какой-то более сложный объект для записи идентификатора в базу данных.

Для моих фоновых заданий требуется несколько ключей API, пароли, некоторые не так просто сериализовать объекты и некоторые файлы YAML, загруженные как config через внутреннюю общую библиотеку конфигурации. Из-за чувствительности этих данных я бы предпочел не записывать их в базу данных. Здесь я вижу два варианта:

  1. Передайте каждый фрагмент более крупных объектов в качестве аргументов заданию Hangfire и позвольте Hangfire сериализовать их в свою базу данных. Для конфиденциальных аргументов, таких как ключи API и пароли, сначала зашифруйте их, используя некоторый сертификат, поставляемый в комплекте с приложением. Фоновое задание должно будет расшифровать их, используя тот же сертификат, после извлечения их из базы данных при запуске.
  2. Задайте объектам какое public static -либо свойство в public static классе при запуске. Фоновое задание может просто ссылаться на это, когда это необходимо. Например:
 // Startup code simplified for the sake of the example
{
    var envConfigs = new EnvironmentConfiguration( ... a bunch of random stuff ... );
    service.AddSingleton(envConfigs);
    EnvironmentConfiguration.Instance = envConfigs;
}


// Hangfire job

{    
    var result = BusinessLogicDoerMethod(EnvironmentConfiguration.Instance.BusinessLogicInformation);
}
  

Вариант 1 раздражает, потому что нам приходится передавать много аргументов, а также иметь дело с логикой шифрования / дешифрования.

Вариант 2, вероятно, подходит, опасность, которую я вижу здесь, заключается в том, что если одно фоновое задание изменит EnvironmentConfiguration объект, другие задания и остальная часть приложения также увидят эту мутацию. Однако я могу легко решить эту проблему, просто не делая этого.

Ответ №1:

Не было ни одного варианта.. просто использовал DI согласно https://docs .hangfire.io/en/latest/background-methods/passing-dependencies.html