好萊塢電影中有多少情節？一些電影評論家說只有五個。您可以採用幾種架構來實現應用程式？目前大多數程序都使用下面提到的五種架構之一。
在本文中，我將五種軟體架構模式的優缺點以及適合場景提煉出來作為快速參考。你可以在單個系統中使用多個架構模式，它們的組合既是計算機科學，也是一門藝術。
一、分層架構
這種方法可能是最常見的方法，因為它通常圍繞資料庫構建，並且業務中的許多應用程式自然會傾向於將信息存儲在RDBMS的表中。許多比較大的軟體框架（例如Java EE，Drupal和Express）都是在這種架構下實現的，因此使用它們構建的許多應用程式自然都來自分層體系結構。
Model-View-Controller（MVC）分層結構是大多數流行的Web框架提供的標準軟體開發方法，顯然是分層體系結構。數據持久層上方是服務層，它通常包含業務邏輯和有關資料庫中數據類型的信息。視圖層位於頂層，通常是CSS，JavaScript和帶有動態嵌入式代碼的HTML。在中間有一個控制層，該控制層具有用於轉換在視圖和模型之間移動的數據的各種規則和方法。
分層架構的優點：每個層可以只集中於自己的功能實現。這使得應用程式：
容易維護
容易單元測試
易於分配單獨的「角色」
易於更新和擴展
適當的分層體系結構將開發層面進行隔離，這些層不受其他層的更改的影響，從而使重構更加容易。劃分任務並定義單獨的層是架構師面臨的挑戰。當需求很好地適應了模式時，這些層將易於解耦或分層開發。
適合：
需要快速構建的新應用程式
傳統IT部門和流程的企業或業務應用程式
具有尚不了解其他架構的經驗不足的開發人員的團隊
需要嚴格的可維護性和可測試性標準的應用
二、事件驅動架構
事件驅動的體系架構根據數據生成一個「事件」，事件由「消息中間件」或「事件分發管理的中央單元」統一接收，並將事件分配特定類型的代碼處理。
使用JavaScript編程網頁涉及編寫對諸如滑鼠單擊或擊鍵之類的事件做出反應的小模塊。瀏覽器本身會協調所有輸入，並確保只有正確的代碼才能得到正確的事件。瀏覽器中常見許多不同類型的事件，但是模塊僅與相關的事件進行交互。這與分層體系結構非常不同，在分層體系結構中，所有數據通常都將穿過所有層。總體而言，事件驅動的體系結構：
容易適應複雜，混亂的業務環境
當出現新的事件類型時，很容易擴展
注意事項：
如果模塊之間可以相互影響，則[測試可能會很複雜
當模塊發生故障時，中央單元（或消息中間件）必須有一個事件備份計劃。
消息傳遞開銷可能會降低處理速度，消息中間件必須緩衝以突發形式到達的消息時。
當事件有非常不同的需求時，為事件開發數據結構可能會很複雜。
維護基於事務的一致性機制很困難，因為接收事件的模塊是解耦和獨立的。
適合：
具有異步數據流的異步系統
各個數據塊僅與多模塊中的少數模塊交互的應用程式
用戶界面
三、微內核-多插件架構
許多的應用程式都具有一組核心代碼，這些代碼在不同的模塊下反覆使用。例如，開發工具Eclipse將打開文件，批註，編輯文件並啟動後臺處理器。用於顯示文件和對其進行編輯的代碼是微內核的一部分。其他的插件擴展了Eclipse，從而擴展了其功能。
具體到解決方案就是將一些基本的核心的任務代碼推入微內核。然後，不同的業務部門可以根據不同類型的聲明編寫插件。
注意事項：
確定哪些代碼是微內核中的內容通常是一門藝術。它應該保留經常被使用的代碼。
一旦許多插件依賴微內核，修改微內核可能非常困難，甚至不可能。唯一的解決方案就是修改插件。
為內核函數選擇正確的粒度很難事先完成，也幾乎不可能在後期進行更改。
適合：
工具類軟體
在核心代碼與邊緣代碼之間有清晰區分的應用程式
具有一組固定的核心函數和一組動態規則的應用程式
四、微服務架構
小寶寶既可愛又有趣，但是一旦變大，就很難操縱並且難以維護。微服務架構旨在幫助開發人員避免讓自己的寶寶長大，笨拙，僵硬，煩人。它的目標不是創建一個大型程序，而是創建多個不同的小型程序。避免修改一個小bug，就需要重新部署整個大型應用的情況出現。
這種方法類似於事件驅動和微內核方法，但是主要用於解耦不同模塊及任務。在許多情況下，不同的任務可能需要不同的處理量，並且用途可能會有所不同。所以微服務的特點是便於修改、便於擴展。使用負載均衡及服務發現的機制，在用戶使用高峰期部署更多的微服務，保證服務的高可用；在用戶低頻服務時段縮減微服務，從而節省伺服器資源。
注意事項：
並非所有應用程式都可以拆分為相對獨立的微服務單元。
當任務分散在不同的微服務之間時，通信成本會更大。單個請求的響應時長會增加。
適合：
快速發展新業務團隊
大型Web應用程式
五、高速緩存架構
許多網站都是圍繞資料庫構建的，只要資料庫能夠滿足負載，它們就可以正常運行。但是當使用量達到頂峰，並且資料庫無法跟上用戶請求的速度時，整個網站就會癱瘓。將數據存儲在內存中可以使許多工作更快，從而大幅度提高用戶並發訪問的支撐能力。
注意事項：
對於內存資料庫，事務的支持更加困難。
開發專業的高速緩存數據的程序，對程式設計師的技術水平往往要求更高一些（至少比只會寫增刪改查的程式設計師要高）
適合：
高頻點擊數據流和用戶日誌之類的大量數據處理
低價值數據，有時可能會丟失而不會造成重大後果（比如用戶訪問量數據）
讀多寫少的數據。比如新聞數據，寫完之後幾乎不改，但是有很多的人看。