天天看點

一文搞懂各種架構(業務架構、應用架構、資料架構)

作者:大資料與人工智能分享

01 什麼是架構和架構本質

02 架構分層和分類

03 架構的級别

04 應用架構的演進

05 衡量架構的合理性

06 常見架構誤區

07 架構知識體系

01 什麼是架構和架構本質

在軟體行業,對于什麼是架構,都有很多的争論,每個人都有自己的了解。此君說的架構和彼君了解的架構未必是一回事。是以我們在讨論架構之前,我們先讨論架構的概念定義,概念是人識這個世界的基礎,并用來溝通的手段,如果對架構概念了解不一樣,那溝通起來自然不順暢。

Linux有架構,MySQL有架構,JVM也有架構,使用Java開發、MySQL存儲、跑在Linux上的業務系統也有架構,應該關注哪一個?想要清楚以上問題需要梳理幾個有關系又相似的概念:系統與子系統、子產品與組建、架構與架構:

1.1. 系統與子系統

系統:泛指由一群有關聯的個體組成,根據某種規則運作,能完成個别元件不能獨立完成的工作能力的群體。

子系統:也是由一群關聯的個體組成的系統,多半是在更大的系統中的一部分。

1.2. 子產品與元件

都是系統的組成部分,從不同角度拆分系統而已。子產品是邏輯單元,元件是實體單元。

子產品就是從邏輯上将系統分解, 即分而治之, 将複雜問題簡單化。子產品的粒度可大可小, 可以是系統,幾個子系統、某個服務,函數, 類,方法、 功能塊等等。

元件可以包括應用服務、資料庫、網絡、實體機、還可以包括MQ、容器、Nginx等技術元件。

1.3. 架構與架構

架構是元件實作的規範,例如:MVC、MVP、MVVM等,是提供基礎功能的産品,例如開源架構:Ruby on Rails、Spring、Laravel、Django等,這是可以拿來直接使用或者在此基礎上二次開發。

架構是規範,架構是結構。

我在這重新定義架構:軟體架構指軟體系統的頂層結構。

架構是經過系統性地思考, 權衡利弊之後在現有資源限制下的最合理決策, 最終明确的系統骨架: 包括子系統、子產品、 元件以及他們之間協作關系, 限制規範, 指導原則.并由它來指導團隊中的每個人思想層面上的一緻。涉及四方面:

  • 系統性思考的合理決策:比如技術選型、解決方案等。
  • 明确的系統骨架:明确系統有哪些部分組成。
  • 系統協作關系:各個組成部分如何協作來實作業務請求。
  • 限制規範和指導原則:保證系統有序,高效、穩定運作。

是以架構師具備能力:了解業務,全局把控,選擇合适技術,解決關鍵問題、指導研發落地實施。

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

那什麼樣的系統要考慮做架構設計 技術不會平白無故的出和自驅動發展起來,而架構的發展和需求是基于業務的驅動。

架構設計完全是為了業務,

  • 需求相對複雜
  • 非功能性需求在整個系統占據重要位置
  • 系統生命周期長,有擴充性需求
  • 系統基于元件或者內建的需要
  • 業務流程再造的需要

02 架構分層和分類

架構分類可細分為業務架構、應用架構、技術架構、代碼架構及部署架構。

一文搞懂各種架構(業務架構、應用架構、資料架構)

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

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

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

2.1. 業務架構(俯視架構):

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

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

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

看看京東業務架構(網上分享圖):

一文搞懂各種架構(業務架構、應用架構、資料架構)

2.2. 應用架構(剖面架構,也叫邏輯架構圖):

硬體到應用的抽象,包括抽象層和程式設計接口。應用架構和業務架構是相輔相成的關系。業務架構的每一部分都有應用架構。

類似:

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

應用架構圖關鍵有2點:

①. 職責劃分: 明确應用(各個邏輯子產品或者子系統)邊界

  • 邏輯分層
  • 子系統、子產品定義。
  • 關鍵類。

