模式的經(jīng)典定義：每個(gè)模式都描述了一個(gè)在我們的環(huán)境中不斷出現(xiàn)的問(wèn)題，然后描述了該問(wèn)題的解決方案的核心，通過(guò)這種方式，我們可以無(wú)數(shù)次地重用那些已有的解決方案，無(wú)需再重復(fù)相同的工作。即模式是在特定環(huán)境中解決問(wèn)題的一種方案 。

        什么是架構(gòu)模式？在維基百科：架構(gòu)模式是針對(duì)特定軟件架構(gòu)場(chǎng)景常見(jiàn)問(wèn)題的通用、可重用解決方案。架構(gòu)模式類(lèi)似于軟件設(shè)計(jì)模式，但范圍更廣。

        架構(gòu)的本質(zhì)是管理復(fù)雜性。如果你覺(jué)得架構(gòu)不重要，可能是你做的事情不夠復(fù)雜，或者是你沒(méi)有管理好復(fù)雜性。架構(gòu)模式雖多，經(jīng)過(guò)抽象沉淀之后，也就那么幾種，O'Reilly 出版過(guò)一本免費(fèi)的小冊(cè)子《Software Architecture Patterns》， 介紹了五種最常見(jiàn)的軟件架構(gòu)，是非常好的入門(mén)讀物：

1. 分層架構(gòu)（比較傳統(tǒng)的單體架構(gòu)）

2. 微服務(wù)架構(gòu)（服務(wù)分割：當(dāng)前比較流行的服務(wù)化架構(gòu)，解決單體架構(gòu)面臨的問(wèn)題，適合敏捷開(kāi)發(fā)，快速迭代）

3. 微核架構(gòu)（又稱插件架構(gòu)，開(kāi)發(fā)難度較高，一般用來(lái)做工具軟件開(kāi)發(fā)，如Eclipse，不太適合分布式業(yè)務(wù)場(chǎng)景）

4. 事件驅(qū)動(dòng)架構(gòu) （一般適用于應(yīng)用局部場(chǎng)景，用來(lái)實(shí)現(xiàn)異步解耦）

5. 云架構(gòu)（現(xiàn)在的說(shuō)法是云原生架構(gòu)-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架構(gòu)）

一、分層

分層架構(gòu)（layered architecture）是最常見(jiàn)的軟件架構(gòu)，也是事實(shí)上的標(biāo)準(zhǔn)架構(gòu)。如果你不知道要用什么架構(gòu)，那就用它。

分層：對(duì)模型中同一抽象層次上的包進(jìn)行分組的一種特定方式。通過(guò)分層，從邏輯上將子系統(tǒng)劃分成許多集合，而層間關(guān)系的形成要遵循一定的規(guī)則。通過(guò)分層，可以限制子系統(tǒng)間的依賴關(guān)系，使系統(tǒng)以更松散的方式耦合，從而更易于維護(hù)。（層是對(duì)構(gòu)架的橫向劃分，分區(qū)是對(duì)構(gòu)架的縱向劃分）。
 

層（layer）這個(gè)概念在計(jì)算機(jī)領(lǐng)域是非常NB的一個(gè)概念。計(jì)算機(jī)領(lǐng)域處處體現(xiàn)層的概念：計(jì)算機(jī)本身：（系統(tǒng)調(diào)用層、設(shè)備驅(qū)動(dòng)層、操作系統(tǒng)層、CPU指令集，每個(gè)層都負(fù)責(zé)自己的職責(zé)。網(wǎng)絡(luò)5層模型：（物理層、鏈路層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層）。

    層到了軟件領(lǐng)域也一樣好用。為什么呢？我們看看使用層技術(shù)有什么好處：

    ● 你使用層，但是不需要去了解層的實(shí)現(xiàn)細(xì)節(jié)。
    ● 可以使用另一種技術(shù)來(lái)改變基礎(chǔ)的層，而不會(huì)影響上面的層的應(yīng)用。
    ● 可以減少不同層之間的依賴。
    ● 容易制定出層標(biāo)準(zhǔn)。
    ● 底下的層可以用來(lái)建立頂上的層的多項(xiàng)服務(wù)。

    當(dāng)然，層也有弱點(diǎn)：

    ● 層不可能封裝所有的功能，一旦有功能變動(dòng)，勢(shì)必要波及所有的層。
    ● 效率降低。

 

