好萊塢電影中有多少情節(jié)？一些電影評論家說只有五個。您可以采用幾種架構(gòu)來實現(xiàn)應用程序？目前大多數(shù)程序都使用下面提到的五種架構(gòu)之一。

在本文中，我將五種軟件架構(gòu)模式的優(yōu)缺點以及適合場景提煉出來作為快速參考。你可以在單個系統(tǒng)中使用多個架構(gòu)模式，它們的組合既是計算機科學，也是一門藝術(shù)。

一、分層架構(gòu)

這種方法可能是最常見的方法，因為它通常圍繞數(shù)據(jù)庫構(gòu)建，并且業(yè)務(wù)中的許多應用程序自然會傾向于將信息存儲在RDBMS的表中。許多比較大的軟件框架（例如JAVA EE，Drupal和Express）都是在這種架構(gòu)下實現(xiàn)的，因此使用它們構(gòu)建的許多應用程序自然都來自分層體系結(jié)構(gòu)。

Model-View-Controller（MVC）分層結(jié)構(gòu)是大多數(shù)流行的Web框架提供的標準軟件開發(fā)方法，顯然是分層體系結(jié)構(gòu)。數(shù)據(jù)持久層上方是服務(wù)層，它通常包含業(yè)務(wù)邏輯和有關(guān)數(shù)據(jù)庫中數(shù)據(jù)類型的信息。視圖層位于頂層，通常是css，JavaScript和帶有動態(tài)嵌入式代碼的html。在中間有一個控制層，該控制層具有用于轉(zhuǎn)換在視圖和模型之間移動的數(shù)據(jù)的各種規(guī)則和方法。

分層架構(gòu)的優(yōu)點：每個層可以只集中于自己的功能實現(xiàn)。這使得應用程序：

• 容易維護
• 容易單元測試
• 易于分配單獨的“角色”
• 易于更新和擴展

適當?shù)姆謱芋w系結(jié)構(gòu)將開發(fā)層面進行隔離，這些層不受其他層的更改的影響，從而使重構(gòu)更加容易。劃分任務(wù)并定義單獨的層是架構(gòu)師面臨的挑戰(zhàn)。當需求很好地適應了模式時，這些層將易于解耦或分層開發(fā)。

適合：

• 需要快速構(gòu)建的新應用程序
• 傳統(tǒng)IT部門和流程的企業(yè)或業(yè)務(wù)應用程序
• 具有尚不了解其他架構(gòu)的經(jīng)驗不足的開發(fā)人員的團隊
• 需要嚴格的可維護性和可測試性標準的應用

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

事件驅(qū)動的體系架構(gòu)根據(jù)數(shù)據(jù)生成一個“事件”，事件由“消息中間件”或“事件分發(fā)管理的中央單元”統(tǒng)一接收，并將事件分配特定類型的代碼處理。

使用JavaScript編程網(wǎng)頁涉及編寫對諸如鼠標單擊或擊鍵之類的事件做出反應的小模塊。瀏覽器本身會協(xié)調(diào)所有輸入，并確保只有正確的代碼才能得到正確的事件。瀏覽器中常見許多不同類型的事件，但是模塊僅與相關(guān)的事件進行交互。這與分層體系結(jié)構(gòu)非常不同，在分層體系結(jié)構(gòu)中，所有數(shù)據(jù)通常都將穿過所有層?？傮w而言，事件驅(qū)動的體系結(jié)構(gòu)：

• 容易適應復雜，混亂的業(yè)務(wù)環(huán)境
• 當出現(xiàn)新的事件類型時，很容易擴展

注意事項：

