那么這些關(guān)于成本、質(zhì)量、速度和范圍的權(quán)衡決策是如何影響系統(tǒng)的可擴展性呢?正如上一章提到的，對于擴展項目或基礎(chǔ)設(shè)施項目來說，可擴展性與這些權(quán)衡之間有著簡單明了的關(guān)系。而對于開發(fā)功能的項目來說，這些約束的權(quán)衡決策從長期來看會影響該功能和整個系統(tǒng)的可擴展性，這是權(quán)衡決策與可擴展性之間的間接關(guān)系。

需要拆分主數(shù)據(jù)庫的擴展項目，就像一個開發(fā)功能的項目一樣，也需要平衡這四個約束因素。你會把自已大部分的高級工程師從開發(fā)功能的項目中抽調(diào)出來，從事拆分數(shù)據(jù)庫的項目嗎?你會給自己的團隊6個月或18個月時間來完成這個項目嗎?你會加人內(nèi)置的功能，從而在必要的時候進一步拆分數(shù)據(jù)庫嗎?你會縮短項目，只進行一一次拆分嗎?這些都是你在項目過程中需要提出的問題，也是為了平衡項目三角中的速度、成本、質(zhì)量和范圍而提出的問題。

這些約束因素還會間接地影響可擴展性。讓我們以AllScale公司的付款功能為例，它的側(cè)重點在于速度。這個功能必須在月底之前發(fā)布，這樣才能供月底的結(jié)算周期使用。錯過了這個日期，就會造成需要手工處理付款，這樣會引人更多錯誤，從而導致拒付和收人損失。軟件開發(fā)團隊的VP麥克，索福特從另一個項目上抽調(diào)了三位高級工程師，把他們分配到這個付款項目上，以便能夠按時完成它。一切都進展得很順利，在月底之前的那個周末，這個功能就被發(fā)布了，這樣就能夠根據(jù)計劃處理賬單。

6個月后，AllScale公 司的HRM站點存儲的內(nèi)容的增加量超過了100%，而參與月底結(jié)算周期的用戶數(shù)量增加的百分比更大，他們在結(jié)算功能上產(chǎn)生的負載總量接近這個功能發(fā)布初期的負載總量的150%。迄今為止，它的處理時間仍然控制在12小時之內(nèi)。但這個月的用戶增長使它發(fā)生了明顯的變化，處理時間一躍達到了38小時。由于這個服務(wù)被設(shè)計為單一應(yīng)用的附加功能， 所以不能在多個服務(wù)器上運行。直到現(xiàn)在，這個6個月之前所做決策的后果才逐漸顯現(xiàn)出來。AllScale公司的運營團隊必須給這個應(yīng)用分配一個更大的服務(wù)器才能完成下個月的結(jié)算工作，而這個服務(wù)器原本是計劃用作數(shù)據(jù)庫服務(wù)器的。當然，這也會對硬件預(yù)算產(chǎn)生不好的影響。運營團隊還需要花費大量的時間為這次遷移進行服務(wù)器的監(jiān)控、準備、配置和測試。此外，這個項目可能還會引人軟件開發(fā)工程師和質(zhì)量保證工程師，以對變更提出建議，并*后驗證該應(yīng)用能夠在新服務(wù)器上運行。由于這個置換新硬件的項目對用戶而言的高風險，它必須在維護的時間窗內(nèi)進行，同時它也用去了這一周系統(tǒng)允許的風險的大部分。另外的數(shù)據(jù)庫拆分的項目則必須推遲了，因為需要訂購新的硬件才行了，這樣增加了數(shù)據(jù)庫過載而造成問題的風險。

從我們的例子中你會發(fā)現(xiàn)，*初的網(wǎng)站制作功能開發(fā)階段所做的決策會給整個系統(tǒng)的可擴展性帶來許多未知的影響。這是否意味著當初的權(quán)衡和決策是錯誤的呢?不，事實上，即使有后見之明，你仍然會覺得迅速地把這個功能投人到生產(chǎn)環(huán)境中，是個正確的決定。對于這個場景，我們大概同意這種看法。從這個例子中我們學到的重要點， 不是個決策是對還是錯， 而是對于一個決策會造成長期和短期的后果，你可能不能完全了解。