②. 職責之間的協作:

  • 接口協定:應用對外輸出的接口。
  • 協作關系:應用之間的調用關系。

應用分層有兩種方式:

  • 一種是水準分(橫向),按照功能處理順序劃分應用,比如把系統分為web前端/中間服務/背景任務,這是面向業務深度的劃分。
  • 另一種是垂直分(縱向),按照不同的業務類型劃分應用,比如進銷存系統可以劃分為三個獨立的應用,這是面向業務廣度的劃分。

應用的合反映應用之間如何協作,共同完成複雜的業務case,主要展現在應用之間的通訊機制和資料格式,通訊機制可以是同步調用/異步消息/共享DB通路等,資料格式可以是文本/XML/JSON/二進制等。

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

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

系統采用什麼樣的應用架構,受業務複雜性影響,包括企業發展階段和業務特點;同時受技術複雜性影響,包括IT技術發展階段和内部技術人員水準。業務複雜性(包括業務量大)必然帶來技術複雜性,應用架構目标是解決業務複雜性的同時,避免技術太複雜,確定業務架構落地。

2.3. 資料架構

資料架構指導資料庫的設計. 不僅僅要考慮開發中涉及到的資料庫,實體模型,也要考慮實體架構中資料存儲的設計。

一文搞懂各種架構(業務架構、應用架構、資料架構)

2.4. 代碼架構(也叫開發架構):

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

代碼架構主要定義:

①. 代碼單元

  • 配置設計
  • 架構、類庫。

②. 代碼單元組織

  • 編碼規範,編碼的慣例。
  • 項目子產品劃分
  • 頂層檔案結構設計,比如mvc設計。
  • 依賴關系
一文搞懂各種架構(業務架構、應用架構、資料架構)

2.5. 技術架構

技術架構:确定組成應用系統的實際運作元件(lvs,nginx,tomcat,php-fpm等),這些運作元件之間的關系,以及部署到硬體的政策。

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

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

2.6. 部署拓撲架構圖(實際實體架構圖):

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

一文搞懂各種架構(業務架構、應用架構、資料架構)

實體架構主要考慮硬體選擇和拓撲結構,軟體到硬體的映射,軟硬體的互相影響。

一文搞懂各種架構(業務架構、應用架構、資料架構)

03 架構的級别

我們使用金字塔的架構級别來說明,上層級别包含下層:

  • 系統級:即整個系統内各部分的關系以及如何治理:分層
  • 應用級:即單個應用的整體架構,及其與系統内單個應用的關系等。
  • 子產品級:即應用内部的子產品架構,如代碼的子產品化、資料和狀态的管理等。
  • 代碼級:即從代碼級别保障架構實施。

戰略設計與戰術設計

基于架構金字塔,我們有了系統架構的戰略設計與戰術設計的完美結合:

  • 戰略設計:業務架構用于指導架構師如何進行系統架構設計。
  • 戰術設計:應用架構要根據業務架構來設計。
  • 戰術實施:應用架構确定以後,就是技術選型。

04 應用架構的演進

業務架構是生産力,應用架構是生産關系,技術架構是生産工具。業務架構決定應用架構,應用架構需要适配業務架構,并随着業務架構不斷進化,同時應用架構依托技術架構最終落地。

一文搞懂各種架構(業務架構、應用架構、資料架構)

架構演進路程:單體應用→分布式應用服務化→微服務

4.1. 單體應用

企業一開始業務比較簡單,隻應用某個簡單場景,應用服務支援資料增删改查和簡單的邏輯即可,單體應用可以滿足要求。

典型的三級架構,前端(Web/手機端)+中間業務邏輯層+資料庫層。這是一種典型的Java Spring MVC或者Python Django架構的應用。其架構圖如下所示:

一文搞懂各種架構(業務架構、應用架構、資料架構)

針對單體應用,非功能性需求的做法:

  • 性能需求:使用緩存改善性能
  • 并發需求:使用叢集改善并發
  • 讀寫分離:資料庫地讀寫分離
  • 使用反向代理和cdn加速
  • 使用分布式檔案和分布式資料庫

