架構設計——全面詳細談談架構

時間 2019-11-30

標籤架構設計全面詳細談談欄目系統架構简体版

原文原文鏈接

【3折購買ECS服務器入口】https://promotion.aliyun.com/ntms/act/qwbk.html?userCode=t9686fzw
html

【9塊9雲服務學生計劃】https://promotion.aliyun.com/ntms/act/campus2018.html?userCode=g6nivc1v前端

一、什麼是架構和架構本質

在軟件行業，對於什麼是架構，都有不少的爭論，每一個人都有本身的理解。此君說的架構和彼君理解的架構未必是一回事。 nginx

LInux有架構，MySQL有架構，JVM也有架構，使用Java開發、MySQL存儲、跑在Linux上的業務系統也有架構，應該關注哪個？想要清楚以上問題須要梳理幾個有關係又類似的概念：系統與子系統、模塊與組建、框架與架構: web

1、系統與子系統

系統：泛指由一羣有關聯的個體組成，根據某種規則運做，能完成個別元件不能獨立完成的工做能力的羣體。子系統：也是由一羣關聯的個體組成的系統，多半是在更大的系統中的一部分。 sql

2、模塊與組件

都是系統的組成部分，從不一樣角度拆分系統而已。模塊是邏輯單元，組件是物理單元。數據庫

3、框架與架構

框架是組件的規範，例如：MVC、MVP、MVVM等，是提供基礎功能的產品，例如：Ruby on Rails、Spring、Laravel、Django等。編程

框架是規範，架構是結構。設計模式

我在這從新定義架構：軟件架構指軟件系統的頂層結構。 緩存

架構是通過系統性地思考, 權衡利弊以後在現有資源約束下的最合理決策, 最終明確的系統骨架: 包括子系統, 模塊, 組件. 以及他們之間協做關係, 約束規範, 指導原則. 並由它來指導團隊中的每一個人思想層面上的一致

這相似建築設計規劃，城市整體規劃等，其實就是架構，只是應用的場景不一樣。蓋一座小房子，能夠拍腦殼幹起來，可是當你要蓋一座大樓，若是沒有一個建築設計規劃，能夠想象搭理最後是什麼樣？

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

那什麼樣的系統要考慮作架構設計?

需求相對複雜.
非功能性需求在整個系統佔據重要位置.
系統生命週期長,有擴展性需求.
系統基於組件或者集成的須要.
業務流程再造的須要.

二、架構分類

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

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

熟悉業務，造成業務架構，根據業務架構，作出相應的應用架構，最後技術架構落地實施。

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

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

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

全部問題的前提要搞清楚咱們今天面臨的業務量有多大，增加走勢是什麼樣，並且解決高併發的過程，必定是一個按部就班逐步的過程。合理的架構可以提早預見業務發展1~2年爲宜。這樣能夠付出較爲合理的代價換來真正達到技術引領業務成長的效果。

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

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

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

相似：

應用架構：

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

應用架構圖關鍵有2點：

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

1）邏輯分層

2）子系統、模塊定義。

3）關鍵類。

二、職責之間的協做：

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

2）協做關係：應用之間的調用關係。

應用分層有兩種方式：

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

另外一種是垂直分（縱向），按照不一樣的業務類型劃分應用，好比進銷存系統能夠劃分爲三個獨立的應用，這是面向業務廣度的劃分。

應用的合反映應用之間如何協做，共同完成複雜的業務case，主要體如今應用之間的通信機制和數據格式，通信機制能夠是同步調用/異步消息/共享DB訪問等，數據格式能夠是文本/XML/JSON/二進制等。

應用的分偏向於業務，反映業務架構，應用的合偏向於技術，影響技術架構。分下降了業務複雜度，系統更有序，合增長了技術複雜度，系統更無序。

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

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

3、數據架構

數據架構指導數據庫的設計. 不只僅要考慮開發中涉及到的數據庫，實體模型，也要考慮物理架構中數據存儲的設計。

6、技術架構

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

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

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

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

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

物理架構主要考慮硬件選擇和拓撲結構，軟件到硬件的映射，軟硬件的相互影響。

三、應用架構

架構演進路程：

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

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

->使用緩存改善性能 ->使用集羣改善併發

->數據庫地讀寫分離

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

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

->業務拆分

->分佈式服務

業務架構是生產力，應用架構是生產關係，技術架構是生產工具。業務架構決定應用架構，應用架構須要適配業務架構，並隨着業務架構不斷進化，同時應用架構依託技術架構最終落地。

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

隨着業務深刻，進銷存每塊業務都變複雜，同時新增客戶關係管理，以更好支持營銷，業務的深度和廣度都增長，這時須要對系統按照業務拆分，變成一個分佈式系統。

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

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

同時無論是企業內部用戶，仍是外部顧客所須要的功能，都由不少細分的應用提供支持，須要提供portal，集成相關應用，爲不一樣用戶提供統一視圖，頂層變成一個AOA的架構（application orientated architecture）。