Spring Cloud Data Flow 2.1 聚焦于指南、档案、示例的升级
感谢Spring Cloud Data Flow社群
在最近的调查中，我们收到了许多关于Spring Cloud Data Flow中参考指南、文件和示例方面的缺陷或局限性的建议和评价。基于反馈，我们也一直致力于针对Spring Cloud Data Flow的问题，寻找到更容易的解决方案！因此，我们将2.1 版本的释出主题认定为“帮助社群和使用者”。今天，我们在此推出全新的Spring Cloud Data Flow微站，以帮助开发者能从我们的产品中更多地受益。
1 背景
Spring旗下的工程专案在StackOverflow、GitHub、Slack和Gitter channels等各大开发者社群中都拥有重要地位。Spring Cloud Data Flow (SCDF)生态系统中的工程专案在所有这些社群平台上都得到了很好的体现。每天，您都会看到Pivotal的团队正忙于解答社群问题。我们对这些与社群的常规互动感到自豪。在回答社群问题、支援客户时，我们注意到，为求更好地构建流处理和批处理解决方案，在不同工程、参考指南、和示例间的切换上下文的需求非常迫切。这与我们在调查结果中收到的反馈是一致的。
所有这些上下文切换的主要原因是，在SCDF生态系统中有着各种各样的专案工程，每个工程都有着不同的特征和释出频率。SCDF将它们整合到了一组统一的开发工具中，以构建、部署并管理流处理和批处理资料管道。因此，社群问题的回复通常指向各种特定工程的资源。
这是以微服务架构搭建SCDF的副作用吗? 也许是。但由于其模组化设计，这种架构更是给我们带来了全新的巨大好处。如果算上Spring Cloud Stream、Spring Cloud Task、Spring Cloud Skipper以及SCDF生态系统中的其他专案，那么它仅在过去一年里就轻松拥有超过100个释出的版本！
为了最小化上下文切换，并轻松开发产品功能，我们意识到我们需要提供一个循序渐进的开发员指南，以深入研究新特性，强化和用例的可能性。
Spring Cloud Data Flow微站应运而生…
2 我们的目标
首要目标是深入，而不仅仅为了突出一些功能的广度。最终，我们希望能够解答开发人员在使用SCDF构建流处理和批处理解决方案时会遇到的问题。鉴于这种想法，我们选择以以简入繁、循序渐进的场景开始，这样大家就可以选择合适自己的难度。最后，我们重点关注可重复性，开发员可以学习到程式码片段、端到端的用例和方法，以便让他们在更短的时间内精通Spring Cloud Data Flow。3 其他值得注意的更新
虽然这次释出的重点是新微站，但该生态系统中还有一些其他改进也值得一提……Spring Cloud Stream 2.2正式释出: 主要目标是为了优化Spring Cloud Stream中Spring Cloud Function的程式设计模型。我们正在开发一个专注讲解Spring IO的部落格，希望大家持续关注。RabbitMQ、Apache Kafka和Kafka Stream binders得益于基于社群的贡献，一些功能又有了新提升。最后，Kinesis binder在近期增加了对KCL/KPL和DynamoDB streams的支援。脱离bit.ly以便批量应用注册:为了方便起见，我们已将基于bit.ly的短URL重新导向我们Spring储存库中的批量注册属性档案。多年来，这带来了很多困扰，但现在我们可以很高兴地宣布，我们正在脱离bit.ly,并以来自Spring IO域的URL进行替换。更新后的URL有更多能力，详情请查阅相关参考指南。指尖上的部署属性:支援平台的特定平台部署属性非常繁琐。我们已经看到了许多关于人们在部署体验方面遇到困难的报告。现在，UI中的一个新下拉选单将自动填充所选平台的部署器属性，从而改进了该特性。开发者不再需要从文件/程式码中寻取属性，只需从下拉选单中进行简单的选择。并行任务的启动优化:考虑到云平台中该用例的客户数量，我们释出了一个参考架构来描述cloud Foundry和Kubernetes的端到端解决方案。此架构的一个关键就是能够限制并执行任务的启动，以避免可用资源的饱和。最开始这个架构是应用于新资料组，我们收到了大量关于将检查点机制用于历史资料组的反馈。现在，我们有了一个改进的解决方案，即以估量实际执行的任务来进行下行决策。Docker Compose / Helm Chart定制:随着对SCDF的Docker Compose和Helm Chart的快速入门的需求日益增长，我们添加了定制功能，以切换到不同的监控解决方案和资讯中介软件。
