Software scalability

一個網站在受到歡迎之前
通常不須要考慮太多的技術上如何最佳化的問題
如果一個網站一天有五萬個人點閱
在個人網站來說 可能算是還不錯的規模了
可是粗估一下流量也不過是一秒兩三個request罷了
所以在這種程度的service 通常其實只要一臺電腦跟好一點的頻寬 就可以支撐起大部份的服務了
而其實可能有九成的小網站或是小部落格 都是某人桌底下的一台低調的server而已

可是如果你是想設計google或是yahoo這種入口型的的網站
如何有效率的從有限的硬體裡頭 榨出更高的request/second 就變的非常重要
這個問題 可以分析的切入點有很多
我主要是講的部份是如何切割你的系統以承受更高的使用量
在網站突然開始流行的年代 有一派人的想法其實只是用更強大的硬體規格解決量的問題
這其實也是一種不錯的方案
這個方案的好處是非常的簡單 就是花錢買最好的機器
如果當年的個人電腦 只能承受每秒100個request 而我業務上的需求如果需要500-1000 request/second
那我就用很貴的經費買最佳化過的硬體跟compiler 也就是類似超級電腦或工作站的機器
軟體都不需要修改 只要把程式放到最好的機器上 問題就解決了
反正當我業務成長到某個階段的時候 又會有更好的硬體出現 可以解決網站效能的問題
這個方式好處是相對來說軟體的設計簡單 複雜的是硬體如何最佳化的設計
但是缺點是很貴 在PC一臺只要五萬台幣的年代 一台工作站軟體加硬體合起來
幾百萬甚至上千萬有時候是跑不掉的
不過這也是現在很多銀行所使用的方式
銀行後台很多所謂的IBM的大型主機 其實也就是一臺很穩定很強大但是也很貴的機器

不過在網路泡沫化之後 這種燒錢的方案 慢慢的比較不受歡迎了
另外的一個因素也是因為現在的PC 效能也不可同日而語了
現在的PC 記憶體也是好幾G CPU不只一顆
所以現在所看到的大型網站的機房 其實大部份都是上百上千台的PC組成的
像我所熟悉的電子商務網站來說好了
看起來就是一般的網站 可是後台 其實有上百台機器相互串聯合作所組出來的服務
如何將網站的功能平均的分散到這些PC上 就是軟體的設計與架構了
不過這個方案 以成本來算的話 若硬體成長十倍也表示購買PC的預算要多十倍
中間還有機器每個月多消耗十倍的電能 十倍的機房空間
還有更多硬體可能壞掉要維修的維護成本
像google 那種規模的機房 平均一天都幾顆硬碟故障或是機器要重開維護也是很平常的
所以中間的取捨也是設計要考慮的因素


不過我們以第二種 軟體的設計解決量的問題 通常就會碰觸到分散式設計的概念
通常這個分散設計的方式可以分成兩種
一種是橫的把網站分成很多的子系統
另一種就是把一個系統 切成許多的一樣的farm

如何將網站分成許多的子系統
如果兩個子系統之間是獨立不互相關連的存在的
那這兩個系統 就可以存在於兩組不同的機器上
當然也就可以把相同的loading 交給更多的機器處理
如果你可以把一整個網站的功能 切成10個獨立的子系統
那最樂觀的狀況 可能就表示你的網站可以承受的量 是原本沒有切割前的10倍左右
現實的狀況當然會有某個子系統可能是所謂的瓶頸 也就是bottle neck
不過通常效能提升個三五倍通常不是問題

另一種就是把同一個服務不同客戶的資料放在不同的機器上
也就是分farm的概念
像一些有名的blog 雖然資料很多量也很大 不過不同的user之間 其實沒有太大的關連性
所以我們就可以所有的user分成N等分 等分到N組的機器上
而每一組的機器都是必須有完整的功能
所以假設我們一組機器可以服務一百萬個使用者 那五百萬個使用者就是把系統切成五組farm
當系統又成長到一千萬的時候 我們只要繼續加機器就可以解決

待續...