重點摘要#

• 應用程式的初始設計是基於當前的業務需求和條件，但未來會變化
• 透過拉伸關鍵維度（用戶量、資料量、交易量等）來找出設計中的隱藏極限
• 在設計還是虛擬的時候重新設計，比上線後再改要便宜得多
• 維度應該單獨拉伸，也要組合拉伸，以找出不同的斷裂點

詳細內容#

一個應用程式的設計最初是基於指定的業務需求、現有技術、預期資料量和可用資源。這個解決方案在當前環境中能夠正常運作，但這只是起點。

拉伸關鍵維度#

取出這個解決方案，拉伸關鍵維度，看看什麼會斷裂。例如：系統變得非常受歡迎、客戶數大增、交易量翻倍、或者資料保留從一週變為六個月。

透過拉伸，架構師可以驗證：

• 基礎設施容量：計畫中的基礎設施是否能容納這些增長？極限在哪裡？
• 處理時間餘裕：每天是否有足夠的時間完成預期的處理量？是否有應對「忙碌日」或故障恢復的餘裕？
• 資料存取方式：保存一週資料時有效的存取方式，在六個月資料量下是否仍然可用？
• 水平擴展路徑：當負載增加時，應用程式如何跨硬體擴展？過渡路徑是什麼？
• 災難復原：如果資料量增加且分散在更多基礎設施上，還能順利復原嗎？

基於這些拉伸測試的結果，可以在設計階段就識別出需要重新設計的部分。在設計還是虛擬的、技術選擇尚未鎖定、業務資料尚未儲存的時候重新設計，成本遠低於上線後再改。

— By Stephen Jones