不可不知的軟件架構模式

有了互聯(lián)網(wǎng)就有了 client-server 模式。client-server 模式以請求-響應方式工作，客戶端發(fā)送請求信息，服務端接受請求，作出相應處理，然后發(fā)回響應信息。所有我們訪問的互聯(lián)網(wǎng)網(wǎng)站都是這種架構。在桌面程序流行的時代，互聯(lián)網(wǎng)還沒有當前這么發(fā)達的時代。Client-Server 還只代表 Desktop Client-Server 模式，使用瀏覽器的方式稱之為 B-S 模式，即 Browser-Server 模式。如今 Browser、Desktop Application、Mobile Application、Mobile Web 等統(tǒng)稱為 Client。

因此我們當前訪問的大部分網(wǎng)站，如新聞咨詢網(wǎng)站、博客網(wǎng)站等等都屬于這種模式。

Peer to Peer

端對端服務模式（Peer to Peer，簡稱 P2P），亦稱為“點對點模式”，是指通過互聯(lián)網(wǎng)將個人與個人連接起來，繞開中心平臺而直接提供服務、完成交易的模式。P2P 的早期含意是計算機通信領域中的“對等網(wǎng)絡協(xié)議”，它打破了傳統(tǒng)的 Client/Server(C/S)模式，使得成千上萬臺彼此連接的計算機都處于對等地位，網(wǎng)絡的參與者直接共享他們所擁有的一部分硬件資源（包括處理能力、存儲能力、網(wǎng)絡連接能力、打印機等），這些共享資源通過互聯(lián)網(wǎng)，能被其它對等節(jié)點(Peer)直接訪問而無需經過統(tǒng)一的中間體。在該網(wǎng)絡中的參與者既是資源（服務或內容）提供者（Server），又是資源獲取者（Client）。

P2P 模式流行于文件分享與下載、計算與存儲、即時通信和協(xié)同共享等領域。

MVC

Model-View-Controller，MVC 架構是面向對象編程的一大進步。服務將邏輯劃分為三個不同的組建：Model——模型，即數(shù)據(jù)，通常存儲在數(shù)據(jù)庫中，在內存中進行邏輯操作。View——用戶可見的組建，用于用戶交互和數(shù)據(jù)展示，如 Web GUI。Controller——邏輯操作，連接 Model 和 View 的組件，操作 Model 邏輯和 View 交互展示邏輯。

MVC 模式在客戶端和 H5 前端都比較流行。也一直是 Web 后端流行的架構模式，在 Java Web 領域催生的 Struts、Spring MVC 等 Web 后臺框架，讓曾經復雜的 Web 開發(fā)變成一種異常簡單的開發(fā)。

隨著前后端漸漸分離，之前的后臺 MVC 已經將 View 完全交于前端，前后端通過相關協(xié)議通信，完成 View 數(shù)據(jù)的傳輸。

Layered

分層架構是運用最為廣泛的架構模式，幾乎每個軟件系統(tǒng)都需要通過層（Layer）來隔離不同的關注點（Concern Point），以此應對不同需求的變化，使得這種變化可以獨立進行。

單一職責原則，是系統(tǒng)設計開發(fā)重要的原則。分層架構就時時遵循單一職責原則。不同的層次相互隔離，承擔不同的職責。

說起分層架構，最讓人熟知的就是經典的三層架構。經典三層架構自頂向下由用戶界面層（User Interface Layer）、業(yè)務邏輯層（Business Logic Layer）與數(shù)據(jù)訪問層（Data Access Layer）組成。三層架構是簡單 Client-Server 架構的升級。

三層架構的經典和流行，以及大量 Web 后臺框架對三層架構的靠近，使得 Web 后臺開發(fā)簡單到一個剛剛入門的開發(fā)人員就可以進行 web 開發(fā)。也正因為此，使得大部分 web 開發(fā)人員的思維受限于此，從而成為人人調侃的 CRUD-Boy。隨著 MIS 系統(tǒng)時代的漸遠，三層架構也開始在一些領域無法成為“銀彈“。

