针对长期纱线应用的设计问题

Question

我正在尝试编写一个纱线应用程序，并希望就我想到的一些设计问题得到一些建议。我已经浏览了更简单的示例应用程序，如分布式shell及其中的一些变体，因此我熟悉基本API。我想要做的是创建一个具有Web界面的应用程序，用户可以与之交互并可能提供某种任务（任务的性质无关紧要）。基于该工作，UI请求容器进行处理。

我想到的理想安排是我的应用程序主机提供了这个Web UI，并且在有人来到AM网站并请求一些工作之前不会分配任何容器。此时，AM应该能够注册新容器并为其分配工作。

1. 如果AM提供了Web UI，我的理解是，每次将应用程序提交给RM时，RM都会选择AM。这意味着AM可以具有不同的IP，因此在应用程序重新启动时可以使用不同的URL。这种行为是否表明AM不应该用于此目的，并且可能完全不同的应用程序（非纱线）可以提供Web UI并且更适合它？
2. 在所有示例中，我已经看到样本纱线应用程序AM请求容器作为其调用的一部分。有人可以指向AM相关的API，它允许在以后基本上请求容器，或者可能让我们说修改已经声明的容器的资源需求（内存），甚至可以按需增加容器数量
3. 与最后一点类似，大多数例子都集中在做某事然后结束的纱线应用上。你可以想象我的应用程序有意义继续永远运行（作为一个Web应用程序）。对于这些长时间运行的应用程序，客户端到RM api会发生变化。是否可以断开客户端提交作业流程或使用＆amp;在后台运行它

我很感激任何建议

Answer 1

关于问题（1）您可以在非托管模式下运行AM。这将允许您在可以更好地控制其IP地址的专用计算机上运行YARN群集之外的AM。

Answer 2

看看Apache Twill。 Apache Twill是Apache Hadoop YARN的抽象，可以降低开发分布式应用程序的复杂性。可以启动容器来执行长时间运行的进程（服务器）。

可以通过Apache Curator来处理为Web UI提供服务的容器的更改IP。可以使用Apache Curator的Service Discovery机制在ZooKeeper中注册服务。