無意中在瀏覽文章的時候，發現了這樣的一張圖

 

沒什么大不了的，就是一個網站的系統架構設計，很簡單，一目了然，但是可能小編比較能瞎想呀，由此聯想到很多東西，比如架構設計體系

大家有沒有考慮過達到企業規模的軟件系統該如何設計呢（已經是這個層次的大佬，膜拜）？在開始寫代碼之前，我們需要選擇一個合適的架構，這個架構將決定軟件實施過程中的功能屬性和質量屬性。因此，了解軟件設計中的不同架構模式對我們的軟件設計會有較大的幫助。

 

但是，在進行這個話題之前，基礎的東西我們應該知道呀，往下看

什么是架構和架構本質

　　在軟件行業，對于什么是架構，都有很多的爭論，每個人都有自己的理解。 此君說的架構和彼君理解的架構未必是一回事。

　　我們主要針對互聯網服server系統（類似網站）來定義架構：架構是系統的骨架，支撐和鏈接各個部分，包括組件、連接件、約束規范，以及指導這些內容設計與演化的原理。

　　組件：類似應用服務，獨立模塊、數據庫、Nginx等等、

　　連接件：分布式調用、進程間調用、調用使用http協議還是tcp協議、組件之間的交互關系、

　　約束規范： 定規則做限制：例如設計原則、編碼規范等等。

　　是系統性的思考，權衡利弊之后在現有資源約束下的“最合理決策”，并有它來指導團隊中的每個人思想層面上的一致。

　　即架構=組件+交互。

　　這類似建筑設計規劃，城市總體規劃等，其實就是架構，只是應用的場景不同。蓋一座小房子，可以拍腦袋干起來，但是當你要蓋一座大樓，如果沒有一個建筑設計規劃，可以想象搭理最后是什么樣？

　　架構的本質就是對系統進行有序化地重構以致符合當前業務的發展，并可以快速擴展。

　　那什么樣的系統要考慮做架構設計?

　　1. 需求相對復雜.

　　2. 非功能性需求在整個系統占據重要位置.

　　3. 系統生命周期長,有擴展性需求.

　　4.系統基于組件或者集成的需要.

　　5.業務流程再造的需要.

　　2、架構分類

　　架構可細分為業務架構、應用架構、技術架構, 代碼架構, 部署架構,.

　　

 

　　業務架構是戰略，應用架構是戰術，技術架構是裝備。其中應用架構承上啟下，一方面承接業務架構的落地，另一方面影響技術選型。

　　熟悉業務，形成業務架構，根據業務架構，做出相應的應用架構，最后技術架構落地實施。

　　如何針對當前需求，選擇合適的應用架構，如何面向未來，保證架構平滑過渡，這個是軟件開發者，特別是架構師，都需要深入思考的問題。

　　一、業務架構（俯視架構）：

　　包括業務規劃，業務模塊、業務流程，對整個系統的業務進行拆分，對領域模型進行設計，把現實的業務轉化成抽象對象。

　　沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題為最終目標，脫離實際業務的技術情懷架構往往會給系統帶入大坑，任何不基于業務做異想天開的架構都是耍流氓。

　　所有問題的前提要搞清楚我們今天面臨的業務量有多大，增長走勢是什么樣，而且解決高并發的過程，一定是一個循序漸進逐步的過程。 合理的架構能夠提前預見業務發展1~2年為宜。這樣可以付出較為合理的代價換來真正達到技術引領業務成長的效果。

　　看看京東業務架構（網上分享圖）：

　　

 

　　二、應用架構（剖面架構，也叫邏輯架構圖）：

　　硬件到應用的抽象，包括抽象層和編程接口。應用架構和業務架構是相輔相成的關系。業務架構的每一部分都有應用架構。

　　類似：

　　

 

　　應用架構：應用作為獨立可部署的單元，為系統劃分了明確的邊界，深刻影響系統功能組織、代碼開發、部署和運維等各方面. 應用架構定義系統有哪些應用、以及應用之間如何分工和合作。這里所謂應用就是各個邏輯模塊或者子系統。

　　應用架構圖關鍵有2點：

　　1、職責劃分: 明確應用（各個邏輯模塊或者子系統）邊界

　　1）邏輯分層

　　2）子系統、模塊定義。

　　3）關鍵類。

　　2、職責之間的協作：

　　1）接口協議：應用對外輸出的接口。

　　2）協作關系：應用之間的調用關系。

　　應用分層有兩種方式：

　　一種是水平分（橫向），按照功能處理順序劃分應用，比如把系統分為web前端/中間服務/后臺任務，這是面向業務深度的劃分。

　　另一種是垂直分（縱向），按照不同的業務類型劃分應用，比如進銷存系統可以劃分為三個獨立的應用，這是面向業務廣度的劃分。

