軟件架構(gòu)和設(shè)計(jì)模式

點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”

優(yōu)質(zhì)文章，第一時(shí)間送達(dá)

  作者 |  錵開や落幕

來源 |  urlify.cn/V3U7zm

軟件架構(gòu)與設(shè)計(jì)模式的區(qū)別

有很多程序員經(jīng)常會(huì)把軟件架構(gòu)和設(shè)計(jì)模式混淆，比如認(rèn)為MVC架構(gòu)是一種設(shè)計(jì)模式。實(shí)際上它們是完全不同的概念軟件。軟件架構(gòu)通常考慮的是代碼重用，而設(shè)計(jì)模式考慮的是設(shè)計(jì)重用，應(yīng)用框架則介于兩者之間，部分代碼重用，部分設(shè)計(jì)重用，有時(shí)分析也可重用。在軟件開發(fā)過程中有以下3種級(jí)別的重用。

（1）內(nèi)部重用：即在同一應(yīng)用程序中將公共使用的抽象塊進(jìn)行重復(fù)使用。

（2）代碼重用：即將通用模塊組合成庫或工具集，以便在多個(gè)應(yīng)用和領(lǐng)域都能使用。

（3）架構(gòu)重用：即為專用領(lǐng)域提供通用的或現(xiàn)成的基礎(chǔ)結(jié)構(gòu)，以獲得最高級(jí)別的重用性。

軟件架構(gòu)與設(shè)計(jì)模式雖然相似，但卻有著根本的不同。設(shè)計(jì)模式是對(duì)在某種環(huán)境中反復(fù)出現(xiàn)的問題及解決該問題的方案的描述，它比軟件架構(gòu)更抽象；軟件架構(gòu)可以用代碼表示，也能直接執(zhí)行或復(fù)用，而對(duì)設(shè)計(jì)模式而言，只有實(shí)例才能用代碼表示。設(shè)計(jì)模式是比軟件架構(gòu)更小的元素，一個(gè)軟件架構(gòu)中往往含有一個(gè)或多個(gè)設(shè)計(jì)模式，軟件架構(gòu)總是針對(duì)某一特定應(yīng)用領(lǐng)域，但同一設(shè)計(jì)模式卻可適用于各種應(yīng)用?？梢哉f，軟件架構(gòu)是應(yīng)用程序，而設(shè)計(jì)模式是開發(fā)應(yīng)用程序的具體方法。我們經(jīng)常使用的軟件架構(gòu)有MVC架構(gòu)、ORM架構(gòu)等。

三層架構(gòu)

通常意義上的三層架構(gòu)（3-Tier Architecture）是將整個(gè)業(yè)務(wù)應(yīng)用自下而上劃分為數(shù)據(jù)訪問層（Data Access Layer，DAL）、業(yè)務(wù)邏輯層（Business Logic Layer，BLL）和表示層（User Interface Layer，UI）。區(qū)分層次是為了體現(xiàn)“高聚合、低耦合”的設(shè)計(jì)理念。在軟件體系架構(gòu)設(shè)計(jì)中，分層式結(jié)構(gòu)是最常見、也是最重要的一種結(jié)構(gòu)。

三層架構(gòu)的編程模型

三層架構(gòu)的編程模型如下

在這3個(gè)層次中，系統(tǒng)主要功能和業(yè)務(wù)邏輯都在業(yè)務(wù)邏輯層進(jìn)行處理。

1.表示層

表示層又叫作表現(xiàn)層，位于三層架構(gòu)的最上層，與用戶直接接觸，主要是B/S信息系統(tǒng)中的Web瀏覽頁面。作為Web瀏覽頁面，表示層的主要功能是實(shí)現(xiàn)系統(tǒng)數(shù)據(jù)的傳入與輸出，在此過程中不需要借助邏輯判斷操作就可以將數(shù)據(jù)傳送到業(yè)務(wù)邏輯層進(jìn)行數(shù)據(jù)處理，處理后會(huì)將結(jié)果反饋到表示層中。換句話說，表示層實(shí)現(xiàn)用戶界面功能，將用戶的需求傳達(dá)和反饋，并用業(yè)務(wù)邏輯層或者M(jìn)odels進(jìn)行調(diào)試，保證用戶體驗(yàn)。

2.業(yè)務(wù)邏輯層

