淺析經常使用軟件架構中的必定要理解的三種架構模型

經常使用的軟件架構模型能夠歸類爲三種架構模型：3/N層架構、「框架＋插件」架構、地域分佈式架構。

一．三種架構模型

1．3/N層架構

這是經典的多層架構模型，對於稍微複雜一點或特別複雜的系統，不使用分層架構是很難想象的。下圖是經典的3層架構：

現在，凡是個程序員都能侃侃而談3/N層架構，這確實是解決系統複雜性的一種主流模式，可是，只要採用了3/N層架構是否是就必定能解決系統的複雜性了？不必定，關鍵在於你在你的系統中如何實做你的3/N層結構。

在採用了3/N層架構後，咱們仍是要解決如下很是重要的問題：系統的可擴展性（能從容地應對變化）、系統的可維護性（由於系統並非使用一次就被拋 棄）、方便部署（在需求變化時，方便部署新的業務功能）、還有等等其它系統質量屬性。然而系統的可擴展性和可維護性是大多數軟件系統必須解決的重中之重， 這是因爲當前需求複雜多變的軟件環境決定的。就像實現功能需求是最基本的，採用3/N層架構也只是萬里長征的第一步。

我採用「框架＋插件」架構來解決與系統的可擴展性、可維護性和部署相關的難題。

2. 「框架＋插件」架構

經典的3/N層架構是對系統進行「縱向」分層，而「框架＋插件」架構對系統進行「橫向」分解。3/N層架構和「框架＋插件」架構處於一個平等的位置，它們沒有任何依賴關係。

可是我常常將它們結合在一塊兒使用，咱們的系統在通過3/N層架構的縱向分層和「框架＋插件」架構的橫向分層後，能夠被看做一個「網格」結構，其中的 某些網格能夠看做是「擴展點」，咱們能夠在這些擴展點處掛接「插件」。也就是說咱們能夠在3/N層架構的每一層都掛接適當的插件來完成該層的一些功能。 如：

插件最主要的特色是能夠實現「熱插拔」，也就是說能夠在不中止服務的狀況下，動態加載/移除/更新插件。因此，採用插件技術能夠實現如下功能：

（1）在UI層，咱們能夠在運行時，替換掉某些用戶界面、或加載與新的業務相關的用戶界面。在業務邏輯層，咱們能夠在運行時加載、替換或者刪除某項業務服務。在數據訪問層，經過使用插件技術咱們能夠動態地添加對新的數據庫類型（如MySQL）的支持。

若是有想學架構技術的朋友能夠加個人QQ羣725219329，裏面分享了我從業十年的編程心得，包括一些經典的源碼分析，看看大牛的代碼是如何設計的，爲何要這樣設計。還有目前最主流的分佈式架構技術，微服務架構技術等。這些技術都錄製成視頻分享在羣裏，你們能夠免費下載。

插件的「熱插拔」功能使得咱們的系統有很是好的可擴展性。

（2）若是咱們須要升級系統，不少狀況下，只要升級咱們的插件（好比業務插件）就能夠了，咱們能夠作到在服務運行的時候進行插件的自動升級。

（3）要想將系統作成「框架＋插件」的結構，要求咱們須要在系統的各層進行「鬆耦合」設計，只有鬆耦合的組件才能夠被作成「插件」。

在3/N層架構中融合「框架＋插件」架構，最難的是對業務邏輯層的鬆耦合處理，這須要咱們細緻分析業務需求之間的關聯，將耦合度緊密的業務封裝在一個組件中，如此獲得的相互獨立的業務組件即可以有機會成爲插件。這個過程可能須要不斷的重構、設計的重構。

咱們知道，相比於那些緊密耦合的組件，鬆耦合的組件更加清晰明確、更加容易維護。另外，在該架構模型中引入了AOP框架進行Aspect焦點的集中 編程（好比處理日誌記錄、權限管理等方面），使得Aspect代碼不會摻雜在正常的業務邏輯代碼中，使得代碼的的清晰性、可維護性進一步加強。

從上述介紹能夠看出，採用3/N層架構和「框架＋插件」架構相結合，咱們能夠加強系統的可擴展性、可維護性和簡單部署升級的能力。

3. 地域分佈式架構

我無心中發明了「地域分佈式架構」這個詞，呵呵，不知道意思是否表達得準確。地域分佈式架構主要針對相似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（輕量）的數據訪問，經過插件的方式來支持新的數據庫類型。

若是有想學架構技術的朋友能夠加個人QQ羣725219329，裏面分享了我從業十年的編程心得，包括一些經典的源碼分析，看看大牛的代碼是如何設計的，爲何要這樣設計。還有目前最主流的分佈式架構技術，微服務架構技術等。這些技術都錄製成視頻分享在羣裏，你們能夠免費下載。

（2）ESFramework 解決了分佈式系統（如上述的地域分佈式架構）之間的底層通訊（直接基於TCP和UDP）。

（3）AddinsFramework 爲「框架＋插件」架構模型提供支持。

（4）ESAspect 經過Proxy方式實現的AOP框架，對方面編程提供支持。

（5）EsfDRArchitecture 爲地域分佈式架構模型提供支持。好比支持，FS的動態添加/移除；FS的負載均衡；AS與FS、AS與IRAS之間的通訊；跨區域的服務請求等等。

感受以上的架構設計主要偏向於J2EE方面的系統設計，若是是其餘的如通訊系統的設計，可能就得另當別論。