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