需要拆分主數(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小時。由于這個服務被設計為單一應用的附加功能， 所以不能在多個服務器上運行。直到現(xiàn)在，這個6個月之前所做決策的后果才逐漸顯現(xiàn)出來。AllScale公司的運營團隊必須給這個應用分配一個更大的服務器才能完成下個月的結(jié)算工作，而這個服務器原本是計劃用作數(shù)據(jù)庫服務器的。當然，這也會對硬件預算產(chǎn)生不好的影響。運營團隊還需要花費大量的時間為這次遷移進行服務器的監(jiān)控、準備、配置和測試。此外，這個項目可能還會引人軟件開發(fā)工程師和質(zhì)量保證工程師，以對變更提出建議，并最后驗證該應用能夠在新服務器上運行。由于這個置換新硬件的項目對用戶而言的高風險，它必須在維護的時間窗內(nèi)進行，同時它也用去了這一周系統(tǒng)允許的風險的大部分。另外的數(shù)據(jù)庫拆分的項目則必須推遲了，因為需要訂購新的硬件才行了，這樣增加了數(shù)據(jù)庫過載而造成問題的風險。
從我們的例子中你會發(fā)現(xiàn)，最初的網(wǎng)站制作功能開發(fā)階段所做的決策會給整個系統(tǒng)的可擴展性帶來許多未知的影響。這是否意味著當初的權(quán)衡和決策是錯誤的呢?不，事實上，即使有后見之明，你仍然會覺得迅速地把這個功能投人到生產(chǎn)環(huán)境中，是個正確的決定。對于這個場景，我們大概同意這種看法。從這個例子中我們學到的重要點， 不是個決策是對還是錯， 而是對于一個決策會造成長期和短期的后果，你可能不能完全了解。
本文地址：http://knowyourextract.com//article/3862.html
