我在一台计算机上运行了一个webmachine REST API服务器。由于预计此机器无法处理更多流量，我需要扩展到其他CPU上的其他节点。有没有办法配置这个？
如果没有正确的分发方式，我是否需要通过OTP，并发工人和主管手动完成？产生工人的地方并将请求发送到邻近的机器。
答案 0 :(得分：1)
这取决于您的使用案例。最好的方法是观察遇到问题的地方，并做出相应的反应。
您可以将应用程序视为三个独立的部分。第一个是REST接口，第二个可能是业务逻辑（稍后会更多），第三个是数据本身（资源，我们称之为数据存储，但它甚至可能只是另一个服务）。
这个最简单。我假设您正在使用单独的服务（如Riak群集），您可以在其中单独进行缩放。您可以考虑的一件事就是确保Webmachine和您的数据存储之间的连接可以根据您的需求进行扩展。
如果您的服务器无法处理足够的请求，只需在其旁边添加另一个请求即可。您可以通过路由器向therm，ans发送请求，因为他们将使用相同的数据存储，它们将保持“同步”状态。
基于http的REST假定无状态通信。这意味着，任何两个请求（形成相同的用户或两个不同的请求）都不共享任何资源，并且可以由不同的应用程序处理（您也不必在Webmachine实例之间共享任何内容）。
理论上你不应该在REST API服务器中使用任何这个，但仍然可以稍微讨论一下。
您的一些请求可能只需要提供更多内容，而不仅仅是提供内容。您可能正在进行一些计算（例如，提供需要生成的统计信息）。您可能正在更新某些资源，需要在一个位置更改一个数据（可以将其视为事务处理）。它可能需要更多的计算能力或状态同步，这将使扩展更加困难。
解决这个问题的方法是将REST与这种逻辑分开。特别是引入微服务，你可以独立于Webmachine本身扩展或缩小。
在Erlang中你实际上可以引入单独的applications inside Erlang VM。在本主题中使用Distributed Erlang（和little more以及工作人员（例如poolboy）可以扩大规模。我建议使用此方法，因为它最容易实现，由于Erlang的异步特性，它可以很容易地移植到外部微服务。
您还应该检查您的盒子是否可以处理此类流量。在你的作品中，最常见的错误之一不是increasing maximal number of file descriptors。但同样，首先你应该观察这些问题，然后对它们做出反应。在大多数情况下，过早优化并不会有所回报。
您可以使用Exometer或更多开箱即用的WombatOAM等工具监控我们的应用和系统资源。
您可以（应该）使用tsung或basho-bench
等工具对您的应用进行压力测试