使用 Linode 主機，ubuntu16.04 apache + php + mariadb 架設網站，外加 cloudflare 管 DNS
目前需要有分流機制，但是沒有做過不清楚怎麼做～
（目前是使用 Linode 4G方案）
想問問有經驗的大大們如何著手？
裡面有兩種不同性質網站，一個是電商一個是部落格（而因為流量持續增加中，光是部落格CPU使用率已超過 33%，電商還沒開始營運）
而電商網域是：shop.XXX.com ，部落格是 XXX.com，（使用 htaccess 實現）
雖然這兩個資料本身就是相通的，同台主機和數據庫，甚至有不少「共用」的程式腳本（應該是說很難將兩個不同性質網站「拆開」）
所以有點蛋疼⋯⋯
想問怎麼將這兩個網站移到兩台不同的主機上？
或是有類似的做法可以實現「分流」機制，至少瀏覽人數突然「爆多」的時候不會有太大問題？
是有聽到一個說法是臉書可能連一個按鈕都是一台主機（？）
不過確實不無可能，畢竟每一秒可能要處理一億次請求，想想也合理
想問說大家會怎麼做？或是有經驗的大大分享如何做？
已邀請的邦友 {{ invite_list.length }}/5
您好：
從您的敘述來看，您可能使用的是 LAMP 的架構，這個架構不是不好，而是沒有橫向擴充的機制！
比較簡單的解決方式，就是撒錢！
將兩個網域：shop.XXX.com、與 XXX.com 分別放置不同主機，每個主機各自管理，資源不會互搶，而主機部分最好要有可以動態長大的機制，例如 Azure 的雲端主機與 AWS 都可以，也就是說當 CPU 資源維持在 XX% 時、多少時間(可自訂)，就會自動生出第二台幫你分流，或是主機自動升級(Lv1 to Lv2)之類的。
如果要複雜，或是預估人數破百萬！以上的架構是撐不下來的！
必須要全部分開架設，前端可以使用 Apache、nginx(我個大力推薦使用 nginx，因為效能讚且速度極快)，有 ELB 可以幫忙分流！
而後端的資料庫就要重新設計囉，如果又有登入的設計，大量人流湧進來，後端資料庫每筆交易處理時間都會大於 3～10 秒以上，最嚴重的就是導致客源流失！所以資料結構設計就必須拆開。
使用 Redis、MongoDB 都是很好的解決方案！最後 CDN 也是要考慮進來的唷！
PS：可以觀察演唱會訂票、電信商搶購手機等等的系統，當 session 都佔滿時，其他人就會發生無法連線或是連線過久的錯誤訊息對吧，小技巧就是使用 CDN！當 session 佔滿時，全部立即導入到 CDN 去！哈哈哈！這是偷雞啦！
以上心得與您分享！
這題的提問方法不對, 問錯問題, 導致沒有辦法精準的回答..
樓主可能會覺得:
上面的回答, 好像講了答案, 卻又對你沒用, 搔不到癢處....這不是他們答得不好, 而是您的問法, 制約了回答的方向, 導致所有的回答, 都沒有解決你的問題....
在樓主這個階段, 其實不應該直接來問解決方案, 而是要先問: 如何增加你的系統可視度 (Visibility)? 沒有可視度, 看不見 inside, 任何解決方案都只是瞎猜, 亂槍打鳥....
如果一位中醫沒把過脈也沒見過你（沒有望聞問切的 inside 資訊）, 光憑別人轉述：發燒＋頭痛（只有病人陳述的表徵現象）, 然後就要開處方給你, 你覺得這樣能對症下藥的機率有多高？....
我在樓主的描述中, 沒看到任何具體的效能數據與測試方法, 在這種狀況下, 解決方案會變得非常多樣多變, 因為我們不知道: 哪一種才適合用在你的環境中？請試著提供一些具體的數據, 大家才能有具體的建議方向.....
有興趣可以看看這篇(不過也是 inside 資訊不足)：每日千人之主機與程式處理？
看這個 ID 的發問紀錄就知道問題在哪了XD
數據控???
有時候效能的瓶頸點是一關卡一關的，解決CPU的問題，IO問題就出現，然後解決IO問題又出現network connection，然後搞CDN...
一下和老闆說這個不夠，花了錢又說那個要加，理由是當初數據沒有顯示出來問題，老闆聽到這樣的說法不氣死才怪！
當然不是用樓上那種頭痛醫頭的方法...
建立 Visibility 只是第一步, 接下來, 你要先設計好未來的 Scale-out 架構, 然後用這個架構建立一個 Lab, 在 Lab 內先做壓力測試, 目的是取得整個架構的 Baseline (基準線)...
取得 Baseline 之後, 開始對你的架構進行 分階段的 Scale-out 然後壓測, 同樣根據壓測結果進行調整, 這時可以一起把 CPU/RAM/Disk/Traffic 全部都調好, 不是來一個調一個....調到可以通過壓測之後, 計錄下當時的數據....
同法繼續 Scale-out 5~10次, 你就會得到 5~10 組數據, 裡面分別有: CPU/RAM/Disk/Traffic...等等參數, 而且你會發現各參數 Scale-out 時的趨勢, 例如: Disk 可能爬很快/CPU沒上升多少/RAM可能用很兇....等等之類的, 這些趨勢可以讓你對以上各種資源, 建立一個方程式, 讓你能夠預測:
1000人時, CPU/RAM/Disk/Traffic該用多少?
5000人時, CPU/RAM/Disk/Traffic該用多少?
1萬人時, CPU/RAM/Disk/Traffic該用多少?
...
你甚至可以透過線性迴歸, 找出某幾個變因的相依性....
當然, 以上不會是線性或長期不變的, 當系統擴展到某個程度之後, 數據就會失真, 你的預測會失敗. 但是, 那應該已經是距離現在很久一段時間了....也就是說, 從上述方法建立起來的一套預測模型, 應該足夠你維持某段長時間的業務成長, 而在這個成長過程中, 你又可以爭取更多時間來做更大的預測模型....
所以, 不是看一個數據到頂了, 才跟老闆要一次錢, 而是:
至少做完3年的預測, 讓老闆知道未來三年他要花的錢是多少 (當然, 你這個模型也要隨時間和業務的變化, 隨時修正上述金額); 絕對不是: 當每一個瓶頸出現了, 才臨時來要一次錢, 這樣老闆當然會把你丟出去...
建立預測模型是企業永續營運很重要的一環, 大部分 IT 人員沒有受過這樣的訓練, 自以為預測不可行, 或是結果不可靠. 可是一家上市規模的公司, 財務預測的準確度必須在 90% 以上, 否則就要發布重大訊息通知資本市場; 如果 IT 部門無法做出準確度 90% 以上的預測, 其實很難在上市公司內生存...
如果你的預測能力可以達到 90% 以上的話, 其實只要在年度預算中, 準備 10~20% 的備用資源, 萬一預測失準的時候, 讓備用資源上場, 就可以解決你的問題, 不需要一直去要錢....
很常見的做法 是把 web server 跟 DB server分開 因為 這是兩個完全不同性質的 server
只需要修改網頁中 DB 連線設定即可
之後網站優化，或是server 效能提升 都可以 輕鬆很多
畢竟 web server 和 DB server 對硬體的需求不太一樣
另外 和 apache 和nginx 相比，nginx 在效能、附載上 有更好的表現
iThome鐵人賽
看影片追技術