服務器軟件架構(gòu)模式有哪些

這篇文章主要介紹“服務器軟件架構(gòu)模式有哪些”，在日常操作中，相信很多人在服務器軟件架構(gòu)模式有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”服務器軟件架構(gòu)模式有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Singleton（單例模式）、倉儲模式（repository）、工廠模式（factory）、建造者模式（builder）、裝飾模式（decorator）……大概每個上課聽講的程序員都不會陌生——軟件的設計模式為我們提供了針對現(xiàn)有的、重復出現(xiàn)的問題以可靠的解決方案。

在軟件架構(gòu)方面同樣存在類似的機制，通用的、可重用的解決方案在給定上下文中的軟件體系結(jié)構(gòu)中經(jīng)常出現(xiàn)的問題。不同的軟件架構(gòu)模式各有千秋，以下是目前較為主流的5種軟件架構(gòu)模式。

分層模式（Layered Pattern）

分層模式大概是最知名的軟件架構(gòu)模式之一，有大量的開發(fā)者使用，但并不知道它的名字。分層模式將代碼拆分為“層”，每個層都有一定的責任，并為更高“層”服務。

分層模式并沒有規(guī)定層的數(shù)量，但通常會有以下結(jié)構(gòu)：

• 表現(xiàn)層 / UI層

• 應用層

• 業(yè)務/域（domain）層

• 持久/數(shù)據(jù)訪問層

• 數(shù)據(jù)庫層

分層模式的想法是用戶通過執(zhí)行某些動作（例如點擊按鈕）在表現(xiàn)層啟動一段代碼。隨后，表現(xiàn)層調(diào)用應用層、進入業(yè)務層，最后持久層將所有內(nèi)容存儲在數(shù)據(jù)庫中。簡單來說，分層模式中的高層調(diào)用并依賴低層。

根據(jù)應用復雜程度，我們會看到很多相應的變體。例如某些應用會省略應用層，而某些應用會添加緩存層，甚至會出現(xiàn)兩層合一的情況。

層責任

如上所述，每層有每層的責任。表現(xiàn)層包含應用的圖形設計和處理交互的代碼。理論上來講，我們不應該在這一層添加任何與user interface無關(guān)的邏輯。

業(yè)務層是放置特定業(yè)務問題模型和邏輯的地方。

應用層位于業(yè)務層和和表現(xiàn)層之間。一方面為表現(xiàn)層提供業(yè)務層抽象，另一方面為應用層提供放置某些不適合放置于業(yè)務層或表現(xiàn)層的某些協(xié)調(diào)邏輯。

持久層包含訪問數(shù)據(jù)庫層的代碼，而數(shù)據(jù)庫層是底層數(shù)據(jù)庫技術(shù)，例如SQL Server、MongoDB。持久層是用于操作數(shù)據(jù)庫的代碼集：SQL語句、連接詳情等。

優(yōu)勢

• 大多數(shù)開發(fā)者都很熟悉

• 一種用于編寫組織良好并且可測試應用的簡單方法

劣勢

• 分層模式往往會導致應用的“一體化”并使之變得難以拆分

• 開發(fā)者往往會發(fā)現(xiàn)自己編寫了大量的代碼來傳遞不同的層，而沒有在這些層里添加任何值。如果我們做的只是編寫一個簡單的CRUD應用，分層模式可能有點過分了。

適用于

• 標準的、不僅僅用于完成CRUD操作的業(yè)務線（line-of-business）應用

微內(nèi)核模式（Microkernel）

當應用程序有一組核心職責和一組可互換的部件時，微內(nèi)核模式(或插件模式)非常有用。微內(nèi)核將提供應用程序的入口點和一般流程，而不需要真正了解不同的插件在做什么。

例如任務調(diào)度，微內(nèi)核可以包含所有的調(diào)度和觸發(fā)邏輯，而插件負責特定的任務。只要插件遵循特定的API，微內(nèi)核就可以出發(fā)它們，而不需要了解實現(xiàn)的細節(jié)。

另一個例子是工作流。工作流的實現(xiàn)包含諸如不同步驟的順序、評估步驟的結(jié)果、決定下一步的內(nèi)容等概念，步驟的的具體實現(xiàn)對于工作流的核心代碼并不重要。

優(yōu)勢

• 靈活性 & 可擴展性

• 某些實現(xiàn)允許我們在應用運行時添加插件

• 微內(nèi)核和插件可以由不同團隊開發(fā)

劣勢

• 難以確定哪些東西屬于微內(nèi)核

• 預定義的API可能不適合未來的插件

適用于

• 從不同來源獲取數(shù)據(jù)、轉(zhuǎn)換數(shù)據(jù)并寫入不同地方的應用

• 工作流應用

• 任務和作業(yè)調(diào)度應用

命令職責查詢分離模式（CQRS）

CQRS是Command and Query Responsibility Segregation的縮寫。這種模式的核心概念是應用具有完全分離的讀取操作和寫入操作，這也意味著用于寫操作（命令）的模型和讀?。ú樵儯┎煌?。此外，數(shù)據(jù)將存儲在不同的位置。在關(guān)系數(shù)據(jù)庫中，意味著將存在用于命令模型的表和用于讀取模型的表。一些實現(xiàn)甚至將不同的模型存儲在完全不同的數(shù)據(jù)庫中，例如用于命令模型的SQL Server和用于讀取模型的MongoDB。

