从1台Web服务器+ 1台数据库服务器扩大规模
我们是Web 2.0公司，它使用LAMP从头建立了一个托管的内容管理解决方案。总之，人们登录到我们的后端来管理他们的网站内容，然后使用我们的API来提取内容。该API被插入到可以在网页上的任何位置托管的模板中。从1台Web服务器+ 1台数据库服务器扩大规模
缩放为我们取得了进展如下：
- 共享主机（的1and1）
- 专用的单一服务器托管（Rackspace公司）
- 1 Web服务器，1 DB服务器（Rackspace公司）
- 1后端的Web服务器，1台API的Web服务器，1个DB服务器
- 内存缓存，缓存，缓存，缓存。
的问题是，什么是未来的我们呢？每当我们的某个网站被挖掘或在一个受欢迎的网站中提及时，我们的API服务器就会因为连接太多而崩溃。或者每当我们的数据库服务器出现查询溢出时，我们的Web服务器就会请求备份。
这显然是任何一家公司像我们这样的“下一个问题”，我想知道，如果你能在某些方向指向我。
我目前吸引到的虚拟化解决方案（如EC2），但需要什么考虑一些指针。
什么/在哪里/如何规模取决于你的问题。既然你已经打了几次，而你知道它是API服务器，你需要确定究竟是什么导致了这个问题。
它是DB查找时间？
Web服务器只是即使他们短暂的无法处理请求的体积？
API请求花费太长时间来处理？ （独立于数据库查找，例如，代码是否需要运行一点）？
一旦你确定是什么问题，你应该有你需要做的一个非常清晰的画面。如果它只是大量的请求，并且它是API服务器，那么您只需要更多的Web服务器（并且更改代码以允许水平缩放）或更强大的Web服务器。如果API请求花费的时间太长，则您正在查看代码优化。在可伸缩性方面，从来没有一次修复。
最常见的缩放问题有每个请求，这反过来又导致更多的Web服务器，从而导致更多的数据库交互的实际代码的速度慢（2-3秒）的执行做（跨服务器会话等），这会导致数据库性能问题。具有memcache的高性能，独立于服务器的代码（我实际上更喜欢使用memcache的包装，因此应用程序不知道/关心从何处获取数据，只是获取它并且翻译层处理DB/memcache查找以及填充内存缓存）。
您要查找的缩放级别是多少？它是一个解决方案，例如垂直缩放？如果这是一个更具战略性的扩展项目，那么当前的架构是否支持水平扩展？
如果您的瓶颈是读取或写入，这取决于您的瓶颈。缩放写入比读取更困难。
这也取决于你在数据库中有多少数据。
如果您的数据库很小，但无法应付读取负载，您可以部署足够的内存以适合内存。如果它仍然无法应付，可以添加只读副本，可能与Web服务器位于同一个盒子中，这将为您提供良好的可扩展性 - 来自一个MySQL主服务器的从服务器数量非常高，主要取决于写工作量。
如果您需要缩放写入，那是完全不同的游戏。要做到这一点，您需要将数据分成水平（分区/分片）或垂直（功能分区等），以便将工作负载分散到多个不需要彼此工作的写入服务器上。
我不确定EC2能为您做什么，它基本上提供了一个缓慢，高延迟的机器，它具有非持久性光盘，并且在一个或多或少不存在的SLA的末端提供低IO性能。我想它可能对您的情况有用，因为您可以相对较快地提供它们 - 假设您只是将它们用作只读副本并且没有太多数据（请记住它们具有非持久性光盘和糟糕的IO）
嗨，让娄，这是长期的战略规模。 – Etienne 2009-10-13 21:48:47