我們是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