自己開發元件是件有趣又刺激的任務,看著自己生出來的元件被廣泛地應用在大小專案上,簡化了原本繁瑣的Coding工程,那份成就感與驕傲猶如坐在台下目送兒子女兒上台領市長獎一般。(女兒跟兒子呀,雖然你們還沒上小學,但也不要成天光看雙胞胎公主跟巧虎,知道怎麼讓老爸開心吧?)

當元件愈散愈廣,用的人愈來愈多,會開始冒出一些挑戰。開發人員應用元件的創意,漸漸超出你的想像。(就像味全永遠想不到它出的果汁牛奶最後會變成維士比的麻吉,撫慰了無數勞工朋友的心) 但這種意外的搭配不純粹只有光明面;另外一些場合,開始有人抱怨你的元件怎麼少了一些功能,而那些功能是你壓根沒想過的應用方法。好比你設計了一支吃魚子醬專用的翡翠雕花銀湯匙,最後竟被拿來挖土種花,還不時有人幹譙"是哪個豬頭沒事設計成這麼小支?"... orz

功能與目的上的差異至少是顯而易見的,另一種隱性差異就有點像不定時炸彈。Performance Tuning是門高深的學問,程式"能用"跟"容納上千人同時使用"常常是兩回事,在許多情境下,甚至元件必須砍掉重練才能在高使用量下存活。當初開發元件時,或許只針對十幾人小部門的系統運作,一切求簡求快,殺雞當然不該揮牛刀,這樣的考量合情合理。別人覺得這顆元件好用,開始拿到各個新專案使用,漸漸地,元件應用的方式及應用網站的規模超出原開發者的想像,求簡求快的寫法對數十個Concurrent User的情境綽綽有餘,但被上千人同時呼叫,卻可能瞬間癱瘓DB,造成一場災難。

這是誰的錯?? 坦白說,我不知道。元件被應用在非當初考量的情境才導致問題,不是針對高負載設計的元件,在開發時根本不會想到做壓力測試、更遑論可提供多少人使用、要用多快的CPU、多大的RAM這類Capacity Planning的參考數據。元件的抗壓性,在非高負載型元件的開發生命周期中,常常是模糊的、易被忽略的,我說不出來這是開發者或應用者的缺失。

對於這個棘手的問題,我有個點子。寫程式久了,應該都知道參考文件上會註明某個Method是否為Thread-Safe;也就是說,在多執行緒下使用它會不會出亂子。久而久之,所有Method都會主動註明Thread-Safe or Not已成慣例,多執行緒程式的開發者,也都知道在使用前先搞清楚,Is it thread-safe?

相同的,當你要寫一個高負載的系統,在使用元件前,也該先問一句,Is it load-safe? 很不幸地,我們可以透過一些Lock技巧確保Thread-Safe,卻難以明確的數字衡量元件是否夠力夠堅強,但至少詢問Load-Safe可以提醒應用者與開發者正視"元件抗壓性"這個議題,以免元件變成系統中最脆弱的一環。我想得到可以檢視元件抗壓性的方法,似乎只有查看SD文件(如果有的話)、Code Review(如果看得懂的話)或實際進行壓力測試,雖然工程都不小,但至少會讓我們對系統的抗壓性更有信心,防止因為元件而崩盤的悲劇。

設計一個高負載系統時,記得要想一想,你所使用的自製元件,是否都Load-Safe?

【圖說】金門大橋兩條直徑一公尺的主鋼纜是由27,512根1公分的組合而成,因此,要加大抗壓性,並非一昧加粗纜徑,而需透過特別的設計才能確保其強韌度,元件設計亦然!


Comments

Be the first to post a comment

Post a comment


27 + 10 =