[[384112]]

本文轉載自微信公眾號「bugstack蟲洞棧」，作者小傅哥  。轉載本文請聯系bugstack蟲洞棧公眾號。

目錄

• 一、前言
• 二、架構圖有哪幾種?
• 三、Zachman框架是什么?
• 四、陪你畫個架構圖
  • 1. 架構選型圖
  • 2. 微服務架構
  • 3. 技術架構圖
• 五、總結
• 六、系列推薦

一、前言

很多程序員畫架構圖頭疼，不知道畫什么、怎么畫!

分享、評審、述職、答辯，只要你在程序員這個行業，就幾乎離不開要畫圖。

一提到畫圖很多人就想站起來喊，”內卷“、”內卷啦“、”PPT工程師“，但程序代碼本身就是一種數學邏輯的具體實現，如果沒有一些圖表配合文字的闡述，講真很難讓所有人都能在共同的共識下進行交流。

這不像是文科，”八表流云澄夜色，九霄華月動春城“ 上來就能聯想到它是在描述啥。但是偏理科代碼邏輯或架構設計，只能把抽象的內容用圖表的形式展現出來，讓大家在同一的共識下共同協同工作。

而我們畫的架構圖、流程圖、結構圖、功能圖、邏輯圖等，都需要好看、好懂、好用、好搞，因為：

• 好看是為了提升溝通效率，
• 好懂是為了提升交流共識，
• 好用是為了提升交付質量，
• 好搞是為了提升實施速度。

這就像君子在追求漂亮姑娘一樣，好看就想主動撩一下、有品行和共同的三觀很快讓你開口說我懂你、接下來就是交付質量和實施速度了，那也是水到渠成的事。

好，別激動，接下來我們就開始專心研究研究架構圖，都有哪些，該怎么畫，有什么手法。

二、架構圖有哪幾種?

僅說技術架構圖的話，通常我們?指的是選型各項技術組件來支撐整個服務建設的系統架構。但用于不同人群范圍和不同場景下會有其他分類，如圖 26-1 架構圖分類

• 業務架構：需求初期業務的結果和過程描述一般比較模糊，可能來自于某個老板、運營或用戶的反饋。客戶說海爾洗衣機洗土豆會堵，海爾立馬設計專門的土豆洗衣機 業務方向往往是定方向和結果的叫戰略，主要包括業務規劃、業務模塊和流程以及問題域的列表等。
• 應用架構：服務復用、跨組協同，簡單、靈活、整合是應用架構必須考慮的點，就像你要上線一個聊天功能，那么聊天內容的輸入法、文字識別、輿情監控以及視頻服務、支付服務等，它們都是在應用架構分層下沉淀到平臺的產物，在供各個方使用。
• 產品架構：業務提需求，產品定方案，相對于業務的粗放流程，產品架構會更加細膩以及考慮各個模塊的分層和邊界。
• 數據架構：數據的獲取、數據的存放和數據的使用是數據架構要解決的三個問題，數據庫存放、大數據匯總、數據分析等。
• 技術架構：是離程序員最近的架構設計，它不僅是系統搭建的架構圖設計，還包括了結構、功能、流程、邏輯等內容。它的具體描述就是整個系統如何落地的具體實現方案。

三、Zachman框架是什么?

Zachman框架，由約翰 扎科曼(John Zachman )在1987年創立的全球第一個企業架構理論，其論文《信息系統架構框架》至今仍被業界認為是企業架構設計方面最權威的理論。

Zachman框架(Zachman framework)是一種邏輯結構，它可以對企業信息按照不同分類和不同角度進行表示。

Zachman框架，從橫向六個角度看待企業，這個六個觀點可以分為;什么內容、如何工作、什么地點、誰負責、為什么這么做(稱為W5H)。

框架的列由一組工件組成，分為規劃者、擁有者、設計者(架構師)、建造者、分包者、產品，或者有時表示為視點：范圍上下文，業務概念，系統邏輯，技術，物理，組件組裝和操作類。整體如圖 26-2 TOGAF Zachman框架