單體架構的應用比較容易部署、測試, 在項目的初期,單體應用可以很好地運作。然而,随着需求的不斷增加, 越來越多的人加入開發團隊,代碼庫也在飛速地膨脹。慢慢地,單體應用變得越來越臃腫,可維護性、靈活性逐漸降低,維護成本越來越高。

下面是單體架構應用的一些缺點:

  • 複雜性高:以一個百萬行級别的單體應用為例,整個項目包含的子產品非常多、子產品的邊界模糊、 依賴關系不清晰、 代碼品質參差不齊、 混亂地堆砌在一起。可想而知整個項目非常複雜。每次修改代碼都心驚膽戰, 甚至添加一個簡單的功能, 或者修改一個Bug都會帶來隐含的缺陷。
  • 技術債務:随着時間推移、需求變更和人員更疊,會逐漸形成應用程式的技術債務, 并且越積 越多。“ 不壞不修”, 這在軟體開發中非常常見, 在單體應用中這種思想更甚。已使用的系統設計或代碼難以被修改,因為應用程式中的其他子產品可能會以意料之外的方式使用它。
  • 部署頻率低:随着代碼的增多,建構和部署的時間也會增加。而在單體應用中, 每次功能的變更或缺陷的修複都會導緻需要重新部署整個應用。全量部署的方式耗時長、 影響範圍大、 風險高, 這使得單體應用項目上線部署的頻率較低。而部署頻率低又導緻兩次釋出之間會有大量的功能變更和缺陷修複,出錯率比較高。
  • 可靠性差:某個應用Bug,例如死循環、記憶體溢出等, 可能會導緻整個應用的崩潰。
  • 擴充能力受限:單體應用隻能作為一個整體進行擴充,無法根據業務子產品的需要進行伸縮。例如,應用中有的子產品是計算密集型的,它需要強勁的CPU;有的子產品則是IO密集型的,需要更大的記憶體。由于這些子產品部署在一起,不得不在硬體的選擇上做出妥協。
  • 阻礙技術創新:單體應用往往使用統一的技術平台或方案解決所有的問題, 團隊中的每個成員 都必須使用相同的開發語言和架構,要想引入新架構或新技術平台會非常困難。

4.2. 分布式

随着業務深入,業務要求的産品功能越來越多,每個業務子產品邏輯也都變得更加複雜,業務的深度和廣度都增加,使得單體應用變得越來越臃腫,可維護性、靈活性逐漸降低,增加新功能開發周期越來越長,維護成本越來越高。

這時需要對系統按照業務功能子產品拆分,将各個子產品服務化,變成一個分布式系統。業務子產品分别部署在不同的伺服器上,各個業務子產品之間通過接口進行資料互動。

該架構相對于單體架構來說,這種架構提供了負載均衡的能力,大大提高了系統負載能力,解決了網站高并發的需求。另外還有以下特點:

  • 降低了耦合度:把子產品拆分,使用接口通信,降低子產品之間的耦合度。
  • 責任清晰:把項目拆分成若幹個子項目,不同的團隊負責不同的子項目。
  • 擴充友善:增加功能時隻需要再增加一個子項目,調用其他系統的接口就可以。
  • 部署友善:可以靈活的進行分布式部署。
  • 提高代碼的複用性:比如Service層,如果不采用分布式rest服務方式架構就會在手機Wap商城,微信商城,PC,Android,iOS每個端都要寫一個Service層邏輯,開發量大,難以維護一起更新,這時候就可以采用分布式rest服務方式,公用一個service層。
  • 缺點:系統之間的互動要使用遠端通信,接口開發增大工作量,但是利大于弊。

4.3. 微服務

緊接着業務模式越來越複雜,訂單、商品、庫存、價格等各個子產品都很深入,比如價格區分會員等級,通路管道(app還是PC),銷售方式(團購還是普通)等,還有大量的價格促銷,這些規則很複雜,容易互相沖突,需要把分散到各個業務的價格邏輯進行統一管理,以基礎價格服務的方式透明地提供給上層應用,變成一個微核心的服務化架構,即微服務。