業(yè)務(wù)邏輯層的功能是對(duì)具體問題進(jìn)行邏輯判斷與執(zhí)行操作，接收到表示層的用戶指令后，會(huì)連接數(shù)據(jù)訪問層。業(yè)務(wù)邏輯層在三層架構(gòu)中位于表示層與數(shù)據(jù)訪問層的中間位置，也是表示層與數(shù)據(jù)訪問層的橋梁，實(shí)現(xiàn)三層之間的數(shù)據(jù)連接和指令傳達(dá)，可以對(duì)接收數(shù)據(jù)進(jìn)行邏輯處理，實(shí)現(xiàn)數(shù)據(jù)的修改、獲取、刪除等功能，并將處理結(jié)果反饋到表示層中，實(shí)現(xiàn)軟件功能。

3.數(shù)據(jù)訪問層

數(shù)據(jù)訪問層是數(shù)據(jù)庫的主要操控系統(tǒng)，實(shí)現(xiàn)數(shù)據(jù)的增加、刪除、修改、查詢等操作，并將操作結(jié)果反饋到業(yè)務(wù)邏輯層。在實(shí)際運(yùn)行過程中，數(shù)據(jù)訪問層沒有邏輯判斷能力，為了實(shí)現(xiàn)代碼編寫的嚴(yán)謹(jǐn)性，提高代碼閱讀程度，一般軟件開發(fā)人員會(huì)在該層編寫SQL語句，保證數(shù)據(jù)訪問層的數(shù)據(jù)處理功能。

三層架構(gòu)的優(yōu)缺點(diǎn)

1.優(yōu)點(diǎn)

（1）有利于系統(tǒng)的分散開發(fā)，每一層都可以由不同的人員來開發(fā)，只要遵循接口標(biāo)準(zhǔn)，利用相同的對(duì)象模型實(shí)體類就可以，這樣可以大大提高系統(tǒng)的開發(fā)速度。

（2）可以很容易地用新的實(shí)現(xiàn)來替換原有層次的實(shí)現(xiàn)，有利于標(biāo)準(zhǔn)化。

（3）有利于各層邏輯的代碼復(fù)用，降低層與層之間的依賴。

（4）避免了表示層直接訪問數(shù)據(jù)訪問層，表示層只與業(yè)務(wù)邏輯層有聯(lián)系，提高了數(shù)據(jù)安全性。

（5）方便系統(tǒng)的移植，如果要把一個(gè)C/S系統(tǒng)變成B/S系統(tǒng)，只要修改三層架構(gòu)的表示層就可以。業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層幾乎不用修改就可以輕松地把系統(tǒng)移植到網(wǎng)絡(luò)上。

（6）項(xiàng)目結(jié)構(gòu)更清楚，分工更明確，極大地降低了后期維護(hù)成本，減少了維護(hù)時(shí)間。

2.缺點(diǎn)

（1）降低了系統(tǒng)的性能，這是不言而喻的。如果不采用分層式結(jié)構(gòu)，則很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來完成。

（2）有時(shí)會(huì)導(dǎo)致級(jí)聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個(gè)功能，為保證其設(shè)計(jì)符合分層式結(jié)構(gòu)，則可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼。

（3）增加了開發(fā)成本。

ORM架構(gòu)

ORM（Object Relational Mapping，對(duì)象關(guān)系映射）是一種為了解決面向?qū)ο笈c關(guān)系型數(shù)據(jù)庫存在的互不匹配的現(xiàn)象的技術(shù)。簡(jiǎn)單地說，ORM是通過使用描述對(duì)象和數(shù)據(jù)庫之間映射的元數(shù)據(jù)，將程序中的對(duì)象自動(dòng)持久化到關(guān)系型數(shù)據(jù)庫中。實(shí)現(xiàn)持久化比較簡(jiǎn)單的方案是采用硬編碼方式，為每一種可能的數(shù)據(jù)庫訪問操作都提供單獨(dú)的方法，這個(gè)操作是在三層架構(gòu)中的數(shù)據(jù)訪問層完成的。因此，ORM架構(gòu)就是專門為數(shù)據(jù)操作層設(shè)計(jì)的。

ORM架構(gòu)的編程模型

ORM架構(gòu)的編程模型如下圖所示。

ORM的方法論基于4個(gè)核心原則。

（1）簡(jiǎn)單：ORM以最基本的形式建模數(shù)據(jù)。比如ORM會(huì)將MySQL的一張表映射成一個(gè)Java類（模型），表的字段就是這個(gè)類的成員變量。

