Каков хороший вариант использования дочернего рабочего процесса в Uber Cadence?
Я пытаюсь понять варианты использования дочернего рабочего процесса с Uber Cadence. В чем преимущество дочернего рабочего процесса по сравнению с простым разделением рабочего процесса на функции? У меня есть довольно сложный рабочий процесс, который я рассматриваю для разделения на несколько дочерних рабочих процессов, но я не уверен в плюсах и минусах этого.
Ответы 1
- Дочерний рабочий процесс может размещаться в отдельном наборе рабочих процессов, не содержащих код родительского рабочего процесса. Таким образом, он будет действовать как отдельная служба, которую можно вызывать из нескольких других рабочих процессов.
- Один рабочий процесс имеет ограниченный размер. Например, он не может выполнять 100 тыс. действий. Дочерние рабочие процессы можно использовать для разделения проблемы на более мелкие фрагменты. Один родитель с 1000 детей, каждый из которых выполняет 1000 действий, дает 1 миллион выполненных действий.
- Дочерний рабочий процесс можно использовать для управления некоторым ресурсом, используя его идентификатор, чтобы гарантировать уникальность. Например, рабочий процесс, управляющий обновлениями узла, может иметь дочерний рабочий процесс для каждого узла (имя узла является идентификатором рабочего процесса) и использовать их для обеспечения сериализации всех операций на узле.
- Дочерний рабочий процесс можно использовать для выполнения некоторой периодической логики, не увеличивая размер родительской истории. Родитель запускает дочерний процесс, который выполняет периодические логические вызовы continue as new столько раз, сколько необходимо, а затем завершает работу. С родительской точки зрения это всего лишь один вызов дочернего рабочего процесса.
Основным ограничением дочернего рабочего процесса по сравнению с размещением всей логики приложения в одном рабочем процессе является отсутствие общего состояния. Родитель и ребенок могут общаться только через асинхронные сигналы. Но если между ними существует тесная связь, может быть проще использовать единый рабочий процесс и просто полагаться на общее состояние объекта.
Я лично рекомендую начинать с реализации одного рабочего процесса, если ваша проблема имеет ограниченный размер с точки зрения количества выполненных действий и обработанных сигналов. Это просто проще, чем несколько асинхронно взаимодействующих рабочих процессов.
Также часто наблюдают, что рабочие процессы — это не просто функции, в них можно использовать всю мощь объектно-ориентированного программирования. Используйте структуры, интерфейсы и другие методы объектно-ориентированного программирования, чтобы разбить логику на более управляемые абстракции.