前段時(shí)間參加新型研發(fā)能力賦能學(xué)習(xí)，才真正明白軟件的架構(gòu)模式和設(shè)計(jì)模式還不一樣。經(jīng)典的架構(gòu)模式超過(guò)20種，設(shè)計(jì)模式更多，據(jù)說(shuō)超過(guò)300種。能記住這些名字都不容易，別說(shuō)是理解和應(yīng)用了?？戳巳钜环宓摹败浖軜?gòu)入門”（是對(duì)Mark Richards的《Software Architecture Patterns》的閱讀筆記），很有收獲，整理出來(lái)分享給大家。

軟件架構(gòu)就是軟件的基本結(jié)構(gòu)。架構(gòu)的本質(zhì)是管理復(fù)雜性。如果你覺(jué)得架構(gòu)不重要，可能是你做的事情不夠復(fù)雜，或者是你沒(méi)有管理好復(fù)雜性。架構(gòu)模式雖多，但常用的適合ICT軟件，也就那么幾種：

1.分層架構(gòu)

2.事件驅(qū)動(dòng)架構(gòu)

3.微核架構(gòu)（又稱插件架構(gòu)）

4.微服務(wù)架構(gòu)

5.云架構(gòu)

一、分層架構(gòu)

分層架構(gòu)（layered architecture）是最常見(jiàn)的軟件架構(gòu)，也是事實(shí)上的軟件標(biāo)準(zhǔn)架構(gòu)。如果你不知道要用什么架構(gòu)，那就用它。有人說(shuō)軟件職業(yè)生涯中只用到了一種架構(gòu)，那一定也是它。當(dāng)前很多產(chǎn)品的頂層架構(gòu)，幾乎無(wú)一例外的也是分層架構(gòu)。

分層架構(gòu)將軟件分成若干個(gè)水平層，每一層都有清晰的角色和分工，不需要知道其他層的細(xì)節(jié)。層與層之間通過(guò)接口通信。雖然沒(méi)有明確約定軟件一定要分成多少層，但是最常見(jiàn)的是四層結(jié)構(gòu)。

• 表現(xiàn)層（presentation）：用戶界面，負(fù)責(zé)視覺(jué)和用戶互動(dòng)
• 業(yè)務(wù)層（business）：實(shí)現(xiàn)業(yè)務(wù)邏輯
• 持久層（persistence）：提供數(shù)據(jù)，SQL 語(yǔ)句就放在這一層
• 數(shù)據(jù)庫(kù)（database） ：保存數(shù)據(jù)

有的軟件在邏輯層和持久層之間，加了一個(gè)服務(wù)層（service），提供不同業(yè)務(wù)邏輯需要的一些通用接口。用戶的請(qǐng)求將依次通過(guò)這四層的處理，不能跳過(guò)其中任何一層。

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

1、結(jié)構(gòu)簡(jiǎn)單，容易理解和開發(fā)；

2、不同技能的程序員可以分工，負(fù)責(zé)不同的層，天然適合大多數(shù)軟件公司的組織架構(gòu)。雖說(shuō)架構(gòu)決定組織，但實(shí)際上架3、構(gòu)往往都是服從于組織；

3、每一層都可以獨(dú)立測(cè)試，其他層的接口通過(guò)模擬解決。

分層架構(gòu)的缺點(diǎn)：

1、 一旦環(huán)境變化，需要代碼調(diào)整或增加功能時(shí)，通常比較費(fèi)時(shí)費(fèi)力；

2、部署比較麻煩，即使只修改一個(gè)小地方，往往需要整個(gè)軟件重新部署，不容易做持續(xù)發(fā)布；

3、軟件升級(jí)時(shí)，可能需要整個(gè)服務(wù)暫停；

4、擴(kuò)展性差。用戶請(qǐng)求大量增加時(shí)，必須依次擴(kuò)展每一層，由于每一層內(nèi)部是耦合的，擴(kuò)展會(huì)很困難。

二、事件驅(qū)動(dòng)架構(gòu)

所謂事件（Event），是狀態(tài)發(fā)生變化時(shí)，軟件發(fā)出的通知，觸發(fā)相關(guān)的操作。事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）就是通過(guò)事件進(jìn)行通信的軟件架構(gòu)。它分成四個(gè)部分：

• 事件隊(duì)列（event queue）：接收事件的入口
• 分發(fā)器（event mediator）：將不同的事件分發(fā)到不同的業(yè)務(wù)邏輯單元
• 事件通道（event channel）：分發(fā)器與處理器之間的聯(lián)系渠道
• 事件處理器（event processor）：實(shí)現(xiàn)業(yè)務(wù)邏輯，處理完成后會(huì)發(fā)出事件，觸發(fā)下一步操作

對(duì)于簡(jiǎn)單的項(xiàng)目，事件隊(duì)列、分發(fā)器和事件通道，可以合為一體，整個(gè)軟件就分成事件代理和事件處理器兩部分。

事件驅(qū)動(dòng)架構(gòu)的優(yōu)點(diǎn)：

