點擊藍色字體「肉眼品世界」，關注公衆號安全
改變，從一點一滴積累開始
微信
做者丨胡斌網絡
策劃丨小智架構
在平常系統開發過程當中，做爲技術人員想必你們都參與過架構設計的工做。作過一段系統架構工做以後，內心對於架構產生了愈來愈多的問題。app
對於系統的架構，它的本質是什麼，它對產品有何影響？框架
架構分爲哪幾類？分佈式
爲何要畫架構圖，能夠不畫架構圖嗎？微服務
架構圖該怎麼畫，怎麼讓畫架構圖不那麼痛苦？字體
爲了回答這些問題，我總結了這一系列的文章，沉澱本身對於架構的理解，總結架構設計的實踐和思路。但願能幫助到在作架構設計過程當中，一樣有這些困惑的你。大數據
什麼是架構？咱們先看一下百科中是如何定義架構的。
在百度百科中的定義是：架構，又名軟件架構，是有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。
在維基百科中的定義是：軟件體系結構是指軟件系統的基本結構，建立此類結構的規則以及這些結構的文檔。須要這些結構來推斷軟件系統。每一個結構包括軟件元素，它們之間的關係，元素和關係的屬性，以及每一個元素的引入和配置的基本原理。軟件系統的體系結構是一種隱喻，相似於建築物的體系結構。
從百科中咱們提煉出一句話，「架構是一種總體與局部關係的抽象描述」。這句話仍是稍顯抽象，不太容易理解。換個角度，按照中文的字面理解，對「架構「兩個字進行拆解，就會發現頗有意思含義。架構從字面意思上，是源於古代的建築術語。把架構拆分紅兩個字「架」和「構」。「架」就是「加」和「木」的結合，把木頭加起來、鏈接起來就是架。「構」就是結構的意思。因此，「架構」就是把「木「按照必定的結構鏈接起來。
下圖爲古代的木質建築的結構圖：
對應到軟件架構，這裏面的「木」表明什麼，軟件架構中的「結構」是什麼，這些軟件系統的「木」又是如何鏈接的？
關聯到軟件領域，木就是系統中的要素，咱們將他們稱之爲架構要素。架構要素能夠是子系統、模塊、應用服務。
結構，是架構的產物。不一樣的軟件系統會有不一樣的結構，這些結構是爲解決不一樣場景而設計的。
鏈接，經過定義架構元素之間的接口和交互關係、集成機制，實現架構元素之間的鏈接。鏈接能夠是分佈式調用、進程間調用、組件之間的交互關係等。
總結一下架構的本質，即架構 = 要素 + 結構 + 鏈接，將系統要素按照特定結構進行鏈接交互。
在軟件設計中架構域是如何劃分的，架構域包括：業務架構、數據架構、產品架構、應用架構、技術架構。首先須要熟悉業務，造成業務架構，根據業務架構，作出相應的數據架構和應用架構，最後經過技術架構落地實施。業務架構是戰略，應用架構是承上啓下，一方面承接業務架構的落地，另外一方面影響技術架構的選型。如何針對當前需求，選擇合適的架構，如何面向將來，保證架構平滑過渡，這個是軟件開發者，特別是架構師，都須要深刻思考的問題。
在需求初期，業務的需求描述每每比較模糊，可能只是一句話。他們可能來自老闆、運營或者用戶。直接把這句話做爲核心產品功能是不恰當的，合理的作法是先把這個產品全部的問題域列清楚。
問題域，是指本身的產品可以解決的全部問題的空間集合。從核心需求出發，將全部當前須要解決、將來可能要解決的問題放入產品框架的範圍。可以幫助咱們的產品擁有更高的可拓展性，在後續具有迭代和優化的空間。
在通過問題域的羅列後，咱們應該可以獲得一個模糊的產品方向和功能範圍。把這些問題域的答案抽象總結成一個肯定的產品需求。根據核心需求和問題域的答案，梳理出業務流程。
業務架構就是在業務需求初期，將模糊的需求描述轉變成清晰的問題域，梳理出清晰的業務流程。爲產品架構提供輸入。
業務架構包括業務規劃、業務模塊、業務流程，對整個系統的業務進行拆分，對領域模型進行設計，把現實的業務轉化成抽象對象。沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題爲最終目標，脫離實際業務的技術情懷架構每每是空中樓閣。
業務架構必須與其面向的實際應用場景相匹配，因爲每一個產品或項目的業務場景均有所不一樣，因此每次作新的軟件開發前，必須設計軟件架構。試圖不經分析直接套用先前的架構方案，十有八九會讓當前的系統在某個點上報出大問題致使推翻重建，更不要說直接拿別人的現成架構方案了。例如，A 業務中有套 A 系統，恰巧 B 業務須要解決相似 A 業務的場景。此時不少狀況，B 業務的人員會考慮把 A 系統直接拿過來，覺得作一些簡單的修改，就能在 B 業務中落地。結果在系統落地的過程當中，不少功能模塊不能直接使用，都要從新按照業務進行修改。最終的結果是，A 系統通過不斷的重寫修改變成了 B 系統。
上述的案例正是因爲業務架構沒有作到位，沒有作好軟件架構的分析和設計，因此咱們很難看出兩個系統有多少差異，也沒法肯定用一個業務系統去覆蓋另外一個業務系統的可行性有多大。相反，對 A 和 B 業務領域進行業務架構梳理，咱們就能清楚發現二者的一致與區別，就能有效的評估系統覆蓋的可行性和合理性。
通過業務架構階段以後，須要輸出的產物包括：企業戰略方向圖、問題域列表、業務流程圖。
企業架構由業務架構驅動，從業務架構分析業務流程、定義數據架構，流程和數據結合定義產品架構。這中間，數據架構起着相當重要的做用。企業 IT 系統的價值並不在於選取的技術有多先進，使用的硬件有多強大。而是企業業務數據的處理和存儲。一家公司最寶貴的資產無疑就是–數據。毫無疑問，在當今大數據的時代背景下，缺乏數據資產的建設和使用，就失去與同行業爭奪競爭的機會。
所以，數據架構主要解決三個問題：第一，系統須要什麼樣的數據；第二，如何存儲這些數據；第三，如何進行數據架構設計。
數據是對客觀事物的真實表現，企業業務過程當中的全部對象的情況均可以用數據記錄下來。業務運營過程當中有兩條重要的線索：流程和數據。業務流程離不開數據流轉，業務運營情況經過數據反映。基於業務架構的端到端的流程建模過程當中，會衍生出對應的業務數據對象，須要與數據架構模型對接。流程模型和數據模型對接後落實到應用層面，就造成了產品架構。
數據架構中的數據包含靜態數據和動態數據。相對靜態部分如元數據、業務對象數據模型、主數據、共享數據。相對動態部分如數據流轉、ETL、數據全生命週期管控治理。
數據架構是爲了創建一個共享、通用、一致的數據基礎平臺，解決企業信息孤島。如何存儲業務數據，須要結合自身需求，採起合適的數據分佈策略。一般，數據存儲的分佈策略有兩種：一種是集中式存儲，一種是分佈式存儲。
集中式存儲就是講數據集中存放於總部數據中心，全部的下屬機構或子公司不放置和維護數據，都想總部數據中心進行訪問。
集中式存儲
分佈式存儲就是數據分佈存放於總部、分支機構或者子公司，每一個分佈節點須要維護和管理本身的數據。分佈式的數據存儲架構中，還須要考慮每一個分佈式節點的數據與總部節點數據進行同步、備份，作到數據資產的安全、可靠。
分佈式存儲
數據源自於企業的業務流程，從業務流程中咱們能夠找出領域對象，基於領域對象進行分析，就能獲得對象的屬性。根據業務關係進而抽取領取對象之間的關係。所以，領域建模是一種對數據架構頗有幫助的建模思想。經過領域建模，咱們不只能清晰的反映企業的業務域，還能清晰的描繪出一幅企業的數據模型。
數據模型最經常使用的視圖就是 ER 圖，它主要描述企業數據實體、屬性和關係。
實體 (Entiy): 企業領域對象
屬性 (Attribute): 領域對象的屬性
聯繫 (RelationShip): 兩個領域對象之間的關係 (1:1, 1:n 或者 m:n)
基礎的產品框架脫胎於業務流程，但相比業務流程，更加註重產品功能的枚舉、功能模塊之間的分界。
當咱們打開一個系統，咱們會看到一個精美的頁面，一些豐富的信息、導航。這些東西會引導咱們去使用這個系統。這些東西就是這個系統的組成部分，就是這個系統的功能模塊。產品架構，就是將這些不一樣用途的功能模塊圍繞特定的業務目標進行分類整合。
功能模塊是用戶可以完成一個操做的最小粒度的完整功能。好比一個展現可購買商品的列表頁、一個修改用戶密碼的功能。在功能模塊設計過程當中，須要確保用戶能經過一個功能模塊完整的完成一項工做，而不是半個工做。
產品架構中，功能模塊是根據其相互之間的關係來組織的。一個產品中不一樣的功能模塊之間的關係分直接關係和間接關係。只有直接關係的功能模塊纔會被組織到一塊兒，造成一個子系統。那些存在間接關係的模塊，會在不一樣的層級經過直接關係的模塊產生聯繫。
當具備直接關係的功能模塊組合成一個子系統後，解決相同問題域的子系統就造成一個功能層級。功能層級按照接近用戶實操的距離程度進行從上到下，或者從左至右的劃分，這就造成了產品架構的分層。
應用架構是要說明產品架構分哪些應用系統，應用系統間是如何集成的。這就是應用架構和應用集成架構。產品架構在業務架構的基礎上，按照解決的業務問題域，劃分出不一樣的功能模塊，再根據功能模塊間的關係，組合成子系統。應用架構在產品架構的基礎上考慮兩個事情：第1、考慮的是子系統間的關係。第2、考慮將可複用的組件或模塊進行下沉，沉澱到平臺層，爲業務組件提供統一的支撐。
應用架構在規劃時，須要遵循如下幾個原則：
體如今應用架構是否有清晰、明確的層次劃分，各應用系統之間的鏈接關係是否簡單明確，系統之間的耦合程度低。
體如今應用架構適應業務的快速變化，不只要求在快速增長新應用時保持現有應用架構的穩定性，還要在適應業務變化的同時主動促進業務變革。
經過應用系統之間的解耦和組合，以統一的方式對外提供一致的服務接口，從而實現應用系統之間的共享和協做。
應用架構自己只關心須要哪些應用系統，哪些平臺來知足業務目標的需求，而不會關心在整個構建過程當中你須要使用哪些技術。技術架構是應接應用架構的技術需求，並根據識別的技術需求，進行技術選型，把各個關鍵技術和技術之間的關係描述清楚。
技術架構解決的問題包括：如何進行純技術層面的分層、開發框架的選擇、開發語言的選擇、涉及非功能性需求的技術選擇。因爲應用架構體系是分層的，那麼對於的技術架構體系天然也是分層的。大的分層有微服務架構分層模型，小的分層則是單個應用的技術分層框架。大的技術體系考慮清楚後，剩下的問題就是根據實際業務場景來選擇具體的技術點。各個技術點的分析、方案選擇，最終造成關鍵技術清單，關鍵技術清單考慮應用架構自己的分層邏輯，最終造成一個完成的技術架構圖。
總之，技術架構是將產品需求轉變爲技術實現的過程。
咱們是否是都會遇到這樣的狀況，每次畫圖前，腦海中有一張看似清晰的圖。可是一到畫圖那一刻，這張圖確又是那麼無比的模糊。思考這張圖如何設計的過程，也是幫助你梳理「將來產品該朝什麼方向發展、功能迭代如何分期和落地、和其餘產品的依賴關係是什麼、技術方案該如何演進」等問題的過程。
當產品架構圖被設計出來後，按照產品架構圖的結構和路徑，項目的里程碑（RoadMap）就能夠被清晰的拆解出來，同時項目成員也能夠根據這張架構圖產出運營計劃、技術架構等強依賴產品方向的方案。
當技術架構圖被設計出來後，技術方案、技術開發進度就能夠被清晰的制定，技術選型就會明確的選定。
能清晰簡單的呈現本身的思路、明確本身產品的邊界和技術邊界、指明發展的方向，幫助不瞭解你產品的人快速的創建對你產品結構、功能、技術的認知。
不一樣角色對於架構視圖的需求有所不一樣，一張圖走天下是不太現實。每每須要針對不一樣的用戶，提供不一樣視角的架構視圖，便於不一樣角色用戶對於產品的理解。
來看一個生活中視圖的例子。就拿中國地圖爲例，不一樣的人員會關心不一樣的問題，例如圖 1（中國氣候類型）是氣象學家關心的，而圖 2（商品糧基地分佈）是糧食局人員關心的。若是氣象學家拿到一張商品糧基地分佈地圖，對他們來講根本就沒有什麼研究價值。看地圖的人但願一幅地圖能針對他的需求來展示。
同理，軟件架構視圖也須要按照不一樣的視角提供不一樣的視圖。面向業務或者產品，須要以產品架構圖去展現。面向技術同窗，須要以技術架構圖去溝通。不一樣的視圖有助於你們理解同一件事。
當你要開始設計一個系統性、完整性的系統時，若是一開始就跳過設計產品架構圖、技術架構圖，直接開始寫文檔、畫 demo，就很容易發生改了又改，作了又推翻的狀況。
若是項目已經進行了一半，或者項目都已經結束了，但本身卻從未畫過架構圖。那麼今後刻開始，動手開始畫把。有一句話「種一棵樹最好的時間是十年前，其次是如今」。
如何畫架構圖對複雜的系統，特別是前人沒有作過的新系統，一般難以一會兒設計出合適的架構。在架構設計的初期，一般都要經歷一個不斷探索的階段。
在架構設計過程當中，架構分解是必不可少的關鍵步驟。如何進行架構分解，從哪裏入手開始進行分解？這些須要一套架構分解的過程模型和過程方法來指導分解。
從架構域的分類：業務架構、數據架構、產品架構、應用架構、技術架構這 5 個域，依次須要進行架構分解。每一個結構域的分解過程，都是一個迭代過程。從無到有、從粗到細、從模糊到清晰，一步步精細化、豐富架構。迭代的過程就是一個否認之否認的過程，隨着分解的逐步推動或系統的架構演化，後面的分解除了會識別出新的架構元素，也可能會對先前識別出的架構做出調整。整個架構分解的迭代過程，經過畫架構圖的方式是種很是直觀的表現形式。
根據這些架構的分類，依次須要產出業務架構圖、數據架構圖、產品架構圖、應用架構圖、技術架構圖。每一個架構域如何進行設計和架構圖的繪製，將經過後續 4 篇文章來闡述。
胡斌，菜鳥網絡技術專家，目前負責菜鳥風控系統的建設。曾在淘寶技術部前後負責賣家平臺、商家運營等領域。在大規模分佈式應用、大數據、架構領域有多年的開發和管理經驗。
點個在看少個 bug 👇
本文分享自微信公衆號 - 肉眼品世界（find_world_fine）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。