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