1、分布式的異步架構(gòu)，事件處理器之間高度解耦，軟件的擴(kuò)展性好；

2、適用性廣，各種類型的項(xiàng)目都可以用；

3、性能較好，因?yàn)槭录漠惒奖举|(zhì)，軟件不易產(chǎn)生堵塞；

4、事件處理器可以獨(dú)立地加載和卸載，容易部署。

事件驅(qū)動(dòng)架構(gòu)的缺點(diǎn)：

1、涉及異步編程（要考慮遠(yuǎn)程通信、失去響應(yīng)等情況），開發(fā)相對(duì)復(fù)雜；

2、難以支持原子性操作，因?yàn)槭录ㄟ^(guò)會(huì)涉及多個(gè)處理器，很難回滾；

3、分布式和異步特性導(dǎo)致這個(gè)架構(gòu)較難測(cè)試。

事件驅(qū)動(dòng)架構(gòu)在通信產(chǎn)品中應(yīng)用得也非常廣泛，典型的如狀態(tài)機(jī)處理。事件驅(qū)動(dòng)架構(gòu)不適于做頂層架構(gòu)，但適合做局部實(shí)現(xiàn)，幾乎遍布在通信軟件的各個(gè)角落。

三、微核架構(gòu)

微核架構(gòu)（microkernel architecture）又稱為"插件架構(gòu)"（plug-in architecture），指的是軟件的內(nèi)核（core）做得相對(duì)較小，主要功能和業(yè)務(wù)邏輯都通過(guò)插件實(shí)現(xiàn)。

內(nèi)核通常只包含系統(tǒng)運(yùn)行的最小功能，插件則是互相獨(dú)立的業(yè)務(wù)功能。插件之間的通信，應(yīng)該減少到最低，避免出現(xiàn)互相依賴的問(wèn)題。

微核架構(gòu)的優(yōu)點(diǎn)：

1、良好的功能延伸性（extensibility），需要什么功能，開發(fā)一個(gè)插件即可；

2、功能之間是隔離的，插件可以獨(dú)立的加載和卸載，使得它比較容易部署；

3、可定制性高，適應(yīng)不同的開發(fā)需要；

4、可以漸進(jìn)式地開發(fā)，逐步增加功能。

微核架構(gòu)的缺點(diǎn)：

1、擴(kuò)展性（scalability）差，內(nèi)核通常是一個(gè)獨(dú)立單元，不容易做成分布式；

2、開發(fā)難度相對(duì)較高，因?yàn)樯婕暗讲寮c內(nèi)核的通信，以及內(nèi)部的插件登記機(jī)制。

微核架構(gòu)的設(shè)計(jì)和開發(fā)難度較高，這就注定它在企業(yè)產(chǎn)品中用得不多，雖然它的優(yōu)點(diǎn)還不少。

四、微服務(wù)架構(gòu)

微服務(wù)架構(gòu)（microservices architecture）是面向服務(wù)架構(gòu)（service-oriented architecture，縮寫 SOA）的升級(jí)。每一個(gè)服務(wù)就是一個(gè)獨(dú)立的部署單元（separately deployed unit）。這些單元都是分布式的，互相解耦，通過(guò)遠(yuǎn)程通信協(xié)議（比如REST、SOAP）聯(lián)系。

微服務(wù)架構(gòu)分成三種實(shí)現(xiàn)模式：

• RESTful API 模式：服務(wù)通過(guò) API 提供，云服務(wù)就屬于這一類；
• RESTful應(yīng)用模式：服務(wù)通過(guò)傳統(tǒng)的網(wǎng)絡(luò)協(xié)議或者應(yīng)用協(xié)議提供，背后通常是一個(gè)多功能的應(yīng)用程序，常見(jiàn)于企業(yè)內(nèi)部；
• 集中消息模式：采用消息代理（message broker），可以實(shí)現(xiàn)消息隊(duì)列、負(fù)載均衡、統(tǒng)一日志和異常處理，缺點(diǎn)是會(huì)出現(xiàn)單點(diǎn)失敗，消息代理可能要做成集群。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)：

1、展性好，各個(gè)服務(wù)之間低耦合；

2、容易部署，軟件從單一可部署單元，被拆成了多個(gè)服務(wù)，每個(gè)服務(wù)都是可部署單元；

3、容易開發(fā)，每個(gè)組件都可以進(jìn)行持續(xù)集成式的開發(fā)，可以做到實(shí)時(shí)部署，不間斷地升級(jí)；

4、易于測(cè)試，可以單獨(dú)測(cè)試每一個(gè)服務(wù)。

微服務(wù)架構(gòu)的缺點(diǎn)：

1、由于強(qiáng)調(diào)互相獨(dú)立和低耦合，服務(wù)可能會(huì)拆分得很細(xì)。這導(dǎo)致系統(tǒng)依賴大量的微服務(wù)，變得很凌亂和笨重，性能也會(huì)不佳；

