可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知可擴充套件模式及個人偏好為標準。本文列出了十大大家耳熟能詳的可擴充套件性架構，以供借鑑。
【51cto精選譯文】對於大多數架構師而言，「可擴充套件性」在軟體架構方面是最虛無縹緲的說法。這毫不奇怪，因為可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知可擴充套件模式及個人偏好為標準。簡單來講，打造一套具備可擴充套件性的系統已經變得更像是一門藝術而不單單是技術。
我們常常會通過觀摩傑作體會並學習藝術的精髓，而可擴充套件性也應該遵循同樣的路線！
在這篇文章中，我將列出數款為大家所耳熟能詳的可擴充套件性架構。通常情況下，架構師們完全可以借鑑已知的可擴充套件架構模式，進而創造出新的可擴充套件架構。
lb (負載平衡器) + 無共享單位 - 該模型中包含一系列單元，各單元彼此間不共享任何內容，且一致指向乙個將輸入文訊按一定條件發往單元處的負載平衡器（這構成乙個迴圈，以負載等情況為基礎）。每個單元可以是乙個單獨的節點或是緊密耦合的節點所構成的集群。使用者可以使用dns迴圈、硬體負載平衡器或者軟體負載平衡器達成負載平衡效果。建立一套負載均衡的層次結構，並在其中結合前面提到的各種負載平衡器也是可行的。在由michael stonebraker撰寫的《 無共享體系架構例項 》一文中，專門討論了此類架構。
lb + 無狀態節點 + 可擴充套件儲存 - 傳統的 三層式web架構 使用的就是這種模型。該模型包括數個與可擴充套件儲存互動的無狀態節點以及乙個分布於節點間負載中的負載平衡器。在這一模型中，儲存通常作為限制因素存在，但nosql儲存則可以利用這套模型建立出具備相當可擴充套件性的系統。
點對點架構 (分布式hash列表 (簡稱dht)以及內容定址網路(簡稱can)) -這套模型提供了一些傳統的可擴充套件演算法，這些演算法的各個方面幾乎全部按對數進行了等比例增加。舉例來說，像chord、pastry（特指免費版）以及can都屬於此類。而以cassandra為代表的、基於p2p架構的幾款nosql系統也是其中的成員。《 展望p2p系統中的資料 》一文就深入**了這類模型的各種細節。
分布式佇列 – 這種模型以將佇列實施（即先進先出交付機制）作為網路服務處理為基礎。該模型通過jms佇列而廣泛得到採用。一般會遵循這種做法的有任務佇列以及通過保持佇列分級體系實現擴充套件性的任務佇列版本，後者在負載無法及時處理時，任務會由低階層面向高階層面傳遞。
小道訊息與自然靈感式模型 - 這種模型源自日常生活中小道訊息的傳播途徑，也就是每個節點將隨機選擇後續節點以交換資訊。正如現實生活中的實際反饋，這種八卦型演算法在資訊傳播方面出奇地迅速。該模型的另一大分支則是受到生物學影響的啟發式演算法。自然世界中存在著大量協調及擴充套件方面極為卓越的固有演算法。舉例來說，螞蟻、人類以及蜜蜂等等，都能夠以最簡潔的交流方式協調好擴充套件性方面的需要。模型中的演算法正是借鑑了這些實際存在的現象。在**《 從流行病的蔓延到分布式計算 》中對這種模型有著詳盡的敘述。
地圖縮小/資料流 - 這一概念首先由谷歌公司提出，地圖縮小為工作的描述及執行提供了一套可擴充套件的模式。雖然內容簡單，但它仍然成為聯機分析處理方面的首要處理模式。資料流則是一種更先進的方式，用來表達執行資訊；而像dryad及pig這樣的專案為資料流的執行提供了可擴充套件的框架。**《 地圖縮小：大型集群上的簡化資料處理 》中設定了專門的主題，詳細討論這一內容。apache的hadoop就是這種模型的代表性產品。
責任樹形圖 - 這種模型打破了遞迴問題的束縛，將整個流程以樹狀形式加以處理；每個父節點將工作下放至子節點。這種模型擴充套件性強，並已經被應用於數款可擴充套件性架構當中。
流處理 - 這種模型被用於處理源源不斷的資料流及資料。這種處理方式通過網路中的處理節點獲得支援（例如aurora、twitter strom以及apache s4等）。
可擴充套件儲存 – 該模型的應用範圍從資料庫、nosql儲存、服務註冊到檔案系統都有體現。 鏈結中的這篇文章 以可擴充套件性為切入點對其進行了深入討論。
綜上所述，可擴充套件性的實現只有三種方式，即：分布、快取及非同步處理。前文所提到的各種架構事實上都是把這三種方式進行不同組合並加以實施。而另一方面，不利於可擴充套件性的因素，除了糟糕的編碼本身，全域性性協調也起到了重要的影響。簡單來說，任何一種全域性性協調都會限制系統的可擴充套件性。本文中所提到的各種架構也只是在做好了本地性協調，而非全域性性協調。
然而，將它們有機地結合起來以建立一套極具可擴充套件性的架構可不像說起來那麼容易，除非我們能找到一種全新的擴充套件模式。不過經驗告訴我們，比起搞一套全新的架構，採用為我們所熟知且更易駕馭的可擴充套件性解決方案永遠是更好的選擇。
架構師不可不知的十大可擴充套件架構
對於大多數架構師而言，可擴充套件性 在軟體架構方面是最虛無縹緲的說法。這毫不奇怪，因為可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知...
架構師不可不知的十大可擴充套件架構
對於大多數架構師而言，可擴充套件性 在軟體架構方面是最虛無縹緲的說法。這毫不奇怪，因為可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知...
架構師不可不知的十大可擴充套件架構
可擴充套件性正是如今軟體設計領域最值得優先考慮的要素。然而，計算機科學家們還無法了解一套單獨的架構如何才能擴充套件至各類應用環境當中。相反，我們在數量繁多的方案中所設計出的可擴充套件性架構，往往以業界較為通用的已知可擴充套件模式及個人偏好為標準。本文列出了十大大家耳熟能詳的可擴充套件性架構，以供借鑑...