我们是使用 LAMP 从头开始构建托管内容管理解决方案的 Web 2.0 公司。简而言之，人们登录我们的后端来管理他们的网站内容，然后使用我们的 API 来提取这些内容。这个 API 被插入到可以托管在互联网上的任何地方的模板中。
我们的扩展进展如下：
- 共享主机（1and1）
- 专用单服务器托管 (Rackspace)
- 1 个 Web 服务器，1 个 DB 服务器（机架空间）
- 1 个后端 Web 服务器、1 个 API Web 服务器、1 个 DB 服务器
- 内存缓存，缓存，缓存，缓存。
问题是，我们的下一步是什么？每次我们的某个网站被挖掘或在热门网站中提及时，我们的 API 服务器都会因连接过多而崩溃。或者，每当我们的数据库服务器被查询淹没时，我们的 Web 服务器请求就会备份。
对于像我们这样的任何公司来说，这显然是“下一个问题”，我想知道您是否可以指出一些方向。
我目前对虚拟化解决方案（如 EC2）很感兴趣，但需要一些关于要考虑什么的指示。
什么/在哪里/如何扩展取决于您的问题是什么。由于您已经被击中几次，并且您知道它是 API 服务器，因此您需要确定实际导致问题的原因。
是数据库查找时间吗？
Web 服务器无法处理的大量请求，即使它们是短暂的？
API 请求处理时间过长？（独立于数据库查找，例如，代码是否需要一些时间才能运行）？
一旦你确定了问题是什么，你应该对你需要做什么有一个非常清晰的认识。如果它只是请求量，并且是 API 服务器，那么您只需要更多的 Web 服务器（和代码更改以允许水平扩展）或更强大的 Web 服务器。如果 API 请求花费的时间太长，那么您正在考虑代码优化。在可扩展性方面，从来没有一劳永逸的解决方案。
最常见的扩展问题与每个请求的实际代码执行缓慢（2-3 秒）有关，这反过来会导致更多的 Web 服务器，从而导致更多的数据库交互（对于跨服务器会话等）这会导致数据库性能问题。具有 memcache 的高性能、与服务器无关的代码（我实际上更喜欢 memcache 周围的包装器，因此应用程序不知道/关心它从哪里获取数据，只是它获取它并且翻译层处理 DB/memcache 查找以及填充内存缓存）。
真的取决于你的瓶颈是读取还是写入。缩放写入比读取更难。
它还取决于您在数据库中拥有多少数据。
如果您的数据库很小，但无法应对读取负载，您可以部署足够的 ram 以使其适合 ram。如果它仍然无法应付，您可以添加只读副本，可能与您的 Web 服务器在同一个盒子上，这将为您提供良好的读取可扩展性 - 来自一个 MySQL 主服务器的从属数量相当高，主要取决于写入工作量。
如果您需要扩展写入，那是完全不同的游戏。为此，您需要将数据拆分为水平（分区/分片）或垂直（功能分区等），以便您可以将工作负载分散到几个不需要彼此工作的写入服务器上。
我不确定 EC2 可以为您做什么，它本质上是在或多或少不存在的 SLA 结束时提供具有非持久性磁盘和低 IO 性能的慢速、高延迟机器。我想这对您的情况可能很有用，因为您可以相对快速地配置它们 - 只要您只是将它们用作只读副本并且您没有太多数据（请记住它们有非持久性磁盘和糟糕的 IO）
您正在寻找的扩展级别是多少？它是一个权宜之计的解决方案，例如垂直扩展吗？如果是更具战略性的扩展项目，您当前的架构是否支持水平扩展？