目前，我们正在使用Spring XD来接收具有许多流（和模块）的数据。不幸的是，Spring XD已经停产，我们不得不四处寻找替代方案。
因此，我们研究了Spring Cloud Data Flow，因为我们希望通过shell动态部署流。
不幸的是，简单流"http | log"占用了1.6GBRAM。然后我第二次启动了它，两个流都占用了3.2 GB RAM。。。
通常我真的同意，通过流程进行扩展是一件好事。。但要用Java和Spring Boot以及它对RAM的巨大消耗来做到这一点，它很快就会变得非常可笑。
对我们来说，这是非常关键的，因为在云中，我们使用RAM等于金钱：-（
那么，在Spring Cloud Data Flow中是否有另一个运行时模型——更像Spring XD——在RAM使用方面更保守？
此时，我们不希望提供自己的容器，我们非常致力于Spring Cloud Data Flow的微服务模型。这不一定会导致高内存消耗。微服务（包括基于Spring Boot的微服务）在经过适当调整后可以非常精简地运行。很多时候，您看到的内存使用率是VM默认设置、未收集垃圾等的产物
此外，Spring Cloud Data Flow目前正在开发中，目前的体验不一定是最终的体验。换句话说，还有很大的改进空间。
你能描述一下你在做什么吗？特别是，我对以下内容感兴趣：
1） 您一直在使用什么版本的Spring Cloud Data Flow？2） 您正在使用哪种类型的部署程序（本地、CF或其他）3） 你是如何衡量内存消耗的？
干杯，马里乌斯
PS：此外，关于Spring XD，"停产"并不能正确反映当前和未来的状态。为了获得更准确的陈述，我强烈建议阅读以下内容：http://projects.spring.io/spring-xd/#announcement
目前，我们不希望提供自己的容器，我们非常致力于Spring Cloud Data Flow 的微服务模型
因此，基于容器的SpringXD已经停产。
这不一定会导致高内存消耗。微服务（包括基于Spring Boot的微服务）在经过适当调整后可以非常精简地运行。
Plz，保持具体，不要谈论微服务。这个词几乎总是被误解。我们讨论的是Spring流，其中一个流由链接的模块组成，而一个模块是用Java实现的。
我们有不同种类的溪流。一个有代表性的例子是：
"receive-data (http) | transform-data | enrich-data | store-data (rabbit, mongodb, etc.)"
使用Spring Cloud Data Flow，每个步骤（模块）都在自己的JVM中运行。我完全同意这是实现水平缩放的一件好事。但请记住粒度级别。模块比微服务更有可能具有函数调用的粒度（哦，不，我已经说过了）。
让我们假设我们优化模块的方式是，每个实例平均最多消耗256MB内存（这是非常乐观的）。
- 对于我们上面的流，这意味着256MB x 4个模块=1GB
- 至少我们将每个流部署两次，以获得一些HA->2GB
- 乘以系统中不同流的数量
这可能适用于少量流和模块，但爆炸速度非常快。。。
对于我的部门来说，这是至关重要的，因为我们开始停止使用Spring XD。。。我真的很讨厌它，因为我喜欢Spring XD和它的容器！对我来说，Spring XD是建立可扩展数据接收的最佳工作解决方案，也是资源成本、使用Java的自由度和可扩展性之间的最佳折衷方案。