　　應用的合反映應用之間如何協作，共同完成復雜的業務case，主要體現在應用之間的通訊機制和數據格式，通訊機制可以是同步調用/異步消息/共享DB訪問等，數據格式可以是文本/XML/JSON/二進制等。

　　應用的分偏向于業務，反映業務架構，應用的合偏向于技術，影響技術架構。分降低了業務復雜度，系統更有序，合增加了技術復雜度，系統更無序。

　　應用架構的本質是通過系統拆分，平衡業務和技術復雜性，保證系統形散神不散。

　　系統采用什么樣的應用架構，受業務復雜性影響，包括企業發展階段和業務特點；同時受技術復雜性影響，包括IT技術發展階段和內部技術人員水平。業務復雜性（包括業務量大）必然帶來技術復雜性，應用架構目標是解決業務復雜性的同時，避免技術太復雜，確保業務架構落地。

　　三、代碼架構（也叫開發架構）：

　　子系統代碼架構主要為開發人員提供切實可行的指導，如果代碼架構設計不足，就會造成影響全局的架構設計。比如公司內不同的開發團隊使用不同的技術棧或者組件，結果公司整體架構設計就會失控。

　　代碼架構主要定義：

　　一、代碼單元:

　　1、配置設計

　　2、框架、類庫。

　　二、代碼單元組織：

　　1、編碼規范，編碼的慣例。

　　2、項目模塊劃分

　　3、頂層文件結構設計，比如mvc設計。

　　4、依賴關系

　　四、技術架構，也可以叫系統架構

　　技術架構：確定組成應用系統的實際運行組件（lvs，nginx，Tomcat，php-fpm等），這些運行組件之間的關系，以及部署到硬件的策略。

　　技術架構主要考慮系統的非功能性特征，對系統的高可用、高性能、擴展、安全、伸縮性、簡潔等做系統級的把握。

　　系統架構的設計要求架構師具備軟件和硬件的功能和性能的過硬知識，這也是架構設計工作中最為困難的工作。

　　

 

　　五、部署拓撲架構圖（實際物理架構圖）：

　　拓撲架構，包括架構部署了幾個節點，節點之間的關系，服務器的高可用，網路接口和協議等，決定了應用如何運行，運行的性能，可維護性，可擴展性，是所有架構的基礎。這個圖主要是運維工程師主要關注的對象。

　　

 

　　應用架構

　　架構演進路程：

　　->初始階段：LAMP,部署在一臺服務器

　　->應用服務器和數據服務器分離

　　->使用緩存改善性能

　　->使用集群改善并發

　　->數據庫的讀寫分離

　　->使用反向代理和cdn加速

　　->使用分布式文件和分布式數據庫

　　->業務拆分

　　->分布式服務

　　

 

　　業務架構是生產力，應用架構是生產關系，技術架構是生產工具。業務架構決定應用架構，應用架構需要適配業務架構，并隨著業務架構不斷進化，同時應用架構依托技術架構最終落地。

　　企業一開始業務比較簡單，比如進銷存，此時面向內部用戶，提供簡單的信息管理系統（MIS），支持數據增刪改查即可，單體應用可以滿足要求。

　　隨著業務深入，進銷存每塊業務都變復雜，同時新增客戶關系管理，以更好支持營銷，業務的深度和廣度都增加，這時需要對系統按照業務拆分，變成一個分布式系統。

　　更進一步，企業轉向互聯網+戰略，拓展在線交易，線上系統和內部系統業務類似，沒必要重做一套，此時把內部系統的邏輯做服務化改造，同時供線上線下系統使用，變成一個簡單的SOA架構。

　　緊接著業務模式越來越復雜，訂單、商品、庫存、價格每塊玩法都很深入，比如價格區分會員等級，訪問渠道（無線還是PC），銷售方式（團購還是普通）等，還有大量的價格促銷，這些規則很復雜，容易相互沖突，需要把分散到各個業務的價格邏輯進行統一管理，以基礎價格服務的方式透明地提供給上層應用，變成一個微內核的SOA架構。

　　同時不管是企業內部用戶，還是外部顧客所需要的功能，都有很多細分的應用提供支持，需要提供portal，集成相關應用，為不同用戶提供統一視圖，頂層變成一個AOA的架構（Application orientated architecture）。

　　衡量架構的合理性

　　架構為業務服務，沒有最優的架構，只有最合適的架構， 架構始終以高效，穩定，安全為目標來衡量其合理性。

　　一、穩定性。指標：

　　1. 高可用：要盡可能的提高軟件的可用性，我想每個操作人都不愿意看到自己的工作無法正常進行。黑盒白盒測試、單元測試、自動化測試、故障注入測試、提高測試覆蓋率等方式來一步一步推進。

　　二、高效指標：

