9

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

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

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

1 回答 1

18

作为您引用的项目的原始作者和 Apache NiFi PMC 的成员，让我首先说您提出了很好的问题，我很感激您来自哪里。我们可能应该改进介绍文件，以更好地反映您提出的问题。

您说得对，当前的方法是创建流程模板，然后您可以将其提交给版本控制。人们也可以使用与 NiFi 的 REST API 交互的脚本来自动部署这些模板。但我们可以而且应该做的远不止让数据流管理工作更容易，无论您是开发人员准确编写将要部署的内容，还是专注于运营的人必须自己将这些部分组合在一起。

  1. 流的管理和版本控制 [1] 应该更容易和集中管理，以便在多个集群和环境 [2] 之间共享。
  2. 我们需要确保环境特定的值很容易映射到给定的环境中，但模板仍然是可移植的 [3]。
  3. 我们需要使多用户/多租户的用户体验更加直观和自然 [4]。

元素 1 和 2 将出现在即将发布的 1.0 版本中，而项目 3 将在即将发布的版本中完全涵盖。与此同时，对于多开发人员的情况，我认为他们将自己的本地实例视为“单元测试”他们的流程然后使用共享的登台或生产环境的地方是有意义的。要记住的关键是，对于许多流和 NiFi 的方法，可以让给定流模板的多个实例执行每个实例，每个实例都被馈送数据的实时馈送。该流程的结果/输出可以连接到实际传递到某个地方或简单地接地。这样，它很像 Git 等源代码控制中的分支思维模型。您可以选择您认为是“生产”的那个 如果您愿意，与图表上的哪个流程只是一个正在进行的功能分支相比。对于来自更传统方法的人来说，这并不明显，我们需要做更多的事情来描述和证明这一点。但是，我们也应该支持更传统的方法，这就是我链接到的一些功能建议将实现的。

[1] https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows

[2] https://cwiki.apache.org/confluence/display/NIFI/Extension+Registry

[3] https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry

[4] https://cwiki.apache.org/confluence/display/NIFI/Multi-Tentant+Dataflow

于 2016-06-21T02:00:17.990 回答