在我們做系統架構設計時，如何快速的向外界傳達我們的設計思路。4+1試圖適合我們厘清思路、表達自己的想法。在我們匯報，爭取領導層的認同支持更適合用架構圖來表述我們的觀點。架構圖包括總體架構、邏輯架構、應用架構、技術架構、數據架構、功能架構、網絡架構、運行架構等等。

一、整體架構圖

總體架構基本上把下面所有的架構都體現了。下面所有的架構也都是要與總體架構保持一致。

總體架構需要說明幾件事情：

整個系統的硬件設置是怎么回事？

數據大概是從哪里來，怎么采集、存儲、處理、交換的？

做了哪些功能抽象，以便于支撐上層的應用？

提供哪些業務應用？管理、控制等功能有哪些？

終端用戶怎么訪問和使用這些應用？

該系統與外部系統是怎么進行對接的？

如何保障整個系統的安全、可靠、高質量的建設？

安防系統架構圖

二、邏輯架構

邏輯架構就是整體架構去掉各種保障、底層的硬件基礎等非軟件開發邏輯核心的內容。所以有很多簡單的項目壓根就不寫邏輯架構，直接用總體架構就行了。復雜的，就要把上面總體架構中間分層的邏輯給寫清楚一些。

關注的是功能，包含用戶直接可見的功能，還有系統中隱含的功能。或者更加通俗來描述，邏輯架構更偏向我們日常所理解的“分層”，把一個項目分為“表示層、業務邏輯層、數據訪問層”這樣經典的“三層架構”。

邏輯架構設計的目的就是為了告訴讀者，整個系統是怎么產生左右的。所謂的系統架構，主要說的就是這部分。早期的單體架構、后面的各種分層架構、微服務、服務網格等，說的都是在這里進行設計。

在設計的時候，會用到很多種設計模式，比如你看到有一個應用支撐層/服務層之類的，這就是做了一個MVC，把業務邏輯和用戶前端分離。而所有的邏輯架構都有數據層，這是最早的MVP，即數據、用戶視圖和處理邏輯分離。當然，系統越復雜，架構圖就越復雜。

上汽通用B2C邏輯架構

三、業務架構

企業架構框架白皮書中把架構分為了四個層次，分別是業務、應用、數據、技術。只有梳理清楚了業務，才能指導應用、數據和技術架構。業務架構的分析過程是復雜的，最終的產出可能也不僅僅只是一張架構圖。還有更細節的流程、建模等產出物。一張好的架構圖大概是：分層次、分模塊講清楚了各個產品模塊之間的關系。

四、應用架構

就是應用太豐富了，需要整理整理。內部有哪些應用，怎么對外部提供服務。很多項目都沒有這個，因為應用比較少，不值得多廢點人工單獨寫。用以闡述細化邏輯架構。

互聯網醫院-應用架構

五、技術架構

技術架構要干啥也就很清楚了，就是每一層，我們都用什么組件、什么技術解決什么問題。要求是：精準、明確、簡練。但大體上的結構是類似的，從最底層的存儲，到最上層的接口。右邊是一些通用的運維體系或者支撐服務。體現出來依賴的SDK、第三方類庫、中間件。

云技術架構

現在更多的情況，是多個系統模塊，組成一個大的分布式系統，或者現存多個系統的情況下，需要進行集成開發一個產品。

這樣的話，技術架構，就是高層級的技術架構了，不僅僅體現的是技術組件了，而是更高層級的一些模塊，甚至規范。

六、數據架構

數據架構其實就是從數據側描述數據怎么來、怎么存、怎么加工、怎么使用。從數據源開始，數據通過哪些方式集成過來；集成到數倉之后，都存在哪里，數倉怎么分層，每一層都干啥；在數據集市中又怎么存、怎么管；到數據應用層又提供哪些應用。上面所有的一切，都用什么技術，什么組件，解決什么問題。系統需要什么樣的數據、如何存儲、如何進行數據架構設計。

七、部署架構

部署架構也叫網絡架構，就是底層服務器、網路的設計，提供網絡安全、服務可靠性的設計。再簡單一些理解，就是你這些應用、數據庫都放在那臺服務器上，這些服務器都在哪個ip端，怎么進行訪問。要具體體現：機房；服務器個數、配置；網絡分區關系；體現數據庫、高可用；體現負載均衡；

八、功能架構

就是前臺頁面的功能菜單的目錄結構。你怎么組織系統的所有功能，給用戶提供相應的服務。

支付系統架構

九、運行架構

運行架構其實就是軟件內部，這些系統內部是怎么運轉的，一般會畫很多時序圖、狀態圖、活動圖。一般不單獨畫一個運行架構，而是在概要和詳細設計里畫。

k8s運行時序圖