2、一旦服務(wù)之間需要通信（即一個(gè)服務(wù)要用到另一個(gè)服務(wù)），整個(gè)架構(gòu)就會(huì)變得復(fù)雜。典型的例子就是一些通用的 Utility 類，一種解決方案是把它們拷貝到每一個(gè)服務(wù)中去，用冗余換取架構(gòu)的簡(jiǎn)單性；

3、分布式的本質(zhì)使得這種架構(gòu)很難實(shí)現(xiàn)原子性操作，交易回滾會(huì)比較困難。

微服務(wù)架構(gòu)易開發(fā)、易測(cè)試、易部署，解耦，擴(kuò)展性好，所以它成為當(dāng)今的網(wǎng)紅也絕非偶然。但服務(wù)變多變細(xì)，勢(shì)必帶來(lái)新的管理復(fù)雜性。好在當(dāng)前工具工程能力的強(qiáng)大，管理復(fù)雜性在一定程度上可以通過(guò)自動(dòng)化來(lái)解決。盡快如此，服務(wù)的劃分仍然很重要，不要通過(guò)后端的自動(dòng)化來(lái)掩蓋前端的不足。

五、云架構(gòu)

云架構(gòu)（cloud architecture）主要解決擴(kuò)展性和并發(fā)的問(wèn)題，是最容易擴(kuò)展的架構(gòu)。云化軟件架構(gòu)的核心是數(shù)據(jù)庫(kù)去中心化，數(shù)據(jù)變成可復(fù)制的內(nèi)存數(shù)據(jù)單元。業(yè)務(wù)處理能力封裝成一個(gè)個(gè)處理單元。業(yè)務(wù)流程和數(shù)據(jù)分離，業(yè)務(wù)狀態(tài)外置，處理單元水平擴(kuò)展。訪問(wèn)量增加，就新建處理單元；訪問(wèn)量減少，就關(guān)閉處理單元。由于沒(méi)有中央數(shù)據(jù)庫(kù)，所以擴(kuò)展性的最大瓶頸消失了。由于每個(gè)處理單元的數(shù)據(jù)都在內(nèi)存里，最好要進(jìn)行數(shù)據(jù)持久化。云化架構(gòu)對(duì)于云上應(yīng)用的可靠性、高擴(kuò)展和高并發(fā)至關(guān)重要。

這個(gè)模式主要分成兩部分：處理單元（processing unit）和虛擬中間件（virtualized middleware）。

處理單元：實(shí)現(xiàn)業(yè)務(wù)邏輯；

虛擬中間件：負(fù)責(zé)通信、保持sessions、數(shù)據(jù)復(fù)制、分布式處理、處理單元的部署。

虛擬中間件又包含四個(gè)組件：

• 消息中間件（Messaging Grid）：管理用戶請(qǐng)求和session，當(dāng)一個(gè)請(qǐng)求進(jìn)來(lái)以后，決定分配給哪一個(gè)處理單元；
• 數(shù)據(jù)中間件（Data Grid）：將數(shù)據(jù)復(fù)制到每一個(gè)處理單元，即數(shù)據(jù)同步。保證某個(gè)處理單元都得到同樣的數(shù)據(jù)；
• 處理中間件（Processing Grid）：可選，如果一個(gè)請(qǐng)求涉及不同類型的處理單元，該中間件負(fù)責(zé)協(xié)調(diào)處理單元；
• 部署中間件（Deployment Manager）：負(fù)責(zé)處理單元的啟動(dòng)和關(guān)閉，監(jiān)控負(fù)載和響應(yīng)時(shí)間，當(dāng)負(fù)載增加，就新啟動(dòng)處理單元，負(fù)載減少，就關(guān)閉處理單

云架構(gòu)的優(yōu)點(diǎn)：

1、高負(fù)載，高擴(kuò)展；

2、動(dòng)態(tài)部署。

云架構(gòu)的缺點(diǎn)：

1、實(shí)現(xiàn)復(fù)雜，成本較高；

2、主要適合網(wǎng)站類應(yīng)用，不合適大量數(shù)據(jù)吞吐的大型數(shù)據(jù)庫(kù)應(yīng)用；

3、較難測(cè)試。

以上是從技術(shù)本質(zhì)，對(duì)架構(gòu)進(jìn)行分類。實(shí)際應(yīng)用中，各種架構(gòu)并不是孤立的，可以根據(jù)業(yè)務(wù)環(huán)境和業(yè)務(wù)訴求，對(duì)各種架構(gòu)進(jìn)行綜合和嫁接。曾對(duì)微服務(wù)架構(gòu)和微核架構(gòu)進(jìn)行綜合，總結(jié)出微插件架構(gòu)，適合于在資源受限的場(chǎng)景應(yīng)用微服務(wù)的架構(gòu)。另外，就如上面列舉，每種架構(gòu)都有其優(yōu)點(diǎn)和缺點(diǎn)。優(yōu)點(diǎn)不必多說(shuō)，缺點(diǎn)則幾乎都是通過(guò)工具工程能力的方法來(lái)規(guī)避，工具工程對(duì)軟件架構(gòu)非常重要。