什麼是系統架構(Architecture)前端
設計不只僅指的是外觀和感受，它還包括運做方式。—— 史蒂夫·喬布斯web
系統架構（System Architecture），軟件架構（Soft Architecture）是 IT 領域常見的名詞，架構設計是軟件系統構建過程當中極其關鍵的一部分。數據庫
系統架構爲何重要？常見的架構模式都有哪些？跟着 【碼哥字節】瞭解不一樣的架構設計所運用的不一樣設計哲學。編程
一塊兒來看下常見的架構模式：Client-Server、Peer to Peer、MVC、Layered、Distribute-Cluster、Micro-Service、Even-Source、Hexagonal 逐個擊破。後端
Architecture，原意建築學，其實軟件架構的概念就是源於建築學。建築學是建築物設計和建造相關的藝術和技術的綜合。建築學是一門橫跨工程技術和人文藝術的學科。它研究的是建築物可資使用的空間、可供欣賞的形象，以及圍繞空間、形象如何產生確立、調整美化等的一系列問題。而且其所研究的對象不只是建築物自己，更主要的是研究人們對建築物的要求及其如何得以知足，研究建築物實體從無到有的產生過程當中相應的策劃、設計、實施等。設計模式
建築學研究建築的規劃、設計和實施。軟件架構研究軟件的規劃、設計和實施。api
在架構設計中，根據業務、技術、組織、靈活性、可擴展性以及可維護性等因素，將應用系統劃分紅不一樣的部分，使這些部分之間相互分工、相互協做，從而完成特定的需求。架構貫穿系統實現的整個過程，是軟件系統實現的主要參考，是軟件系統實現的藍圖。軟件系統的規劃、設計和實施依架構的設計而組織實施。瀏覽器
系統架構爲何重要微信
咱們知道摩爾定律——計算機硬件的能力大體每兩年提升一倍的速度發展。然而軟件開發的流程卻沒有這樣的提速過程，開發成本也沒有降低，系統架構的設計方法論和設計模式不斷變化，而這個重要的流程依舊沒有一個徹底可靠和一勞永逸的解決方案。爲何？軟件開發過程有什麼特別的難題？有下面幾點：restful
-
複雜性（Complexity） 軟件能夠說是人類創造的最複雜的系統類型。軟件的各個模塊之間有各類顯性或隱性的依賴關係，隨着系統的成長和模塊的增多，這些關係的數量每每以幾何級數的速度增加。而理解運用這些複雜性的人並無太多的變化。 -
不可見性（Invisibility） 軟件工程師能直接看見源代碼，可是源代碼不是軟件自己。而且靜態的源代碼和運行的系統也不同，軟件運行環境的複雜性也增長了軟件系統的不可預測性。軟件系統不能以簡單的方式描述出來，設計文檔，描述說明，流程圖，架構圖這些也不過是讓複雜的軟件系統以更易於理解和易於交流的方式展現，卻依舊不能徹底描述系統的全貌。 -
易變性（Changeability） 修改軟件看似很容易，修改軟件比修改硬件容易多了，修改軟件系統也比修改一座巍立建築物容易的多。因此人們天然地期待軟件系統可以適應將來的變化。但變化倒是複雜的，環境也是複雜的，這些複雜的狀況每每讓一個易於修改的事情卻變成一件愈來愈困難的事情。 -
服從性（Conformity） 軟件系統不能獨立存在，它老是運行在硬件上面，也老是要服從系統中其餘組成部分的要求，也要服從用戶的要求、行業的要求。
軟件系統的以上特性使得系統架構的設計顯得尤爲重要。系統架構設計經過如下方式來解決上面的軟件難題：
-
抽象 抽象是系統架構設計的重要一步。抽象是將複雜的概念簡單化。在最高層次上，將軟件系統抽象爲對象和過程兩個高層次概念。對象能夠是系統、組件、接口、類、方法等等不一樣層次的概念，過程是系統運行的方式和流程。抽象使具象的事物概念化，從而肯定邊界，易於理解，易於交流。 -
分解 分解與組合相互做用。分解就是將高層次的抽象概念分解成低層次的抽象概念，就是將實體分紅小的部件或組成部分，在應對複雜度的諸多方式中，」分而治之「是一項基本策略，它把大問題持續分解成小問題，直到每個小問題都可以解決爲止。 -
語言 語言的邊界就是世界的邊界。領域語言、設計語言肯定系統的 what、how和why。語言使系統顯見於文檔，設計圖等等易於理解的層次，也使得系統的易變性被規範在可預見和可控制的範圍之中。
幾種架構模式
Client-Server
有了互聯網就有了 client-server 模式。client-server 模式以請求-響應方式工做，客戶端發送請求信息，服務端接受請求，做出相應處理，而後發回響應信息。全部咱們訪問的互聯網網站都是這種架構。在桌面程序流行的時代，互聯網尚未當前這麼發達的時代。Client-Server 還只表明 Desktop Client-Server 模式，使用瀏覽器的方式稱之爲 B-S 模式，即 Browser-Server 模式。現在 Browser、Desktop Application、Mobile Application、Mobile Web 等統稱爲 Client。
所以咱們當前訪問的大部分網站，如新聞諮詢網站、博客網站等等都屬於這種模式。
Peer to Peer
端對端服務模式（Peer to Peer，簡稱 P2P），亦稱爲「點對點模式」，是指經過互聯網將我的與我的鏈接起來，繞開中心平臺而直接提供服務、完成交易的模式。P2P 的早期含意是計算機通訊領域中的「對等網絡協議」，它打破了傳統的 Client/Server(C/S)模式，使得成千上萬臺彼此鏈接的計算機都處於對等地位，網絡的參與者直接共享他們所擁有的一部分硬件資源（包括處理能力、存儲能力、網絡鏈接能力、打印機等），這些共享資源經過互聯網，能被其它對等節點(Peer)直接訪問而無需通過統一的中間體。在該網絡中的參與者既是資源（服務或內容）提供者（Server），又是資源獲取者（Client）。
P2P 模式流行於文件分享與下載、計算與存儲、即時通訊和協同共享等領域。
MVC
Model-View-Controller，MVC 架構是面向對象編程的一大進步。服務將邏輯劃分爲三個不一樣的組建：Model——模型，即數據，一般存儲在數據庫中，在內存中進行邏輯操做。View——用戶可見的組建，用於用戶交互和數據展現，如 Web GUI。Controller——邏輯操做，鏈接 Model 和 View 的組件，操做 Model 邏輯和 View 交互展現邏輯。
MVC 模式在客戶端和 H5 前端都比較流行。也一直是 Web 後端流行的架構模式，在 Java Web 領域催生的 Struts、Spring MVC 等 Web 後臺框架，讓曾經複雜的 Web 開發變成一種異常簡單的開發。
隨着先後端漸漸分離，以前的後臺 MVC 已經將 View 徹底交於前端，先後端經過相關協議通訊，完成 View 數據的傳輸。
Layered
分層架構是運用最爲普遍的架構模式，幾乎每一個軟件系統都須要經過層（Layer）來隔離不一樣的關注點（Concern Point），以此應對不一樣需求的變化，使得這種變化能夠獨立進行。
單一職責原則，是系統設計開發重要的原則。分層架構就時時遵循單一職責原則。不一樣的層次相互隔離，承擔不一樣的職責。
提及分層架構，最讓人熟知的就是經典的三層架構。經典三層架構自頂向下由用戶界面層（User Interface Layer）、業務邏輯層（Business Logic Layer）與數據訪問層（Data Access Layer）組成。三層架構是簡單 Client-Server 架構的升級。
三層架構的經典和流行，以及大量 Web 後臺框架對三層架構的靠近，使得 Web 後臺開發簡單到一個剛剛入門的開發人員就能夠進行 web 開發。也正由於此，使得大部分 web 開發人員的思惟受限於此，從而成爲人人調侃的 CRUD-Boy。隨着 MIS 系統時代的漸遠，三層架構也開始在一些領域沒法成爲「銀彈「。
除去經典的三層架構。在領域驅動設計中，Eric Evans 設計了一種經典的四層架構，其在用戶界面層與業務邏輯層之間引入了新的一層，即應用層（Application Layer）。其他幾層也相應的有所調整。
Distribute-Cluster
之上所提的架構都是在單體架構之下。單體架構和多服務架構是從服務的部署模式、運行模式來考慮。
單體架構有以下優點：
-
易於開發：藉助於開發框架，單體應用的開發及其簡單，開發人員也不多須要考慮系統、部署、網絡等層次的問題。 -
易於測試：單體應用部署在一個進程中，環境簡單。只要服務啓動就能夠測試全部的功能。 -
易於部署：每每只須要將應用打包成一個簡單的包就可。 -
易於水平擴展：只須要將程序包部署多個服務便可。
單體應用的劣勢：
-
維護成本增長：隨着需求的增多，單體系統將愈來愈臃腫，維護的複雜性也將愈來愈大。 -
持續交互週期長：一方面維護困難，另外一方面單體應用在並行開發，並行測試上將十分困難，單體應用十分不適合快速迭代的敏捷開發。 -
擴展性差：因爲臃腫的系統，將致使系統擴展性變難。系統的升級也須要十分謹慎。 -
對新人不友好。
分佈式系統拆分：
隨着互聯網的快速發展，一方面互聯網應用訪問量級大增，數據量大增。另外一方面，應用的迭代速度也不斷變快。單體應用的模式已經不適合互聯網的快速發展。這樣，後臺分佈式集羣架構愈來愈流行。
Micro-Service
微服務並無一個嚴格的定義。如下是 Martin Fowler 描述的微服務：
微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間相互協調、相互配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相溝通（一般基於 HTTP 的 RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立地部署到生產環境。
微服務一般具備如下特性：
-
單一職責：業務獨立，團隊自主。職責單一的服務應該具備核心的領域，高內聚、低耦合，與其餘系統和領域肯定明確的邊界。 -
輕量級通訊：通訊應該簡單，輕量。與語言無關，與平臺無關。 -
獨立性：獨立開發，獨立測試和獨立部署。
一切選擇都是權衡的過程。微服務解決了單體應用的許多問題，天然也會帶來相應的問題。分佈式和集羣的環境是複雜的，基於此的微服務架構也將具備相應的複雜度。
隨着微服務的流行，微服務的不少問題也被愈來愈多的框架和服務解決掉了。咱們以 Spring Cloud 技術棧爲例：
-
SpringBoot：單體服務，快速建立項目，快速集成各類框架，易於測試，易於部署。 -
Feign：微服務獨立部署，經過相關協議通訊。Feign 就是一個簡單的申明式通訊框架，基於 HTTP restful。 -
Eureka：獨立服務愈來愈多，服務實例也愈來愈多。服務治理即是必須的，Eureka 提供高可用的服務註冊和服務發現功能。 -
Ribbon：Feign 只負責通訊，Ribbon 提供客戶端負載均衡，是系統優化的部分。 -
Hystrix：微服務將帶來服務間複雜的依賴關係，分佈式和集羣的複雜度也將帶來許多難以預料的問題。爲防止複雜網絡和複雜系統某一點的問題致使整個系統的雪崩狀態，便有了 Hystrix，Hystrix 是 Spring Cloud 體系中優秀的斷路器，能夠在系統發生問題時進行服務降級，防止總體系統崩潰。 -
Zuul：統一網關，統一網關是以 Facade 模式，對外提供友好的接口，微服務化以後，服務將愈來愈多，愈來愈複雜，爲了下降外部系統調用的複雜度，統一網關就是經常使用解決方案。 -
Config：服務劃分越多，配置將越多，Spring cloud config 提供統一的配置管理。 -
Sleuth：服務監控和治理。監控是複雜系統必需的基礎設施。系統感知、問題發現、性能定位都須要監控的加持。
Even-Source
事件溯源是最新流行一種應用程序體系結構模式。事件源將應用程序進行的狀態更改建模爲事件的不可變序列或「日誌」。事件源不是在現場修改應用程序的狀態，而是將觸發狀態更改的事件存儲在不可變的日誌中，並將狀態更改建模爲對日誌中事件的響應。
CQRS 模式一般基事件溯源模式。在傳統的體系結構中，使用同一數據模型查詢和更新數據庫。這十分簡單，很是適用於基本的 CRUD 操做。可是，在更復雜的應用程序中，此方法會變得難以操做。例如，在讀取方面，應用程序可能執行大量不一樣的查詢，返回具備不一樣形狀的數據傳輸對象 (DTO)。對象映射可能會變得複雜。在寫入方面，模型可能實施複雜驗證和業務邏輯。結果，模型執行太多操做，過分複雜。
CQRS（命令查詢的責任分離 Command Query Responsibility Segregation ）將讀取和寫入操做分紅不一樣的模型，使用 命令 更新數據，並使用 查詢 來讀取數據。
Hexagonal
👉六邊形架構又稱「端口和適配器模式」，是 Alistair Cockburn 提出的一種具備對稱性特徵的架構風格。在這種架構中，系統經過適配器的方式與外部交互，將應用服務與領域服務封裝在系統內部。
六邊形架構由如下三個組件組成：
-
Ports：又能夠分爲輸入端和輸出端，是系統與其餘系統交互的接口。 -
Adapters：與其餘系統的適配層，一方面防止核心系統和領域被外部影響，即防腐;另外一方面方便 api 使用。 -
Domain：應用和模型是程序的核心。
六邊形架構的核心理念是：應用經過"端口"跟外部進行交互。在傳統的分層架構中很容易跨越層間的邊界，把業務邏輯滲透到其它層中去。六邊形架構重要的就是「邊界」和「領域」。六邊形架構的初衷是爲了解決技術與業務系統的解耦合問題，以及技術與技術間的解耦合問題，這一架構從設計模式中來，從業務的實體服務出發，將面向接口的設計具體化的端口協議和適配器實現，服務自身實現獨立性和完備性。
《構建之法——現代工程》鄒欣
《微服務架構與實現》王磊
《領域驅動設計——軟件核心複雜性應對之道》Eric Evans
《實現領域驅動設計》Vaughn Vernon
《Spring Cloud 微服務實戰》翟永超
《工程學——無盡的前沿》歐陽瑩之
《人月神話》Frederick P. Brooks, Jr.
有道無術，術可成；有術無道，止於術
歡迎你們關注Java之道公衆號
好文章，我在看❤️
本文分享自微信公衆號 - Hollis（hollischuang）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。