（2）精確：ORM使所有的MySQL數(shù)據(jù)表都按照統(tǒng)一的標(biāo)準(zhǔn)精確地映射成Java類，使系統(tǒng)在代碼層面保持準(zhǔn)確統(tǒng)一。

（3）易懂：ORM使數(shù)據(jù)庫結(jié)構(gòu)文檔化。比如MySQL數(shù)據(jù)庫就被ORM轉(zhuǎn)換成了Java程序員可以讀懂的Java類，Java程序員可以只把注意力放在他擅長的Java層面（當(dāng)然能夠熟練掌握MySQL更好）。

（4）易用：ORM包含對(duì)持久化對(duì)象進(jìn)行CRUD操作的API，例如，創(chuàng)建create（）、更新update（）、保存save（）、加載load（）、查找find（）等，也就是將SQL查詢?nèi)糠庋b成了編程語言中的函數(shù)，通過函數(shù)的鏈?zhǔn)浇M合生成最終的SQL語句。通過這種封裝，避免了不規(guī)范、冗余、風(fēng)格不統(tǒng)一的SQL語句，可以避免很多人為Bug，方便編碼風(fēng)格的統(tǒng)一。目前市面上采用ORM架構(gòu)的經(jīng)典框架有MyBatis、JPA、Hibernate等。

ORM的優(yōu)缺點(diǎn)

1.優(yōu)點(diǎn)

（1）提高開發(fā)效率，降低開發(fā)成本。

（2）使開發(fā)更加對(duì)象化。

（3）可移植。

（4）可以很方便地引入數(shù)據(jù)緩存之類的附加功能。

2.缺點(diǎn)

（1）自動(dòng)化進(jìn)行關(guān)系型數(shù)據(jù)庫的映射需要消耗系統(tǒng)性能。其實(shí)這里的性能消耗比較小，一般來說可以忽略。

（2）當(dāng)處理多表聯(lián)查、where條件復(fù)雜之類的查詢時(shí)，ORM的語法會(huì)變得復(fù)雜。

MVC架構(gòu)

MVC的全稱是Model View Controller，是模型（Model）-視圖（View）-控制器（Controller）的縮寫。它指導(dǎo)我們用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼，將業(yè)務(wù)邏輯聚集到一個(gè)部件里面，在改進(jìn)和個(gè)性化定制界面及用戶交互的同時(shí)，不需要重新編寫業(yè)務(wù)邏輯。MVC被獨(dú)特地發(fā)展起來，用于把傳統(tǒng)的輸入、處理和輸出功能映射在一個(gè)邏輯的圖形化用戶界面的結(jié)構(gòu)中。

編程模型

MVC架構(gòu)提供了一種對(duì)HTML、CSS和JavaScript等前端代碼完全隔離的編程方式。各模塊之間分工明確，職責(zé)清晰，下面對(duì)MVC的模塊進(jìn)行詳細(xì)介紹。

（1）模型層用于處理應(yīng)用程序數(shù)據(jù)邏輯的部分，負(fù)責(zé)在數(shù)據(jù)庫中存取數(shù)據(jù)。

（2）視圖層用于處理數(shù)據(jù)顯示的部分，通常視圖是根據(jù)模型數(shù)據(jù)來渲染的。

（3）控制層用于處理用戶交互的部分，負(fù)責(zé)從視圖讀取數(shù)據(jù)，控制用戶輸入，并向模型發(fā)送數(shù)據(jù)。

三層之間主要的交互流程如下圖所示。

目前市面上采用MVC架構(gòu)的主流應(yīng)用框架有Spring MVC、JSF、JFinal等。

MVC的優(yōu)缺點(diǎn)

1.優(yōu)點(diǎn)

（1）降低耦合性。視圖層和業(yè)務(wù)層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼。同樣，一個(gè)應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需要改動(dòng)MVC的模型層即可。因?yàn)槟Ｐ团c控制器和視圖相分離，所以很容易改變應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。（2）提高代碼重用性。隨著IT技術(shù)的不斷升級(jí)，需要用越來越多的方式訪問應(yīng)用程序。MVC模式允許使用各種不同樣式的視圖來訪問同一個(gè)服務(wù)端的代碼，因?yàn)槎鄠€(gè)視圖能共享一個(gè)模型。由于模型返回的數(shù)據(jù)沒有進(jìn)行格式化，所以同樣的構(gòu)件能被不同的界面使用。

（3）軟件生命周期內(nèi)的維護(hù)成本降低，因?yàn)椴捎肕VC使開發(fā)和維護(hù)用戶接口的技術(shù)含量降低，分離視圖層和業(yè)務(wù)邏輯層也使得Web應(yīng)用更易于維護(hù)和修改。