當(dāng)然，層最難的一個(gè)問(wèn)題還是各個(gè)層都有些什么，以及要承擔(dān)何種責(zé)任。最常見(jiàn)的架構(gòu)模式，將系統(tǒng)在橫向維度上切分成幾個(gè)部分，每個(gè)部分單一職責(zé)。通過(guò)分層：                                      
1、從邏輯上將子系統(tǒng)劃分成許多集合，而層間關(guān)系的形成要遵循一定的規(guī)則。                                          
2、可以限制子系統(tǒng)間的依賴關(guān)系，使系統(tǒng)以更松散的方式耦合，從而更易于維護(hù)。

這種架構(gòu)將軟件分成若干個(gè)水平層，每一層都有清晰的角色和分工，不需要知道其他層的細(xì)節(jié)。層與層之間通過(guò)接口通信。

三層架構(gòu)：

雖然沒(méi)有明確約定，軟件一定要分成多少層，網(wǎng)站一般分為三個(gè)層次：應(yīng)用層、服務(wù)層和數(shù)據(jù)層，其具體結(jié)構(gòu)如下圖所示：

　　通過(guò)分層，一個(gè)龐大系統(tǒng)切分成不同部分，便于分工合作和維護(hù)。

        應(yīng)用層：主要負(fù)責(zé)具體的業(yè)務(wù)邏輯處理

         服務(wù)層：提供可復(fù)用的服務(wù)

         數(shù)據(jù)層：負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和訪問(wèn)

　　但是，分層架構(gòu)也有一些挑戰(zhàn)：①必須合理規(guī)劃層次邊界和接口；②禁止跨層次的調(diào)用及逆向調(diào)用。

常見(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ù)

有的軟件在邏輯層（business）和持久層（persistence）之間，加了一個(gè)服務(wù)層（service），提供不同業(yè)務(wù)邏輯需要的一些通用接口。

用戶的請(qǐng)求將依次通過(guò)這四層的處理，不能跳過(guò)其中任何一層。

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

• 結(jié)構(gòu)簡(jiǎn)單，容易理解和開(kāi)發(fā)
• 不同技能的程序員可以分工，負(fù)責(zé)不同的層，天然適合大多數(shù)軟件公司的組織架構(gòu)
• 每一層都可以獨(dú)立測(cè)試，其他層的接口通過(guò)模擬解決

缺點(diǎn)

• 一旦環(huán)境變化，需要代碼調(diào)整或增加功能時(shí)，通常比較麻煩和費(fèi)時(shí)
• 部署比較麻煩，即使只修改一個(gè)小地方，往往需要整個(gè)軟件重新部署，不容易做持續(xù)發(fā)布（因?yàn)槭菃误w架構(gòu)）
• 軟件升級(jí)時(shí)，可能需要整個(gè)服務(wù)暫停
• 擴(kuò)展性差。用戶請(qǐng)求大量增加時(shí)，必須依次擴(kuò)展每一層，由于每一層內(nèi)部是耦合的，擴(kuò)展會(huì)很困難（單體架構(gòu)，需求調(diào)整會(huì)貫穿每一層）

二、微服務(wù)架構(gòu)：分割和分布式

微服務(wù)架構(gòu)（microservices architecture）是服務(wù)導(dǎo)向架構(gòu)（service-oriented architecture，縮寫(xiě) SOA）的升級(jí)。

每一個(gè)服務(wù)就是一個(gè)獨(dú)立的部署單元（separately deployed unit）。這些單元都是分布式的，互相解耦，通過(guò)遠(yuǎn)程通信協(xié)議（比如REST、SOAP）聯(lián)系。

1、功能分割：

微服務(wù)架構(gòu)本質(zhì)就是單體應(yīng)用進(jìn)行功能分割，形成分布式部署。

分層是橫向邏輯分層，分割是分割是在縱向方面對(duì)軟件進(jìn)行切分，將不同的功能和服務(wù)分割開(kāi)來(lái)，包裝成高內(nèi)聚低耦合的模塊單元，有助于軟件開(kāi)發(fā)和維護(hù)，還便于不同模塊的分布式部署，提高網(wǎng)站的并發(fā)處理能力和功能擴(kuò)展能力。

