У меня есть архитектура, где у нас есть около 6-10 (микро) сервисов без состояний, которые предоставляют конечную точку API «POST / run_job arg1 arg2 arg3 ...», используют свой собственный механизм порождения заданий (python-rq), используя redis как шаблон очереди и мастера. Задания занимают от нескольких минут до нескольких часов, чаще всего для обработки некоторых данных и / или выполнения некоторого преобразования данных. Некоторые задания зависят от других, и необходимо запустить, например, job2 после job1 закончен (уничтожение артефактов). Таким образом, очевидно, что есть некоторый поток, иногда обусловленный одобрением руководства пользователя. В настоящее время пользователи вынуждены в основном вручную управлять потоком или триггерами job1 job2, когда он завершает работу (без какой-либо всеобъемлющей службы над управлением этим). Большинство услуг без гражданства.
Поскольку вся система эксплуатируется не инженерами, к ней предъявляются требования прозрачности («Хорошо ли обрабатывается мой поток? Сбой? Почему? В каком состоянии это сейчас?»)
Вся архитектура находится прямо сейчас в Kubernetes в GCP с четко определенными приложениями (12-факторными приложениями) с хорошим мониторингом и ведением журнала. Все находится под CI / CD. Pubsub иногда используется, но не для управления потоком, просто для отправки данных там, где HTTP не подходит.
Очевидно, что это не тот путь, и, поскольку я хочу, чтобы система масштабировалась до еще большего числа шагов, это неустойчиво.
Поэтому я думаю о том, как решить эту проблему. Есть AFAIK эти подходы: оркестровка и хореография . Также есть сочетание обоих: глобальная хореография и локальная оркестровка ( 1 ), но я не понимаю, как это будет использоваться в моем сценарии использования.
Теоретически, хореография - это крутой способ, как это сделать, но довольно сложно представить, как все это будет работать без какого-либо состояния (в основном это часть обратной связи с пользователем).
Оркестровка очень похожа на то, что я хочу - например, используя Argo , мы должны в основном избавиться от этих микросервисов и просто использовать их часть «задание» (без собственного порождения задания или API) как часть четко определенных потоков, в которых есть весь поток (job1) , job2, ожидание подтверждения пользователя, job3, ...), состояние и т. д. С другой стороны, это единственная опасная точка отказа и связи внутри потока («сервисы» - теперь задания - все еще будут разрабатываться и выпускаться самостоятельно до тех пор, пока они соответствуют интерфейсу - CLI).
Есть ли какой-нибудь процесс, которым я мог бы следовать, чтобы выбрать между этими двумя? Я читаю, например ::1010*
1) https://www.simpleorientedarchitecture.com/modelling-long-running-processes-choreography-versus-orchestration/
2) https://www.ben-morris.com/events-sagas-and-workflows-managing-long-running-processes-between-services/
3) https://blog.bernd-ruecker.com/why-service-collaboration-needs-choreography-and-orchestration-239c4f9700fa
4) https://netflix.github.io/conductor/
но я не могу получить достаточно высокую уверенность ни в одном из решений.