（4）部署更快，使用MVC使開發(fā)時(shí)間得到相當(dāng)大的縮減，它使Java開發(fā)人員把精力集中于業(yè)務(wù)邏輯，界面開發(fā)人員把精力集中于表現(xiàn)形式。

（5）有利于代碼工程化管理，由于不同的層各司其職，每一層不同的應(yīng)用都具有某些相同的特征，有利于通過工程化、工具化管理程序代碼?？刂破饕蔡峁┝艘粋€(gè)好處，就是可以使用控制器來連接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構(gòu)造應(yīng)用程序提供強(qiáng)有力的手段。給定一些可重用的模型和視圖，控制器可以根據(jù)用戶的需求選擇模型進(jìn)行處理，然后選擇視圖將處理結(jié)果顯示給用戶。

缺點(diǎn)

（1）沒有明確的邊界定義。作為初學(xué)者完全理解MVC并不是很容易。使用MVC需要精心的設(shè)計(jì)，由于它的內(nèi)部原理比較復(fù)雜，所以需要花費(fèi)一些時(shí)間去思考。同時(shí)由于模型和視圖要嚴(yán)格分離，給調(diào)試應(yīng)用程序帶來了一定困難。每個(gè)構(gòu)件在使用之前都需要經(jīng)過徹底的測(cè)試。（2）不適合小型、中等規(guī)模的開發(fā)。因?yàn)殚_發(fā)人員需要花費(fèi)大量時(shí)間理解MVC的設(shè)計(jì)理念，將MVC應(yīng)用到規(guī)模并不是很大的應(yīng)用程序通常會(huì)得不償失。

（3）增加系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)的復(fù)雜性。對(duì)于本來就很簡(jiǎn)單的界面，如果嚴(yán)格遵循MVC，使模型、視圖與控制器分離，則會(huì)增加結(jié)構(gòu)的復(fù)雜性，并可能產(chǎn)生過多的更新操作，降低運(yùn)行效率。

（4）視圖與控制器之間過于緊密的連接。雖然視圖與控制器從設(shè)計(jì)上是相互分離的，但從邏輯上看卻是聯(lián)系緊密的部件。如果視圖沒有控制器的存在，則形同虛設(shè)，反之亦然，這樣就使得視圖和控制器的代碼不能獨(dú)立重用。

（5）降低了視圖對(duì)模型數(shù)據(jù)的訪問效率。根據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對(duì)未變化數(shù)據(jù)不必要的頻繁訪問，會(huì)降低操作性能。

RPC架構(gòu)

RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）是建立在Socket通信上的設(shè)計(jì)。在一臺(tái)機(jī)器上運(yùn)行的主程序，可以調(diào)用另一臺(tái)機(jī)器上準(zhǔn)備好的子程序，就像LPC（Local Procedure Call，本地過程調(diào)用）。也就是說兩臺(tái)服務(wù)器A和B，一個(gè)應(yīng)用部署在A服務(wù)器上，想要調(diào)用B服務(wù)器上應(yīng)用提供的函數(shù)/方法，由于不在同一個(gè)內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)。

RPC架構(gòu)的編程模型

RPC架構(gòu)主要分為3個(gè)部分，如下圖所示。

（1）服務(wù)端（Provider）：運(yùn)行在服務(wù)端，提供服務(wù)接口定義與服務(wù)實(shí)現(xiàn)類。

（2）注冊(cè)中心（Registry）：運(yùn)行在服務(wù)端，負(fù)責(zé)將本地服務(wù)發(fā)布成遠(yuǎn)程服務(wù)，管理遠(yuǎn)程服務(wù)，提供給服務(wù)消費(fèi)者使用。

（3）消費(fèi)端（Consumer）：運(yùn)行在客戶端，通過遠(yuǎn)程代理對(duì)象調(diào)用遠(yuǎn)程服務(wù)。

在上圖中，服務(wù)端啟動(dòng)后主動(dòng)向注冊(cè)中心注冊(cè)機(jī)器IP、端口及提供的服務(wù)列表；消費(fèi)端啟動(dòng)時(shí)由注冊(cè)中心獲取服務(wù)端提供方的地址列表。目前，使用RPC架構(gòu)的開源框架非常多，舉例如下。

（1）應(yīng)用級(jí)相關(guān)的服務(wù)框架：阿里的Dubbo/Dubbox、Google GRPC、SpringBoot/Spring Cloud。

