今天我們來聊一下系統架構設計的相關基本概念。
系統架構這個詞現在用的非常多，大家可能平時都在用在講。那麼這個詞我覺得用的也比較淡，什麼事情可能不能扯上一點系統架構。但是回過頭去想，這種架構確實也不是乙個高大上的東西，你可能每天都在接觸，每天都在應用。如果那方面你沒有去總結，另一方面，你可能也沒有把這個事情提高到系統架構設計這麼高度去看問題，這篇就是希望幫助大家去理一下思路，看一下什麼叫做系統架構設計。
什麼是系統架構設計？或者說做什麼樣事情稱之為系統架構設計。我們這個問題暫時先不回答，我們先來看幾個例子，看完幾個例子，我們再來**這個問題。、
第乙個例子，我們看到這是一張uml裡面的部署圖，我們看到有中間有乙個節點node1，然後裡面有乙個元件，這個元件名字叫做web，web元件裡面包含了各種頁面、服務、dao，還有其他雜七雜八的東西，這是我們的系統架構1.0，也就是我們最原始的乙個架構風格。
這個架構風格在現實當中確實有些地方（包括我們自己團隊），有時候也會用這樣的風格去組建我們的系統，這種系統風格在有些時候是很有用，因為它比較簡單，這乙個web什麼都在這裡面了。部署上就是乙個普通的乙個web工程。但是隨著團隊規模的擴大，或者隨著業務邏輯複雜，軟體功能越來越多，可能很多人就覺得這種單獨部署web包這個方式就不一定太合適。這樣需要想一些策略和方法，我們想到這個思路，可能大家也想到了，我們稱之為分層。那麼分層怎麼分？我們還是在乙個web裡面，我們還在乙個web裡面，只不過把web裡面的組建一層層撥開來，我們有頁面元件，有service屬性，有dao或其他的元件。總而言之，我們把乙個web的乙個節點分成了幾個元件。這幾個元件我們可以稱之為是乙個分層的元件，相對剛才只是乙個元件而言，這個分層方式就比較經典的所謂的三層模式。三層模式能解決什麼問題？解決就是剛才我們講到的，所有東西都是放在一起導致可復用性比較低的乙個問題。也就是說我們頁面、service跟d奧之間實際上是有一定關係的，這種關係我們有時候認為是可以復用的。這就是我們的2.0架構，也就是分成基本的分層架構。
基本的分層有了之後，我們可能又會碰到問題，什麼問題？隨著業務更加複雜，人越來越多，可能光三層模式不一定滿足我們的需求了，我們怎麼辦呢？我們還想再分拆要怎麼分？我們也有這個思路，就是把剛才講到的幾個元件的拎出去，拎到另外乙個節點裡面去，我們叫這個節點為note2。那麼大家可以看到note1裡面的web肯定會去呼叫note2裡面的服務，這兩個節點上正好體現了一種跨程序呼叫。跨程序的呼叫，物理上可能不一定在兩個節點，可能是在同乙個節點或者說在不同的虛擬機器裡面，但是它的服務呼叫方式已經從普通的函式級的呼叫變成乙個分布式的服務呼叫。這時候我們就看到我們把元件從乙個地方分到兩個地方，這樣的好處就是說我們的服務之間的依賴關係通過分布式的方式能夠得到更進一步的擴充套件，即架構3.0。
但是有時候也會有問題，什麼問題呢？我們到時候可能服務越來越多，服務多的理也理不清楚，就算理清了又管不好，比方說不知道這個服務到底在**，那怎麼辦？這時候我們也會想到把服務這個東西再分層，所以我們有了架構4.0。
我出版了《系統架構設計：程式設計師向架構師轉型之路》、《向技術管理者轉型：軟體開發人員跨越行業、技術、管理的轉型思維與實踐》、《微服務設計原理與架構》、《微服務架構實戰》等書籍，並翻譯有《深入rabbitmq》和《spring5響應式程式設計實戰》（待出版），歡迎交流。
系統架構設計 一
領域建模與需求分析緊密結合，建模是為了更好的進行需求總結和分析，整理出其中不變的模型，建立專業的詞彙。其可作為對現實世界的某種抽象,需要有選擇的進行忽略，而有選擇的進行忽略和保留都取決於你所要進行的模型設計。最終是抽取其中不變的部分和內容。需求 於三大部分 功能 質量屬性 商業需求。關鍵需求決定架構...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...