除去經典的三層架構。在領域驅動設計中，Eric Evans 設計了一種經典的四層架構，其在用戶界面層與業(yè)務邏輯層之間引入了新的一層，即應用層（Application Layer）。其余幾層也相應的有所調整。

Distribute-Cluster

之上所提的架構都是在單體架構之下。單體架構和多服務架構是從服務的部署模式、運行模式來考慮。

單體架構有如下優(yōu)勢：

• 易于開發(fā)：借助于開發(fā)框架，單體應用的開發(fā)及其簡單，開發(fā)人員也很少需要考慮系統(tǒng)、部署、網(wǎng)絡等層次的問題。
• 易于測試：單體應用部署在一個進程中，環(huán)境簡單。只要服務啟動就可以測試所有的功能。
• 易于部署：往往只需要將應用打包成一個簡單的包就可。
• 易于水平擴展：只需要將程序包部署多個服務即可。

單體應用的劣勢：

• 維護成本增加：隨著需求的增多，單體系統(tǒng)將越來越臃腫，維護的復雜性也將越來越大。
• 持續(xù)交互周期長：一方面維護困難，另一方面單體應用在并行開發(fā)，并行測試上將十分困難，單體應用十分不適合快速迭代的敏捷開發(fā)。
• 擴展性差：由于臃腫的系統(tǒng)，將導致系統(tǒng)擴展性變難。系統(tǒng)的升級也需要十分謹慎。
• 對新人不友好。

分布式系統(tǒng)拆分：

隨著互聯(lián)網(wǎng)的快速發(fā)展，一方面互聯(lián)網(wǎng)應用訪問量級大增，數(shù)據(jù)量大增。另一方面，應用的迭代速度也不斷變快。單體應用的模式已經不適合互聯(lián)網(wǎng)的快速發(fā)展。這樣，后臺分布式集群架構越來越流行。

Micro-Service

微服務并沒有一個嚴格的定義。以下是 Martin Fowler 描述的微服務：

微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間相互協(xié)調、相互配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常基于 HTTP 的 RESTful API）。每個服務都圍繞著具體業(yè)務進行構建，并且能夠被獨立地部署到生產環(huán)境。

微服務通常具有以下特性：

• 單一職責：業(yè)務獨立，團隊自主。職責單一的服務應該具有核心的領域，高內聚、低耦合，與其他系統(tǒng)和領域確定明確的邊界。
• 輕量級通信：通信應該簡單，輕量。與語言無關，與平臺無關。
• 獨立性：獨立開發(fā)，獨立測試和獨立部署。

一切選擇都是權衡的過程。微服務解決了單體應用的許多問題，自然也會帶來相應的問題。分布式和集群的環(huán)境是復雜的，基于此的微服務架構也將具有相應的復雜度。

隨著微服務的流行，微服務的很多問題也被越來越多的框架和服務解決掉了。我們以 Spring Cloud 技術棧為例：

• SpringBoot：單體服務，快速創(chuàng)建項目，快速集成各種框架，易于測試，易于部署。
• Feign：微服務獨立部署，通過相關協(xié)議通信。Feign 就是一個簡單的申明式通信框架，基于 HTTP restful。
• Eureka：獨立服務越來越多，服務實例也越來越多。服務治理便是必須的，Eureka 提供高可用的服務注冊和服務發(fā)現(xiàn)功能。
• Ribbon：Feign 只負責通信，Ribbon 提供客戶端負載均衡，是系統(tǒng)優(yōu)化的部分。
• Hystrix：微服務將帶來服務間復雜的依賴關系，分布式和集群的復雜度也將帶來許多難以預料的問題。為防止復雜網(wǎng)絡和復雜系統(tǒng)某一點的問題導致整個系統(tǒng)的雪崩狀態(tài)，便有了 Hystrix，Hystrix 是 Spring Cloud 體系中優(yōu)秀的斷路器，可以在系統(tǒng)發(fā)生問題時進行服務降級，防止整體系統(tǒng)崩潰。
• Zuul：統(tǒng)一網(wǎng)關，統(tǒng)一網(wǎng)關是以 Facade 模式，對外提供友好的接口，微服務化之后，服務將越來越多，越來越復雜，為了降低外部系統(tǒng)調用的復雜度，統(tǒng)一網(wǎng)關就是常用解決方案。
• Config：服務劃分越多，配置將越多，Spring cloud config 提供統(tǒng)一的配置管理。
• Sleuth：服務監(jiān)控和治理。監(jiān)控是復雜系統(tǒng)必需的基礎設施。系統(tǒng)感知、問題發(fā)現(xiàn)、性能定位都需要監(jiān)控的加持。