（2）遠(yuǎn)程通信相關(guān)的協(xié)議：RMI、Socket、SOAP（HTTP XML）、REST（HTTPJSON）。

（3）通信相關(guān)的框架：Mina和Netty。

RPC優(yōu)缺點(diǎn)

1.優(yōu)點(diǎn)

（1）提升系統(tǒng)的可擴(kuò)展性。

（2）提升系統(tǒng)的可維護(hù)性和持續(xù)交付能力。

（3）實(shí)現(xiàn)系統(tǒng)高可用。

2.缺點(diǎn)

（1）一個(gè)完善的RPC``架構(gòu)的框架開發(fā)難度大。

（2）RPC架構(gòu)的框架調(diào)用成功率受限于網(wǎng)絡(luò)狀況。

（3）調(diào)用遠(yuǎn)程方法對(duì)初學(xué)者來說難度大。

未來架構(gòu)演變之路

隨著越來越多的人參與到互聯(lián)網(wǎng)，曾經(jīng)的單體應(yīng)用架構(gòu)越來越無法滿足需求，因此，分布式集群架構(gòu)出現(xiàn)了。也因此，分布式搭建開發(fā)成為Web開發(fā)者必須掌握的技能之一。這些技術(shù)包含但不限于ZooKeeper、Dubbo、消息隊(duì)列（ActiveMQ、Kafka、RabbitMQ）、NoSQL（Redis、MongoDB）、Nginx、分庫分表MyCat、Netty等。分布式架構(gòu)建立在RPC架構(gòu)的基礎(chǔ)之上。大概很多小伙伴都見過下圖，這是在Dubbo官網(wǎng)中找到的一張描述項(xiàng)目架構(gòu)演進(jìn)過程的圖。

分布式架構(gòu)建立在RPC架構(gòu)的基礎(chǔ)之上。大概很多小伙伴都見過下圖，這是在Dubbo官網(wǎng)中找到的一張描述項(xiàng)目架構(gòu)演進(jìn)過程的圖。

它描述了每一種架構(gòu)需要的具體配置和組織形態(tài)。當(dāng)網(wǎng)站流量很小時(shí)，只需一個(gè)應(yīng)用，將所有功能都部署在一起，以減少節(jié)點(diǎn)部署和成本，我們通常會(huì)采用單一應(yīng)用架構(gòu)。之后才出現(xiàn)了ORM架構(gòu)，該架構(gòu)大大簡(jiǎn)化了增刪改查的操作流程，提高了開發(fā)者的工作效率。

隨著用戶量增加，訪問量逐漸增大，單一應(yīng)用增加機(jī)器帶來的加速度越來越小，我們需要將應(yīng)用拆分成互不干擾的幾個(gè)應(yīng)用以提升效率，于是就出現(xiàn)了垂直應(yīng)用架構(gòu)。MVC架構(gòu)就是一種非常經(jīng)典的用于加速前端頁面開發(fā)的架構(gòu)。

當(dāng)垂直應(yīng)用越來越多時(shí)，應(yīng)用之間的交互不可避免，將核心業(yè)務(wù)抽取出來，作為獨(dú)立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速地響應(yīng)多變的市場(chǎng)需求，于是就出現(xiàn)了分布式服務(wù)架構(gòu)。分布式架構(gòu)下服務(wù)數(shù)量逐漸增加，為了提高管理效率，RPC架構(gòu)應(yīng)運(yùn)而生。RPC架構(gòu)用于提高業(yè)務(wù)復(fù)用及整合，在分布式服務(wù)架構(gòu)下，RPC架構(gòu)是關(guān)鍵。

下一代架構(gòu)，將會(huì)是流動(dòng)計(jì)算架構(gòu)占據(jù)主流。當(dāng)服務(wù)越來越多時(shí)，容量的評(píng)估、小服務(wù)的資源浪費(fèi)等問題逐漸明顯。此時(shí)，需要增加一個(gè)調(diào)度中心，基于訪問壓力實(shí)時(shí)管理集群容量，提高集群利用率。SOA（Service-Oriented Architecture，面向服務(wù)的架構(gòu)）架構(gòu)就是用于提高集群利用率的。在資源調(diào)度和治理中心方面，SOA架構(gòu)是關(guān)鍵。

粉絲福利：Java從入門到入土學(xué)習(xí)路線圖

??????

??長按上方微信二維碼 2 秒

感謝點(diǎn)贊支持下哈