常用的軟件架構模型可以歸類為三種架構模型：3/N層架構、“框架＋插件”架構、地域分布式架構。
一．三種架構模型
1．3/N層架構
這是經(jīng)典的多層架構模型，對于稍微復雜一點或特別復雜的系統(tǒng)，不使用分層架構是很難想象的。下圖是經(jīng)典的3層架構：
如今，凡是個程序員都能侃侃而談3/N層架構，這確實是解決系統(tǒng)復雜性的一種主流模式，但是，只要采用了3/N層架構是不是就一定能解決系統(tǒng)的復雜性了？不一定，關鍵在于你在你的系統(tǒng)中如何實作你的3/N層結構。
在采用了3/N層架構后，我們還是要解決以下非常重要的問題：系統(tǒng)的可擴展性（能從容地應對變化）、系統(tǒng)的可維護性（因為系統(tǒng)并不是使用一次就被拋 棄）、方便部署（在需求變化時，方便部署新的業(yè)務功能）、還有等等其它系統(tǒng)質(zhì)量屬性。然而系統(tǒng)的可擴展性和可維護性是大多數(shù)軟件系統(tǒng)必須解決的重中之重， 這是由于當前需求復雜多變的軟件環(huán)境決定的。就像實現(xiàn)功能需求是最基本的，采用3/N層架構也只是萬里長征的第一步。
我采用“框架＋插件”架構來解決與系統(tǒng)的可擴展性、可維護性和部署相關的難題。
2. “框架＋插件”架構
經(jīng)典的3/N層架構是對系統(tǒng)進行“縱向”分層，而“框架＋插件”架構對系統(tǒng)進行“橫向”分解。3/N層架構和“框架＋插件”架構處于一個平等的位置，它們沒有任何依賴關系。
但是我經(jīng)常將它們結合在一起使用，我們的系統(tǒng)在經(jīng)過3/N層架構的縱向分層和“框架＋插件”架構的橫向分層后，可以被看作一個“網(wǎng)格”結構，其中的 某些網(wǎng)格可以看作是“擴展點”，我們可以在這些擴展點處掛接“插件”。也就是說我們可以在3/N層架構的每一層都掛接適當?shù)牟寮硗瓿稍搶拥囊恍┕δ堋?如：
插件最主要的特點是可以實現(xiàn)“熱插拔”，也就是說可以在不停止服務的情況下，動態(tài)加載/移除/更新插件。所以，采用插件技術可以實現(xiàn)以下功能：
（1）在UI層，我們可以在運行時，替換掉某些用戶界面、或加載與新的業(yè)務相關的用戶界面。在業(yè)務邏輯層，我們可以在運行時加載、替換或者刪除某項業(yè)務服務。在數(shù)據(jù)訪問層，通過使用插件技術我們可以動態(tài)地添加對新的數(shù)據(jù)庫類型（如MySQL）的支持。
插件的“熱插拔”功能使得我們的系統(tǒng)有非常好的可擴展性。
（2）如果我們需要升級系統(tǒng)，很多情況下，只要升級我們的插件（比如業(yè)務插件）就可以了，我們可以做到在服務運行的時候進行插件的自動升級。
（3）要想將系統(tǒng)做成“框架＋插件”的結構，要求我們需要在系統(tǒng)的各層進行“松耦合”設計，只有松耦合的組件才可以被做成“插件”。
在3/N層架構中融合“框架＋插件”架構，最難的是對業(yè)務邏輯層的松耦合處理，這需要我們細致分析業(yè)務需求之間的關聯(lián)，將耦合度緊密的業(yè)務封裝在一個組件中，如此得到的相互獨立的業(yè)務組件便可以有機會成為插件。這個過程可能需要不斷的重構、設計的重構。
我們知道，相比于那些緊密耦合的組件，松耦合的組件更加清晰明確、更加容易維護。另外，在該架構模型中引入了AOP框架進行Aspect焦點的集中 編程（比如處理日志記錄、權限管理等方面），使得Aspect代碼不會摻雜在正常的業(yè)務邏輯代碼中，使得代碼的的清晰性、可維護性進一步增強。
從上述介紹可以看出，采用3/N層架構和“框架＋插件”架構相結合，我們可以增強系統(tǒng)的可擴展性、可維護性和簡單部署升級的能力。
3. 地域分布式架構
我無意中發(fā)明了“地域分布式架構”這個詞，呵呵，不知道意思是否表達得準確。地域分布式架構主要針對類似LBS（基于位置的服務）的需要進行地域分布的應用。 地域分布式架構基于上述的3/N層架構和“框架＋插件”架構，它們的關系如下：
現(xiàn)在我對地域分布式架構作個簡單的介紹。假設我們需要為全國的各個大城市提供我們的業(yè)務功能服務，假設每個城市的客戶量很大，而且每個城市訪問的數(shù) 據(jù)可能是不一樣的（如每個城市的地圖數(shù)據(jù)）、訪問的功能也不盡相同（如有的城市提供天氣查詢服務，而另一些城市不提供）。客戶除了跟我們的系統(tǒng)請求服務之 外，可能還想通過我們的系統(tǒng)與他的好朋友進行即時通信，而它們好朋友可能與他在同一個城市，也可能位于另外一個城市。
好了，我們看地域分布式架構是如何解決類似上述的需求的。
首先，地域分布式架構將用戶管理和業(yè)務功能服務分開，分別由應用服務器（AS）和功能服務器（FS）負責，然后將它們部署到不同的節(jié)點上。AS和FS都采用了3/N層架構和“框架＋插件”架構相結合的架構，比如，F(xiàn)S通過功能插件提供功能服務。
比如，對于武漢這個地域，我們部署了一臺AS和一臺FS，客戶端通過連接到AS進行服務請求。假設有一天，我們在武漢的客戶急劇增加，這是壓力最大的是FS，因為所有的業(yè)務計算都是在FS上完成的。
這時，地域分布式架構將允許我們在不停止任何服務的情況下，動態(tài)的添加FS服務器，新添加的FS服務器會自動注冊到AS。
AS可以監(jiān)控每個FS的負載（如CPU消耗、內(nèi)存消耗），再有客戶端請求到來時，AS會將請求交給負載最低的FS處理，這就實現(xiàn)了FS的負載均衡。
如果Client A需要與Client B進行即時通信，那么這些通信消息將通過AS中轉。
上面看到的是我們的系統(tǒng)在武漢的部署，而在其他城市部署情況也一樣。
在這種情況下，AS和AS之間是相互獨立的，但是經(jīng)常會發(fā)生AS之間需要相互通信的情況，比如：Client A需要與Client E進行即時通信，或者Client A需要請求上海地區(qū)獨有的服務，等等。
地域分布式架構使用跨區(qū)域的應用服務器（IRAS）來解決AS之間的通信問題。所有AS在啟動的時候，將自動向IRAS注冊。
如果，我們想在長沙市也提供我們的服務，那么我們只需要在長沙部署我們的AS和FS，這樣就可以融入到上圖表示的整個地域分布式架構中。
關于地域分布式架構，就簡單的介紹這么多，更多的內(nèi)容，讀者可以自己去分析挖掘。
二．對架構模型的支持
如果沒有自己的一套工具對上述的架構模型作支持，那么你可能會認為我是在這里胡扯、夸夸其談。在這幾年的開發(fā)中，我積累了幾套框架和類庫用于對上述架構模型提供支持。
（1）DataRabbit 提供了基于關系和基于ORM（輕量）的數(shù)據(jù)訪問，通過插件的方式來支持新的數(shù)據(jù)庫類型。
（2）ESFramework 解決了分布式系統(tǒng)（如上述的地域分布式架構）之間的底層通信（直接基于TCP和UDP）。
（3）AddinsFramework 為“框架＋插件”架構模型提供支持。
（4）ESAspect 通過Proxy方式實現(xiàn)的AOP框架，對方面編程提供支持。
（5）EsfDRArchitecture 為地域分布式架構模型提供支持。比如支持，F(xiàn)S的動態(tài)添加/移除；FS的負載均衡；AS與FS、AS與IRAS之間的通信；跨區(qū)域的服務請求等等。
感覺以上的架構設計主要偏向于J2EE方面的系統(tǒng)設計，如果是其他的如通信系統(tǒng)的設計，可能就得另當別論。
如果有想學架構技術的朋友可以加我的QQ群725219329，里面分享了我從業(yè)十年的編程心得，包括一些經(jīng)典的源碼分析，看看大牛的代碼是如何設計的，為什么要這樣設計。還有目前最主流的分布式架構技術，微服務架構技術等。這些技術都錄制成視頻分享在群里，大家可以免費下載。
