Существует ли другая модель времени выполнения, кроме одного экземпляра jvm на модуль в Spring Cloud Data Flow?
В настоящее время мы используем Spring XD для приема данных с множеством потоков (и модулей). К сожалению, Spring XD больше не выпускается, и мы должны искать альтернативу.
Итак, мы взглянули на Spring Cloud Data Flow, потому что хотим динамическое развертывание потоков через оболочку.
К сожалению, простой поток "http | log" потребовалось 1,6 ГБ оперативной памяти. Затем я запустил его во второй раз, и оба потока заняли 3,2 ГБ ОЗУ...
Обычно я действительно согласен с тем, что масштабирование с помощью процессов - это хорошо... но делать это с Java и Spring Boot и его огромным потреблением оперативной памяти становится довольно быстро насмешками.
Для нас это очень важно, потому что в облаках мы используем оперативную память, равную деньгам:-(
Итак, есть ли другая модель времени выполнения - более похожая на Spring XD - в Spring Cloud Data Flow, которая более консервативна в отношении использования ОЗУ?
2 ответа
В настоящее время мы не хотим предоставлять собственные контейнеры, и мы довольно привержены модели микросервиса для Spring Cloud Data Flow. Это не обязательно должно привести к высокому потреблению памяти. Микросервисы (в том числе основанные на Spring Boot) могут работать очень скудно при правильной настройке. Часто используемая вами память используется как результат настроек виртуальной машины по умолчанию, несобранного мусора и т. Д.
Кроме того, Spring Cloud Data Flow в настоящее время находится в стадии разработки, и текущий опыт не обязательно является окончательным. Другими словами, есть много возможностей для улучшения.
Можешь немного описать, что ты делаешь? В частности, мне было бы интересно следующее:
1) Какую версию Spring Cloud Data Flow вы использовали? 2) Какой тип развертывания вы используете (локальный, CF и т. Д.) 3) Как вы измеряете потребление памяти?
Ура, Мариус
PS: Кроме того, что касается Spring XD, "прекращено" не отражает должным образом текущий и будущий статус. Для более точного утверждения я настоятельно рекомендую прочитать это: http://projects.spring.io/spring-xd/
В настоящее время мы не хотим предоставлять собственные контейнеры, и мы довольно привержены модели микросервиса для Spring Cloud Data Flow.
Итак, Spring XD, основанный на контейнерах, больше не поддерживается.
Это не обязательно должно привести к высокому потреблению памяти. Микросервисы (в том числе основанные на Spring Boot) могут работать очень скудно при правильной настройке.
Плз, будьте конкретны и не говорите о микросервисах. Этот термин почти всегда неверно истолковывается. Мы говорим о потоках Spring, где поток состоит из связанных модулей, а модуль реализован на Java.
У нас есть разные виды потоков. Представительный выглядит так:
"receive-data (http) | transform-data | enrich-data | store-data (rabbit, mongodb, etc.)"
В Spring Cloud Data Flow каждый шаг (модуль) запускается в своей собственной JVM. И я полностью согласен, что это хорошая вещь, чтобы включить горизонтальное масштабирование. Но, пожалуйста, имейте в виду уровень детализации. Модуль имеет более высокую степень детализации вызова функции, чем микросервисы (о нет, я это сказал).
Давайте предположим, что мы оптимизировали наши модули таким образом, чтобы каждый экземпляр в среднем занимал до 256 МБ памяти (и это очень оптимистично).
- Для нашего потока выше это означает, что 256 МБ x 4 модуля = 1 ГБ.
- По крайней мере, мы развертываем каждый поток дважды, чтобы иметь немного HA -> 2GB
- Умножается на количество разных потоков в вашей системе...
Это может работать для небольшого количества потоков и модулей, но взрывается очень быстро...
Для моего отдела очень важно, чтобы мы перестали использовать Spring XD... И я действительно ненавижу это, потому что я люблю Spring XD и его контейнеры! Для меня Spring XD является лучшим рабочим решением для обеспечения масштабируемого приема данных и наилучшим компромиссом между затратами на ресурсы, свободой использования Java и масштабируемостью.