一、前言

系統架構思想是軟件開發工程師的工作必備知識。大到大型互聯網應用系統的設計，小到一個軟件功能函數的設計，都需要擁有架構設計思想。軟件架構分層就是架構設計中的一個子領域，更著重強調軟件的分層概念。 本篇文章就帶大家簡單的了解一下軟件架構的分層，學習完畢，你就會明白，為什么系統要分層，架構分層可以帶來什么好處。

二、軟件架構分層的發展背景

計算機編程在“上古時代”開始時，是用二進制來編程，后面逐漸發展成熟。到了20 世紀 60 年代第一次軟件危機時，引出了“結構化編程”，并創造了“模塊”概念；20 世紀 80 年代第二次軟件危機引出了“面向對象編程”，創造了“對象”概念；到了 20 世紀 90 年代, 隨著軟件規模的不斷增大，以下問題就開始顯現。

系統規模龐大，內部耦合嚴重，開發效率低；

系統耦合嚴重，牽一發動全身，后續修改和擴展困難；

系統邏輯復雜，容易出問題，出問題后很難排查和修復。

于是在Rational 和 Microsoft 內部，軟件架構的概念開始越來越流行了。“組件”概念隨著軟件架構的流行也逐漸清晰。 我們可以看到，“模塊”“對象”“組件”本質上都是對達到一定規模的軟件進行拆分，差別只是在于隨著軟件的復雜度不斷增加，拆分的粒度越來越粗，拆分的層次越來越高。 隨著90年代互聯網的迅速崛起，軟件架構分層也隨著軟件架構的興起而逐步興起。

三、軟件分層的概念

軟件架構分層就是將軟件模塊按照水平切分的方式分成多個層，一個系統由多層組成，每層由多個模塊組成。每層有自己獨立的職責，為上一層提供服務，使用下一層的服務，每層只能看到處自己相臨的層。多個層次協同提供完整的功能。通過分層結構，可以將大的問題分解為若干個漸進的小問題來解決，可以隱蔽問題的復雜度。修改某一層，最多影響其相鄰的兩層（通常只能影響上層）。 這里引申到層間隔離的概念。分層架構中的每一層可以是封閉的或者開放的，封閉意味著當一個請求自頂向下在層間傳遞時，它不能跳過任意的一層。所謂的層間隔離，旨在降低一個層次上的變化對其他層次的組件的影響。簡單來說，就是每個層次對其他層次的功能知道的越少越好。但是在某些的場景，將特定的層次置為開放的狀態也不失為一件好事。還有某些不想被其它層看到的代碼也可以通過層間隔離的手段來實現。

四、軟件分層的特點

分層設計的本質其實就是將復雜問題簡單化，基于單一職責原則讓每層代碼各司其職，基于“高內聚，低耦合”的設計思想實現相關層對象之間的交互。從而，提升代碼的可維護性和可擴展性。系統架構分層之后，一般要具有以下特點：

高內聚：分層設計可以簡化系統設計，讓不同層專注做本層相關的事，同時更利于系統開發工作的分配，讓“專業的人做專業的事”。這也體現了軟件設計思想的“單一職責原則”；

低耦合：層與層之間通過接口或API來交互，依賴方不用知道被依賴方的細節。這樣即使某一層發生較大的變化，其它層也不需要做較多改動就可以適配。軟件設計思想的“迪米特法則”在這里得到了體現；

復用/可移植性：分層之后可以做到代碼或功能的復用；

擴展性/易裁剪：分層架構可以讓代碼更容易橫向擴展或者裁剪。這里體現了軟件設計思想的“開閉原則”。

任何事物都不可能是盡善盡美的，分層架構雖有優勢也會有缺陷，比如分層可能會增加代碼量。通過層層調用會降低了代碼效率。 下面列用幾種常見的分層架構來說明以上作用。

五、常見的分層架構

TCP/IP協議的四層架構：它把網絡簡化成了四層，即鏈路層、網絡層、傳輸層和應用層。每一層各司其職又互相幫助，網絡層負責端到端的尋址和建立連接，傳輸層負責端到端的數據傳輸等，同時相鄰兩層還會有數據的交互。這樣可以隔離關注點，讓不同的層專注做不同的事情。

Linux文件系統分層：從下圖你可以清晰地看出文件系統的層次。在文件系統的最上層是虛擬文件系統（VFS），用來屏蔽不同的文件系統之間的差異，提供統一的系統調用接口。虛擬文件系統的下層是 Ext3、Ext4 等各種文件系統，再向下是為了屏蔽不同硬件設備的實現細節，我們抽象出來的單獨的一層——通用塊設備層，然后就是不同類型的磁盤了。

我們可以看到，某些層次負責的是對下層不同實現的抽象，從而對上層屏蔽實現細節。比方說VFS 對上層（系統調用層）來說提供了統一的調用接口，同時對下層中不同的文件系統規約了實現模型，當新增一種文件系統實現的時候，只需要按照這種模型來設計，就可以無縫插入到 Linux 文件系統中。

