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