2

我有一个在一台机器上运行的 webmachine REST API 服务器。预计这台机器无法处理更多流量，我需要扩展到其他 cpu 上的其他节点。有没有办法配置这个？

如果不是这里正确的分配方式，我是否需要通过 OTP、并发工人和主管手动进行？产生一个工人并将请求发送到相邻的机器。

4

1 回答 1

1

这取决于您的用例。最好的方法是观察你遇到问题的地方，并做出相应的反应。

您可以将您的应用程序视为三个独立的部分。第一个是 REST 接口，第二个可能是业务逻辑（稍后再讲），第三个是数据本身（资源，我们称之为数据存储，但它甚至可能只是另一个服务）。

数据

这个是最简单的。我假设您为此使用单独的服务（例如 Riak 集群），您可以在其中单独进行扩展。您可以研究的一件事就是确保 Webmachine 和您的数据存储之间的连接可以扩展以满足您的需求。

界面

如果您的服务器无法处理足够的请求，只需在其旁边放置另一个。您可以通过路由器向双方发送请求，因为它们将使用相同的数据存储，因此它们将保持“同步”状态。

基于 http 的 REST 假设无状态通信。这意味着，任何两个请求（来自同一个用户或两个不同的用户）不共享任何资源，并且可以由不同的应用程序处理（您也不必在 Webmachine 实例之间共享任何内容）。

领域逻辑

理论上，您的 REST API 服务器中不应该有任何这些，但仍然让我们稍微讨论一下。

您的某些请求可能只需要提供内容即可。您可能正在执行一些计算（例如提供需要生成的统计信息）。您可能正在更新一些资源，需要在一个地方更改多个数据（可以将其视为事务）。它可能需要更多的计算能力或状态同步，这将使扩展更加困难。

解决这个问题的方法是将 REST 与此类逻辑分开。特别是引入微服务，您可以独立于 Webmachine 本身进行扩展或缩减。

在 Erlang 中，您实际上可以在 Erlang VM 中引入单独的应用程序。这些再次可以通过使用分布式 Erlang进行扩展（在这个主题中并没有更多的工作人员（比如poolboy。我会推荐这种方法作为开始，因为它最容易实现，并且由于 Erlang 的异步性质它可以总是很容易移植到外部微服务。

PS。系统资源

您还应该检查您的盒子是否可以处理此类流量。最常见的错误之一是没有增加生产中文件描述符的最大数量。但同样，首先你应该观察这些问题，然后对它们做出反应。在大多数情况下，过早的优化不会得到回报。

PS2 什么和什么时候

您可以使用Exometer或更多开箱即用的WombatOAM等工具监控我们的应用程序和系统资源。

您可以（应该）使用tsung或basho-bench等工具对应用程序进行压力测试

于 2014-10-21T14:31:19.410 回答