網絡服務架構分層：下圖是目前常見的網絡服務架構，分為部署的硬件環境、操作系統、所需的中間件、承載業務的應用程序以及軟件接入層等。不同的層次也產生了對應在職位，比如運維工程師、中間件工程師、產品經理、開發工程師、測試工程師等工種。而我們在實踐過程中，接觸最多，使用最多的分層要屬應用軟件層了，其次是中間件層。

嵌入式軟件架構分層：在嵌入式系統中，軟件的分層同樣很重要。嵌入式系統中的核心是芯片，以及圍繞著芯片展開的一系列硬件電路，但是不同的嵌入式項目之間硬件差異很大，為了讓硬件能夠按指定的方式工作，就需要為相應的硬件“量身定制”硬件層代碼。雖然硬件之間有差異，但還是存在一些共同點，比如驅動LCD工作，外接幾個IO口來支持按鍵或控制小燈的開關等功能。為了屏蔽硬件底層的差異，同時提供統一的功能硬件接口，于是硬件抽象層就產生了。業務代碼則實現嵌入式系統指定的業務功能，定義了系統在什么條件下做什么反應，或者定期執行一些什么動作。為了讓業務代碼開發更方便，不重復“造輪子”，需要收集很多現成的“輪子”，比較典型的“輪子”就是操作系統，它是眾多“輪子”的集合，給應用程序提供了多任務，中斷，任務間通信等功能，這一層我姑且叫它“功能層”。

六、怎么分

在做架構分層時，開發團隊需要做到以下幾點：

1. 讓團隊深入理解軟件分層的義意，清晰軟件分層的目的

分層的作用在上面已經列出來，只有充分認識到軟件分層帶來的好處，才會有動力去設計與實現分層。

2. 合理設計分層，清晰定義每層的職責

基于“高內聚，低耦合”的設計思想，定義每層的職責，每層再設計不同的模塊。層次數量可以根據實際需要來調整。建議最多不要超過7層，3到4層最佳。

3.避免掉進sinkhole反模式的陷阱

所謂sinkhole反模式指的是請求只是簡單地路過各個層次，并沒有做一些業務處理。 比如，表現層接收到一個獲取基本用戶數據（姓名、地址等）的請求后將它傳遞到業務層；然而，業務層并沒有做任何的業務處理，直接將請求傳遞到持久層；持久層也僅僅是構造了一個簡單的SQL語句，向數據層查詢用戶數據；最后，數據按照原路返回到表現層，中途沒有經過任何的數據匯聚、轉換等操作。sinkhole反模式會導致很多不必要的對象實例化開銷，從而增大了系統的內存消耗，并且影響了性能。 利用80-20原則可以幫助確定架構是否陷入sinkhole反模式。大概有百分之二十的請求僅僅是做簡單的穿透，百分之八十的請求會做一些業務邏輯操作是正常的情況。然而，如果這個比例反過來，大部分的請求都是僅僅穿過層，不做邏輯操作，架構就陷入了sinkhole反模式，可以對一些架構層進行開放或者減少層級關系。

4. 通過技術手段守護架構

當定義清楚了分層架構，必然也要有守護架構的一些原則，在《演進式架構》中推薦盡早確定系統的適應度函數，并定期的審查，根據業務和技術的需求修改當前的適應度函數或增加新的適應度函數，以保證架構能夠按照設計的方向發展。 在java進程內，有一些自動化工具可以通過測試的方式來驗證代碼的架構是否遵循了預先設計的原則（如ArchUnit），可以高效的幫團隊識別出在開發過程中破壞原則的代碼實現。

5.提升團隊整體認知水平和協作水平

在團隊不斷成熟的過程中，很難保證所有的開發人員都能夠有能力守護架構，因此除了通過技術手段守護架構，也非常有必要采取一定的手段來提升整個團隊的認知水平和協作水平。 首先可以在團隊內建立架構評審委員會，關于架構的關鍵決策需要由委員會來拍板，而不是每個開發人員都可以決策。另外在做詳細的實現設計時，要由有經驗有能力守護架構的同學進行設計，并將工作內容拆分成更加可操作的Task。通過這種方式將整個團隊的認知水平底線提升到可以守護架構的程度。 上面分享了分層的特點和分層的方法，相信你已經對軟件架構分層有了更深入的了解。希望軟件架構分層可以融入到我們的開發設計工作中。

七、結語

本篇文章為大家分享了市面上常見的架構分層。架構分層的目的是通過關注點分離來降低系統的復雜度，同時滿足單一職責、高內聚、低耦合、提高可復用性和降低維護成本。但分層架構同樣也有一定的缺點，比如開發成本高、性能略低等問題。實踐中，架構分層并不能解決所有問題，每個項目可能都有其獨特的需求和背景，選擇什么樣的架構模式，還是要根據實情況考慮。