　　1. 文檔化：不管是整體還是部分的整個生命周期內都必須做好文檔化，變動的來源包括但不限于BUG，需求。

　　2. 可擴展：軟件的設計秉承著低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和運用技術的迭代，并且支持在適時對架構做出重構。

　　3. 高復用：為了避免重復勞動，為了降低成本，我們希望能夠重用之前的代碼、之前的設計。這點對于架構環境的依賴是最大的。

　　三、安全指標

　　1. 安全：組織的運作過程中產生的數據都是具有商業價值的，保證數據的安全也是刻不容緩的一部分。以免出現XX門之類丑聞。加密、https等為普遍手段

　　常見架構誤區

　　誤區1——架構專門有架構師來做，業務開發人員無需關注：架構的再好，最終還是需要代碼來落地，并且組織越大這個落地的難度越大。不單單是系統架構，每個解決方案每個項目也有自己的架構，如分層、設計模式等。如果每一塊磚瓦不夠堅固，那么整個系統還是會有崩塌的風險。所謂“千里之堤，潰于蟻穴”。

　　誤區2——架構師確定了架構藍圖之后任務就結束了：架構不是“空中樓閣”，最終還是要落地的，但是架構師完全不去深入到第一線怎么知道“地”在哪？怎么才能落的穩穩當當。

　　誤區3——不做出完美的架構設計不開工：世上沒有最好架構，只有最合適的架構。我們需要的不是一下子造出一輛汽車，而是從單輪車 --> 自行車 --> 摩托車，最后再到汽車。想象一下2年后才能造出的產品，當初市場還存在嗎？

但是，就像在JAVA開發的過程中有設計模式進行參考一樣，難道架構設計就是大家一拍腦門就出來的嘛？那肯定不是啊，繼續看

軟件架構模式

什么是架構模式？根據維基百科：架構模式是針對特定軟件架構場景常見問題的通用、可重用解決方案。架構模式類似于軟件設計模式，但范圍更廣。本文將簡要解釋10種常見架構模式及其用法、優缺點。

• 分層模式（Layered pattern）
• 客戶端-服務器模式（Client-server pattern）
• 主從模式（Master-slave pattern）
• 管道-過濾器模式（Pipe-filter pattern）
• 代理模式（Broker pattern）
• 點對點模式（Peer-to-peer pattern）
• 事件-總線模式（Event-bus pattern）
• 模型-視圖-控制器模式（Model-view-controller pattern）
• 黑板模式（Blackboard pattern）
• 解釋器模式（Interpreter pattern）

1. 分層模式

此模式用于可分解為子任務的結構化程序，每個子任務都位于特定的抽象層級，每一層都為上一層提供服務。一般信息系統最常見的4個層次如下。

• 表示層(也稱為UI層)
• 應用層(也稱為服務層)
• 業務邏輯層(也稱為領域層)
• 數據訪問層(也稱為持久層)

應用場景：

• 一般的桌面應用程序
• 電子商務web應用程序
• 一般的移動App

 

2. 客戶端-服務器模式

這種模式由兩部分組成：服務器和多個客戶端。服務器將向多個客戶端提供服務。客戶端從服務器請求服務，服務器向這些客戶端提供相關服務。此外，服務器繼續偵聽客戶端請求。

應用場景：

• 電子郵件、文檔共享和銀行等在線應用程序。
• 基于IPC的應用程序

 

3.主從模式

這種模式由兩部分組成：主節點和從節點。主節點將工作分配給相同的從節點，并根據從節點返回的結果計算最終結果。

應用場景：

• 在數據庫復制中，主數據庫被視為權威源數據庫，從數據庫與之同步。
• 通過總線連接到計算機系統(主驅動器和從驅動器)的外圍設備。
• 進程內的多線程應用。

 

4.管道-過濾器模式

這種模式可用于構造生成和處理數據流的系統。每個處理步驟都包含一個過濾器組件。要處理的數據通過管道傳遞。這些管道可用于緩沖或同步目的。

應用場景：

• 編譯器。連續過濾器執行詞法分析、詞法解析、語義分析和代碼生成。
• 生物信息學的工作流
• 工具鏈式的應用程序

 

5. 代理模式

這種模式通過解耦組件來構造分布式系統。這些組件可以通過遠程服務調用彼此交互。代理組件負責協調組件之間的通信。服務器向代理發布功能(服務和特征)。客戶端向代理請求服務，然后代理將客戶端重定向到合適的服務。需要注意broker，agent，proxy以及delegate的區別。

應用場景：

• 消息代理軟件，例如：Apache ActiveMQ、Apache Kafka、RabbitMQ和JBoss消息傳遞。
• 網絡傳輸中的代理軟件。

 

6. P2P模式

