我有一台网络机器REST API服务器在一台机器上运行。由于预计这台机器将无法处理更多的流量，我需要扩展到其他cpu上的其他节点。有没有一种配置方法？
如果不是，这里的正确分配方式是什么，我是否需要通过OTP、并发工作人员和主管手动进行分配？在那里产生一个工作者并将请求发送到相邻的机器。
这在某种程度上取决于您的用例。最好的方法是观察你遇到问题的地方，并做出相应的反应。
您可以将您的应用程序视为三个独立的部分。第一个是REST接口，第二个是业务逻辑（稍后会详细介绍），第三个是数据本身（资源，我们称之为数据存储，但它甚至可能只是另一个服务）。
数据
这个是最简单的。我假设您对此使用单独的服务（如Riak集群），在那里您可以单独进行扩展。您可以考虑的一件事是确保Webmachine和您的数据存储之间的连接能够扩展到足以满足您的需求。
接口
如果你的服务器无法处理足够的请求，只需在旁边放一个。你可以用路由器将请求发送到两个therm，因为它们将使用相同的数据存储，所以它们将保持"同步"。
基于http的REST假定了无状态通信。也就是说，任何两个请求（来自同一个用户或两个不同的用户）都不共享任何资源，可以由不同的应用程序处理（您也不必在Web机实例之间共享任何内容）。
域逻辑
理论上，您不应该在REST API服务器中有任何这样的内容，但仍然让我们讨论一下。
您的一些请求可能只需要提供内容，而不需要更多的工作。您可能正在进行一些计算（比如提供需要生成的统计信息）。您可能正在更新一些资源，需要在一个地方更改多个数据（可以将其视为事务）。它可能需要更多的计算能力，或者状态同步，这将使缩放更加困难。
解决这个问题的方法是将REST从这样的逻辑中分离出来。特别是引入微服务，您可以独立于Webmachine本身进行扩展或缩小。
在Erlang中，您实际上可以在ErlangVM中引入单独的应用程序。这些可以通过使用分布式Erlang（在本主题中还有更多内容）和pull-ofworker（比如poolboy。我建议首先使用这种方法，因为它最容易实现，而且由于Erlang的异步特性，它总是可以很容易地移植到外部微服务。
PS。系统资源
你还应该检查一下你的盒子是否能处理这样的流量。最常见的错误之一是没有增加生产中文件描述符的最大数量。但是，首先你应该观察这些问题，然后对它们做出反应。在大多数情况下，过早的优化是没有回报的。
PS2什么时候
您可以使用Exometer或更多开箱即用的WombatOAM等工具来监控我们的应用程序和系统资源。
您可以（应该）使用tsung或basho bench 等工具对应用程序进行压力测试