管理器节点向self发出HTTP请求？

Question

我正在开发一个使用Manager Worker模式的分布式应用程序。应用程序的管理器节点通过WorkerNode对象向工作节点提交工作(允许将WorkerNode视为服务器本身)。

管理器节点也可以将工作提交给它的内部WorkPool，这目前是通过显式调用WorkPool类来完成的，而无需进行HTTP调用。

我正在编写大量代码，以确保“本地工作”被提交到管理器节点上的WorkPool类，并且“远程工作”通过HTTP (使用WorkerNode对象)提交给远程WorkPool类。

这导致了一些尴尬的边缘情况，开发人员需要担心，比如在节点之间均匀地分配WorkUnit对象。

提出的设计：

将所有工作池视为远程工作池。我可以通过分配给WorkerNode地址的localhost来控制本地工作池。这还要求管理节点在运行时将工作节点路由添加到应用程序中(烧瓶蓝图，因此很简单)。

缺点：

管理节点向自身发出请求。可能会导致缓存问题，新的开发人员说“到底是什么”，或者在稍后添加反向代理服务器时出现网络问题。

Improvements:

工作池是完全抽象的，在提交、检索或杀死池中的工作单元时不存在边缘情况。

单元测试我的WorkRouter类变得非常容易。

与本地工作池或远程工作池的接口是通过相同的对象类型完成的，保持代码干燥。

类似问题：从API实例内部调用API端点是否有错误的设计？

这个问题似乎与分布式系统无关，因此在处理单个无状态应用程序时，使用服务层是一个合适的答案。

Answer 1

我整个上午都在想这个问题:)

拥有API调用本身并不是一个优雅的解决方案。但是，使这种抽象具有许多好处，可以通过将进一步的责任放在WorkerNode类上来完成。

WorkerNode类现在负责在管理器节点上运行时与服务层逻辑进行接口。这个类足够聪明，可以根据它的‘UUID值’知道它在哪里运行。我们可以在类接口中添加一个简单的检查，以便使用服务层或HTTP协议进行分支。

现在，WorkRouter类可以遍历每个WorkerNode，并且在与其他服务层逻辑的接口上没有边界情况。