經過這幾年的積累，在系統架構方面逐漸積累了一些自己的經驗，到今天有必要對這些經驗作個小結。在我的架構思維中，主要可以歸類為三種架構模型：3/n層架構、「框架＋外掛程式」架構、地域分布式架構。
這是經典的多層架構模型，對於稍微複雜一點或特別複雜的系統，不使用分層架構是很難想象的。下圖是經典的3層架構：
如今，凡是個程式設計師都能侃侃而談3/n層架構，這確實是解決系統複雜性的一種主流模式，但是，只要採用了3/n層架構是不是就一定能解決系統的複雜性了？不一定，關鍵在於你在你的系統中如何實作你的3/n層結構。
在採用了3/n層架構後，我們還是要解決以下非常重要的問題：系統的可擴充套件性（能從容地應對變化）、系統的可維護性（因為系統並不是使用一次就被拋棄）、方便部署（在需求變化時，方便部署新的業務功能）、還有等等其它系統質量屬性。然而系統的可擴充套件性和可維護性是大多數軟體系統必須解決的重中之重，這是由於當前需求複雜多變的軟體環境決定的。就像實現功能需求是最基本的，採用3/n層架構也只是萬里長征的第一步。
我採用「框架＋外掛程式」架構來解決與系統的可擴充套件性、可維護性和部署相關的難題。
經典的3/n層架構是對系統進行「縱向」分層，而「框架＋外掛程式」架構對系統進行「橫向」分解。3/n層架構和「框架＋外掛程式」架構處於乙個平等的位置，它們沒有任何依賴關係。
但是我經常將它們結合在一起使用，我們的系統在經過3/n層架構的縱向分層和「框架＋外掛程式」架構的橫向分層後，可以被看作乙個「網格」結構，其中的某些網格可以看作是「擴充套件點」，我們可以在這些擴充套件點處掛接「外掛程式」。也就是說我們可以在3/n層架構的每一層都掛接適當的外掛程式來完成該層的一些功能。如：
外掛程式最主要的特點是可以實現「熱插拔」，也就是說可以在不停止服務的情況下，動態載入/移除/更新外掛程式。所以，採用外掛程式技術可以實現以下功能：
（1）在ui層，我們可以在執行時，替換掉某些使用者介面、或載入與新的業務相關的使用者介面。在業務邏輯層，我們可以在執行時載入、替換或者刪除某項業務服務。在資料訪問層，通過使用外掛程式技術我們可以動態地新增對新的資料庫型別（如mysql）的支援。
外掛程式的「熱插拔」功能使得我們的系統有非常好的可擴充套件性。
（2）如果我們需要公升級系統，很多情況下，只要公升級我們的外掛程式（比如業務外掛程式）就可以了，我們可以做到在服務執行的時候進行外掛程式的自動公升級。
（3）要想將系統做成「框架＋外掛程式」的結構，要求我們需要在系統的各層進行「松耦合」設計，只有松耦合的元件才可以被做成「外掛程式」。
在3/n層架構中融合「框架＋外掛程式」架構，最難的是對業務邏輯層的松耦合處理，這需要我們細緻分析業務需求之間的關聯，將耦合度緊密的業務封裝在乙個元件中，如此得到的相互獨立的業務元件便可以有機會成為外掛程式。這個過程可能需要不斷的重構、設計的重構。
我們知道，相比於那些緊密耦合的元件，松耦合的元件更加清晰明確、更加容易維護。另外，在該架構模型中引入了aop框架進行aspect焦點的集中程式設計（比如處理日誌記錄、許可權管理等方面），使得aspect**不會摻雜在正常的業務邏輯**中，使得**的的清晰性、可維護性進一步增強。
從上述介紹可以看出，採用3/n層架構和「框架＋外掛程式」架構相結合，我們可以增強系統的可擴充套件性、可維護性和簡單部署公升級的能力。
我無意中發明了「地域分布式架構」這個詞，呵呵，不知道意思是否表達得準確。地域分布式架構主要針對類似lbs（基於位置的服務）的需要進行地域分布的應用。 地域分布式架構基於上述的3/n層架構和「框架＋外掛程式」架構，它們的關係如下：
現在我對地域分布式架構作個簡單的介紹。假設我們需要為全國的各個大城市提供我們的業務功能服務，假設每個城市的客戶量很大，而且每個城市訪問的資料可能是不一樣的（如每個城市的地圖資料）、訪問的功能也不盡相同（如有的城市提供天氣查詢服務，而另一些城市不提供）。客戶除了跟我們的系統請求服務之外，可能還想通過我們的系統與他的好朋友進行即時通訊，而它們好朋友可能與他在同乙個城市，也可能位於另外乙個城市。
好了，我們看地域分布式架構是如何解決類似上述的需求的。
首先，地域分布式架構將使用者管理和業務功能服務分開，分別由應用伺服器（as）和功能伺服器（fs）負責，然後將它們部署到不同的節點上。as和fs都採用了3/n層架構和「框架＋外掛程式」架構相結合的架構，比如，fs通過功能外掛程式提供功能服務。
比如，對於武漢這個地域，我們部署了一台as和一台fs，客戶端通過連線到as進行服務請求。假設有一天，我們在武漢的客戶急劇增加，這是壓力最大的是fs，因為所有的業務計算都是在fs上完成的。
這時，地域分布式架構將允許我們在不停止任何服務的情況下，動態的新增fs伺服器，新新增的fs伺服器會自動註冊到as。
as可以監控每個fs的負載（如cpu消耗、記憶體消耗），再有客戶端請求到來時，as會將請求交給負載最低的fs處理，這就實現了fs的負載均衡。
如果client a需要與client b進行即時通訊，那麼這些通訊訊息將通過as中轉。
上面看到的是我們的系統在武漢的部署，而在其他城市部署情況也一樣。
在這種情況下，as和as之間是相互獨立的，但是經常會發生as之間需要相互通訊的情況，比如：client a需要與client e進行即時通訊，或者client a需要請求上海地區獨有的服務，等等。
地域分布式架構使用跨區域的應用伺服器（iras）來解決as之間的通訊問題。所有as在啟動的時候，將自動向iras註冊。
如果，我們想在長沙市也提供我們的服務，那麼我們只需要在長沙部署我們的as和fs，這樣就可以融入到上圖表示的整個地域分布式架構中。
關於地域分布式架構，就簡單的介紹這麼多，更多的內容，讀者可以自己去分析挖掘。
如果沒有自己的一套工具對上述的架構模型作支援，那麼你可能會認為我是在這裡胡扯、夸夸其談。在這幾年的開發中，我積累了幾套框架和類庫用於對上述架構模型提供支援。
（1） datarabbit 提供了基於關係和基於orm（輕量）的資料訪問，通過外掛程式的方式來支援新的資料庫型別。
（2） esframework 解決了分布式系統（如上述的地域分布式架構）之間的底層通訊（直接基於tcp和udp）。
（3） addinsframework 為「框架＋外掛程式」架構模型提供支援。
上面介紹的很多內容在我以往的blog文章中都有提及，讀者可以針對我早期的blog來進一步了解這些內容。
架構 常用的三種架構模式
在做架構設計的時候，一般會採用一些架構模式，便於設計和以後需求變更時修改 如果設計模式選擇得不正確那麼很容易造成架構的混亂，也會變成怪物。分層模式 分層模式是最常見的模式。我們熟悉的mvc模式就是分層模式的一種。在進行架構設計的時候，如果一籌莫展，那麼分層模式是很好的一種嘗試。在分層模式中，業務水平...
hadoop的架構模型
1.x的版本架構模型介紹 檔案系統核心模組 namenode 集群當中的主節點，管理元資料 檔案的大小，檔案的位置，檔案的許可權 主要用於管理集群當中的各種資料 seconddarynamenode 主要能用於hadoop當中元資料資訊的輔助管理 datanode 集群當中的從節點，主要用於儲存集群...
hadoop的架構模型
資料 於網路 檔案系統核心模組 namenode 集群當中的主節點，主要用於管理集群當中的各種資料 secondarynamenode 主要能用於hadoop當中元資料資訊的輔助管理 datanode 集群當中的從節點，主要用於儲存集群當中的各種資料 資料計算核心模組 jobtracker 接收使用...