表格橫向六項 代表了用于描述信息系統的某一個方面，對于任何一個事物只要在這幾個基本方面對其進行清洗的解釋就足夠可以描述清楚。

• 數據(What，即什么內容)：什么是業務數據，信息或對象?
• 功能(How，即如何工作)：業務如何運作，即什么是業務流程?
• 網絡(Where，即何處)：企業運營、部署在哪里?
• 人(Who，即何人負責)：什么人?什么是業務部門及其等級制度?
• 時間(When，即什么時間)：業務計劃和工作流程是什么?什么時候執行?
• 原因(Why，即為什么做)：為什么選擇的解決方案?這是怎么產生的?

表格縱向六項 代表了在信息系統構造過程中所涉及到的人在描述信息系統時所采用的視角，包括：

• 范圍/規劃者(Planner)：此視圖描述了業務目的和策略，充當其他視圖將被派生和管理的上下文。
• 業務模型/擁有者(Owner)：這是對信息系統必須在其中運作的組織的描述。
• 系統模型/設計師(Designer)：該視圖概述了系統如何滿足組織的信息需求。
• 技術模型/建造者(Builder)：這是系統如何實施的表示，它使特定的解決方案和技術顯而易見。
• 詳細表述/分包者(Sub-Contractor)：這些表示說明了某些系統元素的特定于實現的細節：在生產開始之前需要進一步說明的部分。
• 功能系統/產品(Functioning Enterprise)：在1987年的論文(《A framework for information systems architecture》)中并沒有這一行的內容，實際上此行的內容也并不在架構描述的范疇的之內，不過為了使得架構Zachman框架對于架構的表述更加完備，這一行最終還是被加了進去。

根據 TOGAF 的定義，企業是具有一系列共同目標組織的集合，而架構則是為了有效地實現這一系列目標。

在實現的過程中 定義了企業的結構和運作模式的概念藍圖(SearchCIO)，以及構成企業的所有關鍵元素和其關系的綜合描述(Zachman)。通過創建、溝通和優化用以描述企業未來狀態和發展的關鍵原則和模型以將業務愿景和戰略轉化成有效的企業變更的過程(Gartner)。

可以這一部分內容會比較繞，但可以作為架構設計的知識擴展進行學習理解以及運用。

四、陪你畫個架構圖

簡單來說，架構圖就是為了達成交流共識的實現方案演示，并不一定非得拘泥于某種形式，只要你能畫的清楚，講的明白就最合適不過了。

1. 架構選型圖

• 難度：???
• 作用：通常在新項目開發初期，都要做一些技術選型工作。在負載、網關、架構、治理、框架、服務、數據以及環境和支撐服務上，要選擇適合當前開發的技術。

2. 微服務架構

• 難度：????
• 作用：技術選型完畢后，接下來就是對于這些技術的運用。這個過程有點像搭積木一樣，把每一個區域用適合此位置的積木填充進去。如果是團隊初建或者是技術升級，那么這個過程還是比較復雜的，需要大量的驗證。不過其實互聯網的技術分層和使用已經相對穩定，搭建一個這樣的微服務并不會耗費太長的時間。

3. 技術架構圖

• 難度：????
• 作用：技術架構圖主要是對于研發層面做技術實現指導的，它可以把系統分層和實現結構劃分清楚。另外一般也會把案例工程的結構拿出來一起講解，這樣可以讓團隊伙伴快速的進入開發。

五、總結

本章節向大家講解了什么是架構圖，架構圖的分類和怎么畫架構圖，通過這樣的內容可以讓大家對架構圖有一個全貌的認知。在以后自己畫架構圖了也可以非常明確的知道面對的什么用戶群體，要畫的內容是什么。

TOGAF有一套非常完善的企業架構理論，它描述了一種開發和管理企業體系結構生命周期的方法，并構成了TOGAF的核心。所涉及到的知識非常豐富，值得認真看一下。

好看，能把一件事做的好看非常重要，好看能讓人提起興趣、好看可以使溝通成本降低。也鼓勵大家盡可能把經過自己手里的東西，做的好看一些。