我公司有一个 Web 服务 API，它开始得到广泛使用。最近我们遇到了内存不足的问题。我们优化了一些效率低下的代码并解决了这个问题。
我们知道我们将进一步扩张，我们希望有一个好的方法来应对拥堵的交通。
有人提出一个想法，即为一些使用量较大的客户提供不同的 URL。在我看来，这是错误的做法。在某些情况下，URL 会指向独立的服务器，但有些 URL 也会指向更多的虚拟目录。
无论如何，这都是解决问题的好办法吗？我预见到严重的可维护性问题，并且会导致更多问题，而不是解决这些问题。请给我一些双方的利弊。
这已经位于负载平衡服务器场中。
答案1
如果它已经在负载平衡的服务器场中，并且您获得了过多的负载，并且您已经尽可能地进行了优化，那么自然的下一步似乎是扩大您的服务器场以满足需求。
答案2
如果你达到了负载均衡器的最大容量，并且有空闲的服务器，你可以尝试使用某种反馈来更均匀地平衡，例如mod_cluster。如果你仍然遇到限制，你可以尝试循环 DNS作为分发多个 URL 的替代方案。这样，您可以将负载平衡转移给客户端。您可以通过以下方式向此解决方案添加反馈：命名。另一种方法是使用更大的负载均衡器，当然这需要更多的钱。
答案3
你的 API 可以利用缓存吗？
如果 API 的特定部分经常被调用，并返回相同的结果，例如memcached可能会对你有很大帮助。
我认为为不同客户提供特定 URL 没有任何好处。在我看来，要么您需要更多服务器，要么您的负载平衡无法正常工作。
答案4
我现在会关注那些使用量较大的客户。你能向他们收取更多费用吗？他们的使用量是否超出了应有的水平？你能帮助他们优化系统，让他们不需要如此频繁地使用吗？你能为你的 API 添加速率限制吗？他们的使用量是否足以为他们提供自己的服务器并向他们收取相应的费用？
下一步是查看您的架构。您的 Web 服务器前面是否有缓存代理？您是否有单独的数据库服务器？您的所有服务器和代码是否都经过了优化？您是否缓存了所有可能的内容？您的硬件是否良好？
一旦您确定您的架构尽可能地优化，您实际上只需要在开始达到限制时向负载平衡设置添加额外的盒子（无论是额外的缓存，额外的 Web 服务器还是额外的后端服务器都取决于您达到的限制）。