Освещение понятий Spring Dataflow

Question

Я начал использовать Spring Dataflow, и я нахожусь с некоторыми вопросами, на которые я не могу ответить, прочитав документацию и проведу некоторые тесты. Любое пояснение будет приветствоваться (если вы не можете ответить на все сразу, ответить на те, которые вы можете, я консолидировать полный ответ, если это необходимо)

1. Spring Dataflow предназначен для записи аппликативными рабочих процессов, например: выход app A является входом app B и т. д. Рабочие процессы не обязательно должны быть линейными, так как вывод app A может быть входом как app B, так и app C. Насколько это точно?

2. Хорошо написано, что приложения в поточном конвейере обмениваются сообщениями «с сообщением». App A отправляет сообщение брокеру (например, RabbitMQ или Kafka, например), а app B потребляет сообщение от него. Мы можем иметь несколько разных брокеров в нашем потоке. Но является ли обмен сообщениями единственным способом отправки информации между приложениями? Возможно ли, что app A звонит app B через HTTP-запрос REST, например? И если да, то как?

3. Поскольку приложения полагаются на асинхронный обмен сообщениями (см. Выше вопрос), какова добавленная стоимость Dataflow? Я имею в виду, что если вы настроите app A для отправки сообщений на тему foo и app B, чтобы использовать сообщения из той же темы, вы можете развернуть их как отдельно (без потока данных), так и работать. Насколько я понимаю, Dataflow предоставляет только способ развертывания и развертывания их сразу, а не один за другим. Правильно ли это?

4. Как и в предыдущем вопросе, асинхронный обмен сообщениями абстрагирует вас от определения порядка потока (то есть вы можете начать app B перед app A). Вся система будет работать только тогда, когда оба приложения работают, но они даже не должны знать друг друга. Единственное, что нужно, это то, что они используют одного и того же брокера и тему, одну для отправки сообщения, а другую - для получения. Итак, почему вам абсолютно необходимо связать вывод одного приложения с другим, в Spring Cloud Dataflow? Это способ заставить обе приложения использовать одну и ту же тему, но так ли это все?

Answer 1

Spring Dataflow предназначен написать аппликативные рабочих процессы

Spring Cloud Data Flow (SCDF) является сервис оркестровки, что позволяет создавать microservice приложения в целостный трубопровод. Принимаемые заявки (сегодня) основаны на модели программирования Spring Cloud Stream (SCSt) или Spring Cloud Task (SCT), поэтому вы можете организовать потоковые и задачи/пакетные конвейеры соответственно. В зависимости от требований вы можете использовать линейные или сложные рабочие процессы типа DAG.

Но является ли сообщение единственным способом отправки информации между приложениями?

Прямо сейчас, да. Текущая абстракция связующего, предоставляемая SCSt, поддерживает каналы обмена сообщениями, и мы находимся в процессе обобщения модели привязки.Следующее поколение развивается и добавляет поддержку для KStream в качестве входов/выходов, а также Reactor Flux в качестве входов/выходов. У нас пока нет поддержки механизма привязки RESTful.

Поскольку приложения полагаются на асинхронные сообщения (см. Выше вопрос), что такое добавленное значение Dataflow?

Вы можете организовать индивидуальные приложения SCSt/SCT. Отдельные приложения включают такие свойства, как «информация о соединении связующего», «адресация привязки каналов» и многие другие - вы должны их предоставить. Как только у вас появятся такие требования, как разбиение на разделы и масштабирование, вам придется еще больше хранить эти свойства приложений. Здесь уровень оркестровки SCDF добавляет ценность. Помимо DSL, REST-APIs, Dashboard/Flo, которые вы можете использовать для более быстрого создания потоковых/пакетных конвейеров, SCDF также автоматизирует создание этих известных свойств для подключения приложений с четко определенными соглашениями об именах.

Dataflow предоставляет только способ развертывания и развертывания их сразу, а не один за другим. Это верно ?

При развертывании потока с набором приложений SCDF развертывает их в порядке. Вы можете развернуть, уничтожить и запросить агрегированный статус потока из приложений. И для задач вы можете запускать, уничтожать и запрашивать статус выполнения и т. Д.

Почему вам абсолютно необходимо связать вывод одного приложения с другим вводом данных в Spring Cloud Dataflow?

Это неясно. Для обработки потоков вам понадобится минимум 2 приложения (источник и приемник) в контексте SCDF. Однако вы можете построить aggregate application с использованием SCSt и организовать агрегацию (источник, процессор (s) и раковину) как единое целое.

Answer 2

Следует отметить, что новая модель исполнения SCDF и общая архитектура ограничены для некоторых случаев использования, в которых большинство из нас принадлежит (по крайней мере, в среде TELCO, в которой мы работаем). Другими словами, SCDF, работающий над двигателем контейнера, находится в ближайшем будущем - где-то. У нас работает SpringXD на производстве, и он работает как шарм с Zookeeper (распространяется). Теперь, с концепцией SCDF, я должен думать о чем-то другом, несмотря на то, что мне удалось установить и запустить SCDF на кластере Kubernetes (в моей лаборатории).