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