可伸縮性Web服務的指導原則
可伸縮性Web服務關注性能優化,但一味注意優化也并非是其關鍵所在。Tom Killalea,Amazon負責基礎設施與分布式系統的技術副總裁在近期的ACM queue上發表了一篇關于構建可伸縮性Web服務的文章。 他概述了構建可伸縮性Web服務的指導原則并舉了許多現實世界的實際案例,其核心主題是“只構建你所需要的”。
警惕:過早優化
花費在優化可伸縮性上面的時間和資源不如花費在改進用戶體驗和吸引流量上。
采納:他人的成果
他解釋到,學習他人在框架與基礎設施方面的工作可以減短上市時間,幫助將重點轉移到提供客戶價值上。
三個重要的進展從不同的方面對降低門檻作出了貢獻:邁向SOA的趨勢(面向服務的架構),云計算基礎設施服務的涌現,以及ASP.NET,Django,Rails和Spring等等Web應用框架的可用性。
警惕:過度優化
他引用了Nicholas Nassim Taleb在高度非概然性不可測事件所產生的重大影響方面所做的工作,并建議使用冗余作為提高可用性的策略;使用冗余作為負載平衡而不僅僅是故障恢復機制這一想法比起對于低概率的可能性事件進行過度優化來說,顯然更加有成本效率。
采納:云
Tom給出了Animoto的例子,這一通過Amazon.com的EC2基礎設施托管的社交Web應用是如何隨需應變的快速平面伸縮(scale out)的,甚至擴展到3500個實例。同樣的情況在非云的基礎設施里,為了保證尖峰時刻的流量將會花費巨大的成本。
警惕:目標驅動的優化
對于期望的流量進行建模然后構建精確的伸縮性計劃以滿足這一目標是***風險的。好的模型難于構建,并且會因為簡化或者是降低變因的樂觀估計而受到影響。[…]如果你的Web服務是成功的,你最終會遇到比目標模型更大的需求——也許不是這個黑色的星期一或者超級碗周末,但有可能是很快以后,在你所沒想到的時間范圍內。
采納:扯下翅膀
“除了分析哪部分會***個出問題以及其原因以外”,Tom談到“我們會查看給定的應用或者服務在沒有出問題或缺少這部分的情況下會有怎樣的表現,并且重新進行測試,以找下一個出問題的部分”。
Tom這樣總結了他的文章“構建一個可伸縮的Web服務所面臨的最困難的挑戰就是在出現故障以及高度的并發訪問械的情況下,如何去處理持續性,可靠性,性能以及成本效率之間的折衷。”。
除了Tom的這篇文章,2008年10號還有其它的關于構建可伸縮性Web服務的精彩文章。
【編輯推薦】