現(xiàn)在開(kāi)源的微服務(wù)框架比較多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

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

• 擴(kuò)展性好，各個(gè)服務(wù)之間低耦合
• 容易部署，軟件從單一可部署單元，被拆成了多個(gè)服務(wù)，每個(gè)服務(wù)都是可部署單元
• 容易開(kāi)發(fā)，每個(gè)組件都可以進(jìn)行持續(xù)集成式的開(kāi)發(fā)，可以做到實(shí)時(shí)部署，不間斷地升級(jí)
• 易于測(cè)試，可以單獨(dú)測(cè)試每一個(gè)服務(wù)

缺點(diǎn)

• 由于強(qiáng)調(diào)互相獨(dú)立和低耦合，服務(wù)可能會(huì)拆分得很細(xì)。這導(dǎo)致系統(tǒng)依賴大量的微服務(wù)，變得很凌亂和笨重，性能也會(huì)不佳。
• 一旦服務(wù)之間需要通信（即一個(gè)服務(wù)要用到另一個(gè)服務(wù)），整個(gè)架構(gòu)就會(huì)變得復(fù)雜。典型的例子就是一些通用的 Utility 類(lèi)，一種解決方案是把它們拷貝到每一個(gè)服務(wù)中去，用冗余換取架構(gòu)的簡(jiǎn)單性。
• 分布式的本質(zhì)使得這種架構(gòu)很難實(shí)現(xiàn)原子性操作，交易回滾會(huì)比較困難。

2、分布式部署

　　分布式應(yīng)用和服務(wù)：應(yīng)用和服務(wù)模塊分布式部署，便于業(yè)務(wù)功能擴(kuò)展；

　　分布式靜態(tài)資源：JS、CSS、LOGO圖片等資源獨(dú)立部署，采用獨(dú)立域名->動(dòng)靜分離；

　　分布式數(shù)據(jù)和存儲(chǔ)：傳統(tǒng)RDBMS分布式部署和NoSQL產(chǎn)品；

　　分布式計(jì)算：類(lèi)似Hadoop及其MapReduce分布式計(jì)算框架，其特點(diǎn)是移動(dòng)計(jì)算而不是移動(dòng)數(shù)據(jù)。

三、插件架構(gòu)：微核架構(gòu)

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

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

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

• 良好的功能延伸性（extensibility），需要什么功能，開(kāi)發(fā)一個(gè)插件即可
• 功能之間是隔離的，插件可以獨(dú)立的加載和卸載，使得它比較容易部署，
• 可定制性高，適應(yīng)不同的開(kāi)發(fā)需要
• 可以漸進(jìn)式地開(kāi)發(fā)，逐步增加功能

缺點(diǎn)

• 擴(kuò)展性（scalability）差，內(nèi)核通常是一個(gè)獨(dú)立單元，不容易做成分布式
• 開(kāi)發(fā)難度相對(duì)較高，因?yàn)樯婕暗讲寮c內(nèi)核的通信，以及內(nèi)部的插件登記機(jī)制

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

四、事件驅(qū)動(dòng)架構(gòu)：異步

事件（event）是狀態(tài)發(fā)生變化時(shí)，軟件發(fā)出的通知。

事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）就是通過(guò)事件進(jìn)行通信的軟件架構(gòu)。它分成四個(gè)部分。

事件驅(qū)動(dòng)架構(gòu)（event-driven architecture）核心組件：

• 事件隊(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)典型就是消息隊(duì)列的生產(chǎn)者消費(fèi)者模式，兩者不存在直接調(diào)用，只要保持?jǐn)?shù)據(jù)結(jié)構(gòu)不變，彼此功能實(shí)現(xiàn)可以隨意變化而不互相影響，這對(duì)網(wǎng)站擴(kuò)展新功能非常便利。

業(yè)務(wù)之間的消息傳遞不是同步調(diào)用，而是將一個(gè)業(yè)務(wù)操作分成多個(gè)階段，每個(gè)階段之間通過(guò)共享數(shù)據(jù)的方式異步執(zhí)行進(jìn)行協(xié)作。

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