在這種模式中，每個組件都稱為對等節點。對等節點既可以作為客戶機(從其他對等節點請求服務)，也可以作為服務器(向其他對等節點提供服務)。對等節點可以充當單個客戶機或服務器，也可以同時充當客戶機和服務器，并且可以隨著時間變化動態地更改角色。

使用場景：

• 文件共享網絡，例如Gnutella和G2等。
• 多媒體協議，如P2PTV和PDTP。

 

7. 事件-總線模式

這種模式也被稱為訂閱發布模式，主要處理事件，有4個主要組件：事件源、事件監聽者、通道和事件總線。事件源將消息發布到事件總線上的特定通道，監聽者訂閱特定的通道。消息發布到監聽者之前訂閱的通道，監聽者將收到消息的通知。

使用場景：

• Android/ target=_blank class=infotextkey>安卓開發
• 通知服務
• 注冊中心

 

8. 模型-視圖-控制器模式

這種模式，也稱為MVC模式，將一個交互應用程序分為三個部分：

• 模型-包含核心功能和數據
• 視圖——向用戶顯示信息(可以定義多個視圖)
• 控制器——處理來自用戶的輸入

這樣做是為了將信息的內部表示、信息呈現給用戶的方式、接受用戶輸入的方式分離開來。這種模式解耦組件并允許有效的代碼重用。

應用場景：

• 一般的web應用程序架構
• Django和Rails等Web框架
• 一般的GUI 應用程序

 

9. 黑板模式

這種模式對于沒有確定解決方案策略的問題非常有用。黑板圖案由三個主要部分組成：

• 黑板：一個結構化的全局內存，包含來自解決方案空間的對象
• 知識源：具有自己表示形式的專門化模塊
• 控制組件：選擇、配置和執行模塊

所有的組件都可以到達黑板。組件可以生成添加到黑板上的新數據對象。組件在黑板上查找特定類型的數據，并通過與現有的知識源進行模式匹配找到這些數據。

應用場景：

• 語音識別
• 車輛識別及追蹤
• 蛋白質結構識別
• 聲納信號的解釋

 

10. 解釋器模式

這種模式用于設計一個解釋專用語言編寫的程序組件。它主要指定如何評估每一行程序，即用特定語言編寫的句子或表達式。其基本思想是語言的每個符號都有一個類。

應用場景：

• 數據庫查詢語言，如SQL。
• 用于描述通信協議的語言。

 

好了，今天的內容，基本就到這里結束了

覺得寫的還不錯的，歡迎點贊+關注支持一下小編，后期會不斷更新，需要相關資料的，轉發后私信“資料”即可，謝謝

最后，給大家推薦幾本書，有我自己看過的，有我老大推薦給我的，希望對各位能有所幫助

　　架構書籍推薦

　　1. 《大型網站技術架構：核心原理與案例分析》

　　這是比較早，比較系統介紹大型網站技術架構的書，通俗易懂又充滿智慧，即便你之前完全沒接觸過網站開發，通讀前幾章，也能快速獲取到常見的網站技術架構及其應用場景。非常贊。

　　2. 《億級流量網站架構核心技術》

　　相比《大型網站技術架構》的高屋建瓴，開濤的這本《億級流量網站架構核心技術》則落實到細節，網站架構中常見的各種技術，比如緩存、隊列、線程池、代理……，統統都講到了，而且配有核心代碼。甚至連 Nginx 的配置都有！

　　如果你想在實現大流量網站時找參考技術和代碼，這本書最合適啦。

　　3. 《架構即未來》

　　這是一本“神書”啦，超越具體技術層面，著重剖析架構問題的根源，幫助我們弄清楚應該以何種方式管理、領導、組織和配置團隊。

　　4. 《分布式服務架構：原理、設計與實戰》

　　這本書全面介紹了分布式服務架構的原理與設計，并結合作者在實施微服務架構過程中的實踐經驗，總結了保障線上服務健康、可靠的最佳方案，是一本架構級、實戰型的重量級著作。

　　5. 《聊聊架構》

　　這算是架構方面的一本神書了，從架構的原初談起，從業務的拆分談起，談到架構的目的，架構師的角色，架構師如何將架構落地……強烈推薦。

　　不過，對于沒有架構實踐經驗的小伙伴來講，可能會覺得這本書比較虛，概念多，實戰少。但如果你有過一兩個項目的架構經驗，就會深深認同書中追本溯源探討的架構理念。

　　6. 《軟件架構師的12項修煉》

　　大多數時候所謂的“技術之玻璃天花板”其實只是缺乏軟技能而已。這些技能可以學到，缺乏的知識可以通過決定改變的努力來彌補。

　　想了解獲取的可以轉發關注小編，私信小編“學習”來免費獲取吧！

　　1 SpringBoot+ 高并發消息處理 EDM?項目 實戰

　　2 SpringBoot ELK?分布式 數據分析

　　3 Netty?高 并發 UTS?項目實戰