Even-Source

事件溯源是最新流行一種應用程序體系結構模式。事件源將應用程序進行的狀態(tài)更改建模為事件的不可變序列或“日志”。事件源不是在現(xiàn)場修改應用程序的狀態(tài)，而是將觸發(fā)狀態(tài)更改的事件存儲在不可變的日志中，并將狀態(tài)更改建模為對日志中事件的響應。

CQRS 模式通?；录菰茨Ｊ?。在傳統(tǒng)的體系結構中，使用同一數(shù)據(jù)模型查詢和更新數(shù)據(jù)庫。這十分簡單，非常適用于基本的 CRUD 操作。但是，在更復雜的應用程序中，此方法會變得難以操作。例如，在讀取方面，應用程序可能執(zhí)行大量不同的查詢，返回具有不同形狀的數(shù)據(jù)傳輸對象 (DTO)。對象映射可能會變得復雜。在寫入方面，模型可能實施復雜驗證和業(yè)務邏輯。結果，模型執(zhí)行太多操作，過度復雜。

CQRS（命令查詢的責任分離 Command Query Responsibility Segregation ）將讀取和寫入操作分成不同的模型，使用 命令 更新數(shù)據(jù)，并使用 查詢 來讀取數(shù)據(jù)。

Hexagonal

六邊形架構又稱“端口和適配器模式”，是 Alistair Cockburn 提出的一種具有對稱性特征的架構風格。在這種架構中，系統(tǒng)通過適配器的方式與外部交互，將應用服務與領域服務封裝在系統(tǒng)內部。

六邊形架構由以下三個組件組成：

• Ports：又可以分為輸入端和輸出端，是系統(tǒng)與其他系統(tǒng)交互的接口。
• Adapters：與其他系統(tǒng)的適配層，一方面防止核心系統(tǒng)和領域被外部影響，即防腐;另一方面方便 api 使用。
• Domain：應用和模型是程序的核心。

六邊形架構的核心理念是：應用通過"端口"跟外部進行交互。在傳統(tǒng)的分層架構中很容易跨越層間的邊界，把業(yè)務邏輯滲透到其它層中去。六邊形架構重要的就是“邊界”和“領域”。六邊形架構的初衷是為了解決技術與業(yè)務系統(tǒng)的解耦合問題，以及技術與技術間的解耦合問題，這一架構從設計模式中來，從業(yè)務的實體服務出發(fā)，將面向接口的設計具體化的端口協(xié)議和適配器實現(xiàn)，服務自身實現(xiàn)獨立性和完備性。

參考：

《系統(tǒng)架構——復雜系統(tǒng)的產品設計與開發(fā)》丹尼爾·塞爾瓦
《構建之法——現(xiàn)代工程》鄒欣
《微服務架構與實現(xiàn)》王磊
《領域驅動設計——軟件核心復雜性應對之道》Eric Evans
《實現(xiàn)領域驅動設計》Vaughn Vernon
《Spring Cloud 微服務實戰(zhàn)》翟永超
《工程學——無盡的前沿》歐陽瑩之
《人月神話》Frederick P. Brooks, Jr.