我們公司的重點是幫助客戶實現他們的擴展性需求，也許你可以想到，經常會有客戶這樣問:“我們應該何時對可擴展性進行投資?”不必經過大腦的答復是應該在需要該解決方案的前一天投資(部署)如果你能夠在需要擴展解決方案的前一天部署它，那么就會讓投資行為“即時”發生，恰到好處，從而像 Dell/公司那樣按需生產。這樣做，會使你的公司效益和股東權益最大。
不過我們要面對的問題是，讓投資和部署成為即時的是不可能的，即使可能，如果沒有選對時機，也會帶來很大的風險。退而求其次，部署擴展性方案的最好方法是 AKF Partners的設計一實現一部署(Design-implement-deploy)方法，即D- I -D方法。這三個階段與我們認識事物的三個階段一致，即針對問題思考和設計解決方案、構建或編寫該解決方案、實際地安裝或部署它。這種方法不提倡也不需要瀑布模型。
我們認為敏捷方法正是遵循的這個過程，體現了人的主觀能動性。人們不會為還沒有注意到的問題開發解決方案，而一個方案，如果還沒有開發出來，也不可能被制造或發布出來。無論開發的方法是什么(敏捷模型、瀑布模型、混合模型等)，開發的任何東西都需要基于一套成體系的理論和標準，它們定義并指導著我們該做什么。
1.設計
首先要說的是，討論和設計什么東西，比真正用代碼實現這一設計的投人少得多。考慮到設計的成本較低，那么在實際需要之前，可以討論并草擬出能夠使平臺具有高擴展性的設計。但是，顯然我們并不想在生產環境中投人比實際需要多10倍、20倍或者100倍的容量，關于如何將容量擴展到這種水平的討論相對來說成本小得多。那么，在D- I -D擴二展模型的設計(Design)階段，重點就在于如何將平臺的容量擴展到2倍以上，甚至到無窮大。我們的腦力成本是相當高的，因為需要雇傭“大思想家”來考慮“大問題”。但是編程成本和資產成本卻是很低的，因為我們并沒有編寫代碼，也沒有部署系統。由小組的領導者和程序員參與的討論擴展性問題的大會，能讓人發現在D- I -D方法的設計階段有哪些地方是必須擴展的。
2.實現
隨著時間的流逝，我們所預見的對擴展性的需求就會臨近，這日時就需要在軟件中實現(Implement)我們的設計了。我們要根據實際需要，把擴展的范圍縮小，例如擴展到當前大小的3-20倍。這里使用“大小”這個詞，指的就是被認為是系統擴展的最大瓶頸，因此極需要進行可擴展性修改的元素。也許存在這樣的情況，即把系統擴展到當前大小的100倍(或更高)所需的成本和擴展到20倍的成本一樣，那么我們還不如一次完成這些修改，而不是分成多次來做。在X對用戶需求進行模塊化，把它們分布(或共享)到多(N)個系統和數據庫中時，就可能發生這種情況。我們可以編寫一個變量Cust MOD，隨著時間變遷，可以把它配置為1(當前)到1000(5年后)。這種修改帶來的編程(或實現現)成本不會隨著N而變化，所以我們不如選擇這種方法。這種修改，帶來的是高編程成本、中等的腦力成本(在整個生命周期前期已經討論過設計了)以及低資產成本，因為如果最初階段我們只打算部署1倍或者2倍的模塊，那么當前就沒有必要部署100倍的系統。
3.部署
D-I-D方法的最后階段是部署(Deployment)。仍然用上面介紹的模塊化示例，我們想用即時方法部署系統，沒有任何理由讓資產閑置從而減少股東的收益。如果我們是一個較高速增長的公司，那么可以在生產環境中投入1.5倍的峰值容量。如果是個超高速增長的公司，則可以在生產環境中投人5倍的峰值容量。我們常常告訴客戶，對于爆炸性的容量，要利用“云”，以免備用33%的資產去防范突然的客戶活動增長。在部署階段，需要高資產成本，而其他成本則屬中低水平。這類情況的總體成本趨于最高，部署一個相當于需求的容量100倍的系統，會讓很多公司倒閉。記住，擴展性是個靈活的概念，它可以是擴張，也可以是收縮，而我們的解決方案需要兩方面都考慮到。因此，靈活性至關重要，你可能需要根據客戶需求讓解決方案中的不同系統進行擴張或者收縮。
雖然D-I-D方法的每個階段都有不同的腦力、編程和資產成本，但整體成本卻是基本一致的。關于擴展性的設計和思考成本相對較低，所以應該經常進行。這些活動最好形成文檔，以便當有需求時，程序員就能迅速地根據文檔編寫代碼。將設計好的解決方案編寫(開發)成代碼可以稍后再進行，開發的成本稍高，但是沒必要在生產環境中真正實施它。我們可以像上面的模塊化示例中所述的，修改少量代碼，而無需再購買一個相當于現有容量100倍的系統。最后，采用這種方法，就可以只在有需求時再購買設備，可能是從主要網站建設的設備供應商那里提前6周購買，或者極其緊急的情況下，讓系統管理員去當地的服務器商店采購。
本文地址：http://murenxiang.com.cn//article/3443.html
