轉自：http://www.itivy.com/ivy/archive/2011/11/24/something-that-architecture-must-be-aware-of.html

對于大多數架構師而言，“可擴展性”在軟件架構方面是最虛無縹緲的說法。這毫不奇怪，因為可擴展性正是如今軟件設計領域最值得優先考慮的要素。然 而，計算機科學家們還無法了解一套單獨的架構如何才能擴展至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴展性架構，往往以業界較為通用 的已知可擴展模式及個人偏好為標準。簡單來講，打造一套具備可擴展性的系統已經變得更像是一門藝術而不單單是技術。

我們常常會通過觀摩杰作體會并學習藝術的精髓，而可擴展性也應該遵循同樣的路線！

在這篇文章中，我將列出數款為大家所耳熟能詳的可擴展性架構。通常情況下，架構師們完全可以借鑒已知的可擴展架構模式，進而創造出新的可擴展架構。

1. LB (負載平衡器) + 無共享單位 - 該模型中包含一系列單元，各單元彼此間不共享任何內容，且一致指向一個將輸入文訊按一定條件發往單元處的負載平衡器（這構成一個循 環，以負載等情況為基礎）。每個單元可以是一個單獨的節點或是緊密耦合的節點所構成的集群。用戶可以使用DNS循環、硬件負載平衡器或者軟件負載平衡器達 成負載平衡效果。創建一套負載均衡的層次結構，并在其中結合前面提到的各種負載平衡器也是可行的。在由Michael Stonebraker撰寫的《 無共享體系架構實例 》一文中，專門討論了此類架構。
    
2. LB + 無狀態節點 + 可擴展存儲 - 傳統的 三層式Web架構 使用的就是這種模型。該模型包括數個與可擴展存儲交互的無狀態節點以及一個分布于節點間負載中的負載平衡器。在這一模型中，存儲通常作為限制因素存在，但NoSQL存儲則可以利用這套模型創建出具備相當可擴展性的系統。
    
3. 點對點架構 (分布式Hash列表 (簡稱DHT)以及內容尋址網絡(簡稱CAN)) -這套模型提供了一些傳統的 可擴展算法，這些算法的各個方面幾乎全部按對數進行了等比例增加。舉例來說，像Chord、Pastry（特指免費版）以及CAN都屬于此類。而以 Cassandra為代表的、基于P2P架構的幾款NoSQL系統也是其中的成員?！?nbsp;展望P2P系統中的數據 》一文就深入探討了這類模型的各種細節。
    
4. 分布式隊列 – 這種模型以將隊列實施（即先進先出交付機制）作為網絡服務處理為基礎。該模型通過JMS隊列而廣泛得到采用。一般會遵循這種做法的有任務隊列以及通過保持隊列分級體系實現擴展性的任務隊列版本，后者在負載無法及時處理時，任務會由低級層面向高級層面傳遞。
    
5. 發布/訂閱模式 - 一般用于通過網絡向彼此發布訂閱訊息?！?nbsp;發布與訂閱的多面性 》這一經典論文中詳細的介紹這一模型，該模型方面最典型的例子即 NaradaBroker與 EventJava 。
    
6. 小道消息與自然靈感式模型 - 這種模型源自日常生活中小道消息的傳播途徑，也就是每個節點將隨機選擇后續節點以交 換信息。正如現實生活中的實際反饋，這種八卦型算法在信息傳播方面出奇地迅速。該模型的另一大分支則是受到生物學影響的啟發式算法。自然世界中存在著大量 協調及擴展方面極為卓越的固有算法。舉例來說，螞蟻、人類以及蜜蜂等等，都能夠以最簡潔的交流方式協調好擴展性方面的需要。模型中的算法正是借鑒了這些實 際存在的現象。在論文《 從流行病的蔓延到分布式計算 》中對這種模型有著詳盡的敘述。
    
7. 地圖縮小/數據流 - 這一概念首先由谷歌公司提出，地圖縮小為工作的描述及執行提供了一套可擴展的模式。雖然內容 簡單，但它仍然成為聯機分析處理方面的首要處理模式。數據流則是一種更先進的方式，用來表達執行信息；而像Dryad及Pig這樣的項目為數據流的執行提 供了可擴展的框架。論文《 地圖縮小：大型集群上的簡化數據處理 》中設置了專門的主題，詳細討論這一內容。Apache的Hadoop就是這種模型的代表性產品。
    
8. 責任樹形圖 - 這種模型打破了遞歸問題的束縛，將整個流程以樹狀形式加以處理；每個父節點將工作下放至子節點。這種模型擴展性強，并已經被應用于數款可擴展性架構當中。
    
9. 流處理 - 這種模型被用于處理源源不斷的數據流及數據。這種處理方式通過網絡中的處理節點獲得支持（例如Aurora、Twitter Strom以及Apache S4等）。
    
10. 可擴展存儲 – 該模型的應用范圍從數據庫、NoSQL存儲、服務注冊到文件系統都有體現。 鏈接中的這篇文章 以可擴展性為切入點對其進行了深入討論。

綜上所述，可擴展性的實現只有三種方式，即：分布、緩存及異步處理。前文所提到的各種架構事實上都是把這三種方式進行不同組合并加以實施。而另一方 面，不利于可擴展性的因素，除了糟糕的編碼本身，全局性協調也起到了重要的影響。簡單來說，任何一種全局性協調都會限制系統的可擴展性。本文中所提到的各 種架構也只是在做好了本地性協調，而非全局性協調。

然而，將它們有機地結合起來以創建一套極具可擴展性的架構可不像說起來那么容易，除非我們能找到一種全新的擴展模式。不過經驗告訴我們，比起搞一套全新的架構，采用為我們所熟知且更易駕馭的可擴展性解決方案永遠是更好的選擇。