CQRS模式通常和事件溯源（Event Sourcing）結(jié)合，下一小節(jié)會講到。

CQRS如何工作？當用戶執(zhí)行操作，應用會向命令服務器發(fā)送命令。命令服務從命令數(shù)據(jù)庫中檢索所需的任何數(shù)據(jù)，進行必要的操作并將其存儲回數(shù)據(jù)庫中，然后它通知讀取服務，以便更新讀取模型。如下所示：

當應用需要向用戶顯示數(shù)據(jù)時，它可以通過調(diào)用讀取服務來檢索讀取模型，如下所示：

優(yōu)勢

• 命令模型專注于業(yè)務邏輯和驗證，讀取模型根據(jù)特定情境進行定制

• 可以避免復雜的查詢，讓讀取更高效

劣勢

• 保持命令和讀取模型同步可能會讓事情變得很復雜

適用于

• 需要大量讀取的應用

• 有復雜域的應用

事件溯源模式（Event Sourcing）

這種模式不會將模型的當前狀態(tài)存儲在數(shù)據(jù)庫中，而是將時間存儲其中。因此，例如customer name發(fā)生變化時，該值不會存儲在“name“列中，我們會存儲一個”NameChanged“事件。

當我們需要檢索模型時，我們將檢索其存儲的所有事件并在新對象上重新應用，即rehydrating an object。

用EXCEL記賬來理解event sourcing會容易一些。當我們添加支出時，我們不需更改總值，而是增加一“行”，出現(xiàn)錯誤，也增加一“行”，最終利用EXCEL的公式自動計算出總數(shù)，而這里計算總數(shù)可以看作是讀取模型。

您可以看到我們在添加Invoice 201805時發(fā)生了錯誤。我們添加了兩條新行，而不是更改行，首先是一行取消錯誤的行，然后是新的正確行。這就是event sourcing的工作方式。你永遠不會刪除事件，因為它們無可否認地發(fā)生在過去。為了糾正情況，我們添加了新事件。

另外，請注意我們是如何獲取總值的，它是上面單元格中所有值的總和。在Excel中，它會自動更新，因此我們可以說它與其他單元格同步。這就是一個讀取模型。

Event sourcing通常會與CQRS同時使用，因為rehydrating an object可能會對性能產(chǎn)生影響，尤其是當實例中存在大量事件時。快速讀取模型可以顯著改善應用的響應時間。

優(yōu)勢

• 提供“開箱即用”的audit log，每個事件即特定時間點上的特定操作

劣勢

• event sourcing有一定的限制要求，我們不能直接通過數(shù)據(jù)庫中的簡單編輯來修復錯誤數(shù)據(jù)

• 改變事件的結(jié)構(gòu)比較復雜

適用于

• 需要發(fā)布事件到外部系統(tǒng)的應用

• CQRS應用

• 有復雜域的應用

• 需要數(shù)據(jù)修改audit log的應用

微服務模式（Microservices）

編寫一組微服務實際上就是編寫可以協(xié)同的多個應用。每個微服務都有自己獨特的責任，團隊可以獨立于其他微服務開發(fā)它們。他們之間唯一的依賴是通信。當微服務相互通信時，我們必須確保它們之間發(fā)送的消息保持backwards-compatible（向后兼容）。這需要一些協(xié)調(diào)，特別是當不同的團隊負責不同的微服務時。

如下圖所示——

在上圖中，應用調(diào)用一個中央API，將調(diào)用轉(zhuǎn)發(fā)給正確的微服務。在此示例中，有為用戶配置文件、庫存、訂單和付款提供單獨的服務。我們可以想象這是一個用戶訂購應用。單獨的微服務也可以相互調(diào)用。例如，支付服務可以在支付成功時通知訂單服務。然后，訂單服務可以調(diào)用庫存服務來調(diào)整庫存。

沒有明確規(guī)定微服務有多大。在前面的示例中，用戶配置文件服務可能負責用戶的用戶名和密碼等數(shù)據(jù)，也可能負責家庭地址、頭像圖像、收藏夾等，也可以選擇將所有這些責任分成更小的微服務。

優(yōu)勢

• 我們可以單獨編寫、維護、部署微服務

• 微服務架構(gòu)容易擴展

• 重寫變得很容易，因為微服務之間松耦合

劣勢

• 實際上沒有合適的工具平臺，反而在最初編寫結(jié)構(gòu)良好的一體化應用，再拆分為微服務的辦法實際上更容易。使用微服務，會產(chǎn)生許多額外的問題：通信、協(xié)調(diào)，向后兼容、日志記錄等。沒有編寫結(jié)構(gòu)良好的整體結(jié)構(gòu)的必要技能的團隊可能很難編寫一組良好的微服務。

• 傳統(tǒng)微服務架構(gòu)可能會有多個失敗點，查找問題可能會比較復雜

適用于

• 某些組件被密集使用并需要擴展的應用

• 為其他應用提供功能的應用

• 一體化架構(gòu)下很復雜的應用

• 能夠明確定義bounded contexts的應用

到此，關(guān)于“服務器軟件架構(gòu)模式有哪些”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>