Deployment apachenifi的开发生命周期

我意识到，在NiFi中，正如他们的文档所定义的那样，“生产中会出现持续改进”。因此，这不适合用作传统的开发工具。然而，对于我正在进行的项目，已经决定这是我们将要使用的工具，所以我不想讨论它的优点，因为我意识到会有一些问题

例如，如果我将更改推送到现有环境中（从暂存到生产），并且目标中存在实时编辑，则这些更改将被覆盖。所以我对如何组织开发生命周期有疑问

• 是否可以合并由多个开发人员并行完成的更改（合并导出的xml模板文件）？我猜合并任何重大变化都可能很困难，但我没有尝试过
• 如何管理版本控制更改？我假设您可以将整个配置导出为模板，并将其检查到版本控制中
• 如何将流部署到不同的服务器？您可以只部署库存NiFi部署，然后使用NiFi REST API从导出的模板（如上所述）更新它吗
• 如何管理部署到可能具有不同配置的不同环境？是否必须更新模板XML文件？或者我可以从Zookeeper之类的东西动态地把它拉进来吗

---

作为您引用的文章的原始作者和Apache NiFi PMC的成员，我首先要说的是，您提出的问题很好，我很欣赏您的来历。我们可能应该改进介绍文档，以更好地反映您提出的问题

现在的方法是创建流的模板，然后将其提交给版本控制。人们也可以使用与NiFi的RESTAPI交互的脚本自动部署这些模板。但是，我们可以而且应该做的远不止是让数据流管理工作变得更容易，不管您是一名开发人员，还是一名专注于操作的人员，必须自己将这些部分组装起来

流的管理和版本控制[1]应该更容易集中管理，以便跨多个集群和环境共享[2]

我们需要确保特定于环境的值很容易映射到给定的环境中，但模板仍然是可移植的[3]

我们需要让多用户/多租户用户体验更加直观和自然[4]

1和2的元素将出现在即将发布的1.0版本中，第3项将在即将发布的版本中完全涵盖。同时，对于多开发人员案例，我认为对于他们来说，将自己的本地实例作为“单元测试”流程的场所，然后使用共享的暂存或生产环境是有意义的。需要记住的关键是，对于许多流，使用NiFi的方法，可以让给定流模板的多个实例执行每个实例，并向每个实例提供实时的数据馈送。该流程的结果/输出可以连接到实际交付的地方，或者简单地接地。通过这种方式，它非常类似于Git等源代码管理中分支的心智模型。你可以选择你认为是“生产”的，而在图上哪个流程仅仅是一个正在进行的特征分支。对于来自更传统方法的人来说，这并不明显，我们需要做更多的工作来描述和证明这一点。然而，我们也应该支持更传统的方法，这就是我链接到的一些特性建议所能实现的

[1]

[2]

[3]

---

[4]

看起来[1]、[2]和[3]尚未实现。您能否提供如何解决当前版本中所述问题的最新信息？我认为现在人们只是在导入和导出模板。这有一些缺点，例如，没有真正的更新选项，您可以删除旧版本并读取新版本。您是对的，没有真正的更新选项（对于现有流程组）。目前的常见模式是推送流程组的新版本，然后更改为该组提供服务的连接。这可以通过编程方式通过几个REST调用来完成。用于流管理、流程组变量和版本化组件的ApacheNIFI注册表在最新版本中的后两个组件中都进行得很好。下一个版本中可能集成了用于版本化流的ApacheNIFI注册表，此时您将获得真正的更新！应该很酷。