2009-07-06 131 views
3

天兒真好,是否可以將可擴展性量化爲一項要求?

我正在讀的項目Quantify書中「97件事每一個軟件架構師應該知道」(sanitised Amazon link),它讓我知道如何量化的可擴展性。

我設計了兩個系統的主要英國廣播公司被用於:

  1. 檢測原產國傳入的HTTP請求,或
  2. 確定合適的視頻格式的手機屏幕幾何圖形和當前連接類型。

這兩個設計被要求提供可擴展性。

我對兩個系統的設計是可擴展的水平落後,其用於處理用於這兩項服務的傳入請求,並將在幾個服務器實際上提供服務本身分配緩存負載平衡層。服務容量的初始增加是通過在負載平衡層後添加更多的服務器來實現的,因此稱爲水平可伸縮性。

有該架構然而,如果負載平衡層開始具有難度與傳入請求通信應對的可擴展性限制。

那麼,是不是可以量化的可擴展性?是否可以估算您可以添加多少個額外服務器來橫向擴展解決方案?

回答

2

我認爲在某些情況下是可能的 - 例如,Web應用程序的可擴展性可以根據用戶數量,併發請求數量,響應時間的平均值和標準偏差等進行量化。您也可以進入帶寬和存儲的通用數字,每秒交易次數和恢復時間(用於備份和DR)。

你也可以經常給應用領域內的數字 - 假設系統支持評論,你可以量化的是評論的數量的大小,它需要能夠存儲的順序。

然而值得銘記不是問題可以衡量一切,可以測量的問題不是萬能的。 :-)

3

我認爲這歸結於什麼可擴展性是指一個給定的情況下,因此答案是這取決於

我在東西根本還不存在需要看到的可擴展性。例如,一個新的貸款申請工具,特別是未來需要在iPhone和其他移動設備上工作。

我也看到了用來描述世界不同地區的多個數據中心和網絡服務器的擴張潛力,以提高性能的可擴展性。

這兩個例子,如果有對未來的已知的目標以上即可量化。但是,如果沒有已知的目標或計劃使其成爲移動目標,則可擴展性可能無法量化。

+1

啊,「必須是未來的要求」! ( - : – 2009-07-06 16:19:59

1

的可擴展性(的適當措施不是簡單的一個;-)是一組曲線定義資源要求(CPU,內存,存儲,本地帶寬,...)和性能(如延遲)交付,作爲負載增長(例如,按照每秒查詢數量計算,但其他度量,例如所需的總數據吞吐量也可能適用於某些應用程序)。決策者通常會要求將這些準確但複雜的測量數據歸結爲幾個關鍵數字(幾條曲線中的某些曲線上的特定點),但我總是試圖進行更精確的談判,而不是更簡單易懂的測量。關鍵指標! - )

1

當我想到的可擴展性,我認爲的:

  • 性能 - 應用程序如何響應需要爲給定負載
  • 多大的負載應用程序可以長入並在什麼單位成本(如果每臺服務器包括軟件,支持等)
  • 你能多快擴展你想在高峯期使用的應用起來,多少緩衝(我們可以在2-3小時內添加更多的50%的帶寬,需要在計劃的峯值使用情況下爲30%的緩衝區)

冗餘是另一回事,但也應該包括和考慮。

1

「系統應根據成本/用戶比例保持X的線性關係」。