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



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

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

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

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