微服務的特點:

  • 易于開發和維護:一個微服務隻會關注一個特定的業務功能,是以它業務清晰、代碼量較少。開發和維護單個微服務相對簡單。而整個應用是由若幹個微服務建構而成的,是以整個應用也會被維持在一個可控狀态。
  • 單個微服務啟動較快:單個微服務代碼量較少, 是以啟動會比較快。
  • 局部修改容易部署:單體應用隻要有修改,就得重新部署整個應用,微服務解決了這樣的問題。一般來說,對某個微服務進行修改,隻需要重新部署這個服務即可。
  • 技術棧不受限:在微服務架構中,可以結合項目業務及團隊的特點,合理地選擇技術棧。例如某些服務可使用關系型資料庫MySQL;某些微服務有圖形計算的需求,可以使用Neo4j;甚至可根據需要,部分微服務使用Java開發,部分微服務使用Node.js開發。

微服務雖然有很多吸引人的地方,但它并不是免費的午餐,使用它是有代價的。使用微服務架構面臨的挑戰。

  • 運維要求較高:更多的服務意味着更多的運維投入。在單體架構中,隻需要保證一個應用的正常運作。而在微服務中,需要保證幾十甚至幾百個服務服務的正常運作與協作,這給運維帶來了很大的挑戰。
  • 分布式固有的複雜性:使用微服務建構的是分布式系統。對于一個分布式系統,系統容錯、網絡延遲、分布式事務等都會帶來巨大的挑戰。
  • 接口調整成本高:微服務之間通過接口進行通信。如果修改某一個微服務的API,可能所有使用了該接口的微服務都需要做調整。
  • 重複勞動:很多服務可能都會使用到相同的功能,而這個功能并沒有達到分解為一個微服務的程度,這個時候,可能各個服務都會開發這一功能,進而導緻代碼重複。盡管可以使用共享庫來解決這個問題(例如可以将這個功能封裝成公共元件,需要該功能的微服務引用該元件),但共享庫在多語言環境下就不一定行得通了。

05 衡量架構的合理性

架構為業務服務,沒有最優的架構,隻有最合适的架構,架構始終以高效,穩定,安全為目标來衡量其合理性。

合理的架構設計:

5.1. 業務需求角度

  • 能解決當下業務需求和問題
  • 高效完成業務需求: 能以優雅且可複用的方式解決當下所有業務問題
  • 前瞻性設計: 能在未來一段時間都能以第2種方式滿足業務,進而不會每次當業務進行演變時,導緻架構翻天覆地的變化。

5.2. 非業務需求角度

①. 穩定性名額

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

②. 高效名額

  • 文檔化:不管是整體還是部分的整個生命周期内都必須做好文檔化,變動的來源包括但不限于BUG,需求。
  • 可擴充:軟體的設計秉承着低耦合的理念去做,注意在合理的地方抽象。友善功能更改、新增和運用技術的疊代,并且支援在适時對架構做出重構。
  • 高複用:為了避免重複勞動,為了降低成本,我們希望能夠重用之前的代碼、之前的設計。這點對于架構環境的依賴是最大的。

③. 安全名額

  • 安全:組織的運作過程中産生的資料都是具有商業價值的,保證資料的安全也是刻不容緩的一部分。以免出現XX門之類醜聞。加密、https等為普遍手段。

06 常見架構誤區

開高走落不到實處:

  • 遺漏關鍵性限制與非功能需求
  • 為虛無的未來埋單而過度設計
  • 過早做出關鍵性決策
  • 客戶說啥就是啥成為傳話筒
  • 埋頭幹活兒缺乏前瞻性
  • 架構設計還要考慮系統可測性
  • 架構設計不要企圖一步到位