• 分布式的異步架構(gòu)，事件處理器之間高度解耦，軟件的擴(kuò)展性好
• 適用性廣，各種類(lèi)型的項(xiàng)目都可以用
• 性能較好，因?yàn)槭录漠惒奖举|(zhì)，軟件不易產(chǎn)生堵塞
• 事件處理器可以獨(dú)立地加載和卸載，容易部署

缺點(diǎn)

• 涉及異步編程（要考慮遠(yuǎn)程通信、失去響應(yīng)等情況），開(kāi)發(fā)相對(duì)復(fù)雜
• 難以支持原子性操作，因?yàn)槭录ㄟ^(guò)會(huì)涉及多個(gè)處理器，很難回滾
• 分布式和異步特性導(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)（云原生-Cloud Native）

云架構(gòu)（cloud architecture，現(xiàn)在的說(shuō)法是云原生-Cloud Native）主要解決擴(kuò)展性和并發(fā)的問(wèn)題，是最容易擴(kuò)展的架構(gòu)。

它的高擴(kuò)展性，主要原因是可以基于云上計(jì)算資源彈性伸縮。然后，業(yè)務(wù)處理能力封裝成一個(gè)個(gè)處理單元（prcessing unit）。訪問(wèn)量增加，就新建處理單元（Docker容器）；訪問(wèn)量減少，就關(guān)閉處理單元（Docker容器）。由于沒(méi)有中央數(shù)據(jù)庫(kù)，所以擴(kuò)展性的最大瓶頸消失了。由于每個(gè)處理單元的數(shù)據(jù)都獨(dú)立分庫(kù)。

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

• 處理單元：實(shí)現(xiàn)業(yè)務(wù)邏輯（類(lèi)似于微服務(wù)架構(gòu)中的微服務(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)求涉及不同類(lèi)型的處理單元，該中間件負(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)閉處理單元。

隨著Docker、Kubernetes等容器化技術(shù)的快速發(fā)展，上述關(guān)于云架構(gòu)描述有點(diǎn)陳舊了。當(dāng)前最新的云原生架構(gòu)，以Docker+Kubernetes為核心，尤其是容器編排Kubernetes 已經(jīng)成為事實(shí)上的行業(yè)標(biāo)準(zhǔn)。

云原生架構(gòu)圖的主要特征：

• 微服務(wù)應(yīng)用運(yùn)行支撐環(huán)境；
• 以容器化應(yīng)用的鏡像作為交付標(biāo)準(zhǔn)；
• 通過(guò)資源調(diào)度服務(wù)快速申請(qǐng)、釋放資源；
• 通過(guò)彈性伸縮快速擴(kuò)展應(yīng)用；
• 狀態(tài)監(jiān)控；

主要目標(biāo)：

1. 讓開(kāi)發(fā)人員聚焦業(yè)務(wù)邏輯的實(shí)現(xiàn)，其他交給容器云平臺(tái)來(lái)完成；

2. 支持業(yè)務(wù)系統(tǒng)的快速迭代，支撐業(yè)務(wù)的快速變化和發(fā)展；

3. 構(gòu)建以共享服務(wù)體系為核心的業(yè)務(wù)中臺(tái)；

下面是小編針對(duì)某新零售企業(yè)設(shè)計(jì)的云原生架構(gòu)圖，以云和微服務(wù)架構(gòu)為基礎(chǔ)構(gòu)建云原生應(yīng)用，這里云可以是公有云、私有云、混合云等等。

結(jié)束

以上是從不同的視角，對(duì)架構(gòu)進(jìn)行了分類(lèi)。實(shí)際應(yīng)用中，各種架構(gòu)并不是孤立的，可以根據(jù)業(yè)務(wù)環(huán)境和業(yè)務(wù)訴求，對(duì)各種架構(gòu)進(jìn)行綜合和嫁接。每種架構(gòu)都有其優(yōu)點(diǎn)和缺點(diǎn)。優(yōu)點(diǎn)不必多說(shuō)，缺點(diǎn)則幾乎都是通過(guò)工具工程（比如自動(dòng)化發(fā)布工具、自動(dòng)化測(cè)試等等）能力的方法來(lái)規(guī)避，工具工程對(duì)軟件架構(gòu)非常重要。