• 如果模塊之間可以相互影響，則[測試可能會很復雜
• 當模塊發(fā)生故障時，中央單元（或消息中間件）必須有一個事件備份計劃。
• 消息傳遞開銷可能會降低處理速度，消息中間件必須緩沖以突發(fā)形式到達的消息時。
• 當事件有非常不同的需求時，為事件開發(fā)數(shù)據(jù)結(jié)構(gòu)可能會很復雜。
• 維護基于事務(wù)的一致性機制很困難，因為接收事件的模塊是解耦和獨立的。

適合：

• 具有異步數(shù)據(jù)流的異步系統(tǒng)
• 各個數(shù)據(jù)塊僅與多模塊中的少數(shù)模塊交互的應用程序
• 用戶界面

三、微內(nèi)核-多插件架構(gòu)

許多的應用程序都具有一組核心代碼，這些代碼在不同的模塊下反復使用。例如，開發(fā)工具Eclipse將打開文件，批注，編輯文件并啟動后臺處理器。用于顯示文件和對其進行編輯的代碼是微內(nèi)核的一部分。其他的插件擴展了Eclipse，從而擴展了其功能。

具體到解決方案就是將一些基本的核心的任務(wù)代碼推入微內(nèi)核。然后，不同的業(yè)務(wù)部門可以根據(jù)不同類型的聲明編寫插件。

注意事項：

• 確定哪些代碼是微內(nèi)核中的內(nèi)容通常是一門藝術(shù)。它應該保留經(jīng)常被使用的代碼。
• 一旦許多插件依賴微內(nèi)核，修改微內(nèi)核可能非常困難，甚至不可能。唯一的解決方案就是修改插件。
• 為內(nèi)核函數(shù)選擇正確的粒度很難事先完成，也幾乎不可能在后期進行更改。

適合：

• 工具類軟件
• 在核心代碼與邊緣代碼之間有清晰區(qū)分的應用程序
• 具有一組固定的核心函數(shù)和一組動態(tài)規(guī)則的應用程序

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

小寶寶既可愛又有趣，但是一旦變大，就很難操縱并且難以維護。微服務(wù)架構(gòu)旨在幫助開發(fā)人員避免讓自己的寶寶長大，笨拙，僵硬，煩人。它的目標不是創(chuàng)建一個大型程序，而是創(chuàng)建多個不同的小型程序。避免修改一個小bug，就需要重新部署整個大型應用的情況出現(xiàn)。

這種方法類似于事件驅(qū)動和微內(nèi)核方法，但是主要用于解耦不同模塊及任務(wù)。在許多情況下，不同的任務(wù)可能需要不同的處理量，并且用途可能會有所不同。所以微服務(wù)的特點是便于修改、便于擴展。使用負載均衡及服務(wù)發(fā)現(xiàn)的機制，在用戶使用高峰期部署更多的微服務(wù)，保證服務(wù)的高可用；在用戶低頻服務(wù)時段縮減微服務(wù)，從而節(jié)省服務(wù)器資源。

注意事項：

• 并非所有應用程序都可以拆分為相對獨立的微服務(wù)單元。
• 當任務(wù)分散在不同的微服務(wù)之間時，通信成本會更大。單個請求的響應時長會增加。

適合：

• 快速發(fā)展新業(yè)務(wù)團隊
• 大型Web應用程序

五、高速緩存架構(gòu)

許多網(wǎng)站都是圍繞數(shù)據(jù)庫構(gòu)建的，只要數(shù)據(jù)庫能夠滿足負載，它們就可以正常運行。但是當使用量達到頂峰，并且數(shù)據(jù)庫無法跟上用戶請求的速度時，整個網(wǎng)站就會癱瘓。將數(shù)據(jù)存儲在內(nèi)存中可以使許多工作更快，從而大幅度提高用戶并發(fā)訪問的支撐能力。

注意事項：

• 對于內(nèi)存數(shù)據(jù)庫，事務(wù)的支持更加困難。
• 開發(fā)專業(yè)的高速緩存數(shù)據(jù)的程序，對程序員的技術(shù)水平往往要求更高一些（至少比只會寫增刪改查的程序員要高）

適合：

• 高頻點擊數(shù)據(jù)流和用戶日志之類的大量數(shù)據(jù)處理
• 低價值數(shù)據(jù)，有時可能會丟失而不會造成重大后果（比如用戶訪問量數(shù)據(jù)）
• 讀多寫少的數(shù)據(jù)。比如新聞數(shù)據(jù)，寫完之后幾乎不改，但是有很多的人看。