常見誤區:

  • 誤區1——架構專門由架構師來做,業務開發人員無需關注:架構的再好,最終還是需要代碼來落地,并且組織越大這個落地的難度越大。不單單是系統架構,每個解決方案每個項目也由自己的架構,如分層、設計模式等。如果每一塊磚瓦不夠堅固,那麼整個系統還是會由崩塌的風險。所謂“千裡之堤,潰于蟻穴”。
  • 誤區2——架構師确定了架構藍圖之後任務就結束了:架構不是“空中樓閣”,最終還是要落地的,但是架構師完全不去深入到第一線怎麼知道“地”在哪?怎麼才能落的穩穩當當。
  • 誤區3——不做出完美的架構設計不開工:世上沒有最好架構,隻有最合适的架構,不要企圖一步到位。我們需要的不是一下子造出一輛汽車,而是從單輪車→自行車→機車,最後再到汽車。想象一下2年後才能造出的産品,當初市場還存在嗎?
  • 誤區4—— 為虛無的未來埋單而過度設計:在創業公司初期,業務場景和需求邊界很難把握,産品需要快速疊代和變現,需求頻繁更新,這個時候需要的是快速實作。不要過多考慮未來的擴充,說不定功能做完,效果不好就無用了。如果業務模式和應用場景邊界都已經比較清晰,是應該适當的考慮未來的擴充性設計。
  • 誤區5——一味追随大公司的解決方案:由于大公司巨大成功的光環效應,再加上從大公司挖來的技術高手的影響,網站在讨論架構決策時,最有說服力的一句話就成了“淘寶就是這麼搞的”或者“騰訊 就是這麼搞的”。大公司的經驗和成功模式固然重要,值得學習借鑒,但如果是以而變得盲從,就失去了堅持自我的勇氣,在架構演化的道路上遲早會迷路。
  • 誤區6——為了技術而技術:技術是為業務而存在的,除此毫無意義。在技術選型和架構設計中,脫離網站業務發展的實際,一味追求時髦的新技術,可能會将技術發展引入崎岖小道,架構之路越走越難。考慮實作成本、時間、人員等各方面都要綜合考慮,理想與現實需要折中。

07 架構知識體系

7.1. 架構演進

  • 初始階段:LAMP,部署在一台伺服器
  • 應用伺服器和資料伺服器分離
  • 使用緩存改善性能
  • 使用叢集改善并發
  • 資料庫地讀寫分離
  • 使用反向代理和cdn加速
  • 使用分布式檔案和分布式資料庫
  • 業務拆分
  • 分布式服務

7.2. 架構模式

分層:橫向分層:應用層,服務層,資料層

分割:縱向分割:拆分功能和服務

分布式:

  • 分布式應用和服務
  • 分布式靜态資源
  • 分布式資料和存儲
  • 分布式計算

叢集:提高并發和可用性

緩存:優化系統性能

  • cdn
  • 方向代理通路資源
  • 本地緩存
  • 分布式緩存

異步:降低系統的耦合性

  • 提供系統的可用性
  • 加快響應速度

備援:冷備和熱備,保證系統的可用性

自動化:釋出,測試,部署,監控,報警,失效轉移,故障恢複

7.3. 架構核心要素

高性能:網站的靈魂

  • 性能測試
  • 前端優化
  • 應用優化
  • 資料庫優化

可用性:保證伺服器不當機,一般通過備援部署備份伺服器來完成負載均衡、資料備份、自動釋出、灰階釋出、監控報警。

伸縮性:建叢集,是否快速應對大規模增長的流量,容易添加新的機器叢集

  • 負載均衡
  • 緩存負載均衡

可擴充性:主要關注功能需求,應對業務的擴充,快速響應業務的變化。是否做法開閉原則,系統耦合依賴。

  • 分布式消息
  • 服務化

安全性:網站的各種攻擊,各種漏洞是否堵住,架構是否可以做到限流作用,防止ddos攻擊。如:xss攻擊、sql注入、csr攻擊、web防火牆漏洞、安全漏洞、ssl等。

下一篇: ethtool

繼續閱讀