如何啟動具有高未來增長潛力的網站。
我希望我有一個簡單的問題。因為我確信設置它的步驟很複雜，所以我想知道一些事情。我們有一個團隊一直在開發一個即將完成的偉大平台。我們一直在開發沒有什麼特別的標準燈安裝。我們在模式上遇到的問題是如何規劃燈配置的增長。購買一台伺服器並在其上傳入應用程序很容易，但是我們如何計劃何時需要 3、4、5 台伺服器並繼續添加到此方案而不破壞站點或每次都將其關閉？基本上需要避免停機。我們更願意購買我們自己的伺服器，並在同一地點自行維護它們。
本質上，我們如何設置站點，以便從一開始就為並行性而設計（我相信這就是這個詞？）。
我希望我有一個簡單的問題。
對不起，但這幾乎完全相反。可擴展性是一大組設計選擇，如果您希望它超級簡單，幾乎需要從一開始就融入其中。這通常需要做很多額外的工作，如果你之前從未建構過這樣的系統，通常會更容易通過“成長的痛苦”來學習。
我們對這些問題的通用罐頭答案是：稍後處理可伸縮性。建立您的站點/應用程序/任何東西，並儘可能長時間地投入更強大的伺服器。一旦該選項用完，就開始擔心如何拆分邏輯層（這通常是最簡單的），例如前端 Web 伺服器與數據庫伺服器。然後弄清楚如何同時執行兩個 Web 伺服器，依此類推。
問題的一個主要部分是，雖然我可以放棄我的手並說“數據庫分片”或“主動-主動集群”，但它們的實際實現將在很大程度上取決於您的應用程序內部的工作方式。LAMP 甚至不是很“標準”——我假設你的意思是 PHP 或 Perl，它們都不能很好地處理開箱即用的並發（並且可能是你要處理的第一個瓶頸；至少這些是常見的問題，並且有很多關於如何處理它的文章）。
更新： 實際上我在找到可擴展性主題的簡明大綱時遇到了一些麻煩。我遇到了這個：
- 無狀態應用
- 松耦合
- 非同步
- 延遲載入
- 記憶體
- 並行性
- 分區
- 路由
來自不同來源的類似大綱：
關注點分離（表示、邏輯/應用程序、數據、傳輸/路由、管理）
最小化狀態分佈（即狀態不跨越上述分離）
冗餘
獨立環境（Dev、QA、Stage、Prod）
建造
- 自動化（腳本、建構、管理等）
- 配置管理
- 中央身份管理
- 部署管理
跑
- 監視器
- 重新評估能力，計劃
- 日誌，日誌，日誌
- 持續改進週期（極端的敏捷開發）
我可以寫一本書，將第一個列表中的每個主題分解為單獨的技術。每個人都可以寫一本關於在各種平台、不同模型等上實現的書（許多人已經有了關於它們的書）。
如果有人想對此添加更多內容或添加詳細資訊，請隨意。