1. 爲什麼要分層
1.1. 各司其職
- 各層級之間只需要關注自己內部的邏輯。
- 方便程序複用。
- 沉澱解決方案或組件等。在實際的業務開發中，每層可以沉澱自己的問題解決方案/組件，在實際業務中運行一段時間後，甚至形成整個行業的標準解決方案。
- 提高研發效率。實際開發中，前後端分離，專業人做專業事。
1.2. 分而治之
“分”，“治”思想的一種應用。將複雜的問題不斷的拆解到各層中，每層只解決一小部分問題，整個層級連起來形成複雜問題的完整解決方案。
通過拆解的方式簡化了問題處理難度，對於開發者來說也更容易理解。
1.3. 有條不紊的結合
- 各層之間相互獨立，並且有嚴格的調用層級關係，任意一層的實現變化只需要測試本層的內容即可，無需迴歸整條鏈路。
- 方便程序複用。
2. 常見分層架構
2.1 網絡OSI七層模型
標準的OSI模型共分爲七層：應用層、表現層、會話層、傳輸層、網絡層、數據鏈路層、物理層；一般應用實現分爲四層：應用層、傳輸層，網絡層，網絡接口層。
| 層級名稱 | 簡單說明 |
|---|---|
| 物理層 | 該層規範了有關傳輸介質的特性，包含連接頭、幀、幀的使用、電流、編碼及光調製等。爲數據端設備提供傳送數據的通路，爲邏輯數據傳送提供基礎物理服務，數據單位：比特(bit) |
| 數據鏈路層 | 數據鏈路層協議是爲發對等實體間保持一致而制定的，主要提供鏈路連接的建立，拆除，分離，數據幀差錯控制與恢復，常見的實體產品有：網卡，網橋等，數據單位：數據幀 |
| 網絡層 | 數據鏈路層解決了物理連接的建立、拆除等問題，但是一條物理連接的建立卻只能被一對用戶使用，資源的利用率極低，該層是在邏輯上基於目前已有的物理連接，解決如何更好更快從一端傳輸到另一端的問題。主要功能包含：路由選擇，流量控制，數據順序，常見的協議爲：IP、ARP，ICMP等，數據單位：數據報 |
| 傳輸層 | 解決一臺設備多應用數據傳輸，提供流量控制、差錯控制等，常見的協議爲：TCP、UDP等，數據單位：數據段 |
| 會話層 | 該層的定義挺好的，見名知意，定義了網絡兩端應用程序建立連接、斷開連接、保持會話時長等。常見的協議爲：DNS、SSH等，數據單位：數據報 |
| 表現層 | 提供一種公共語言，確保發送的內容可以被其他設備識別，除此之外還提供編碼轉換，數據解析，管理數據的解密和加密等功能，常見協議：telnet |
| 應用層 | 面向應用程序提供數據傳輸服務。應用程序有啥功能，他就提供什麼服務，例如郵箱，提供發送郵件服務，常見協議：HTTP、HTTPS； |
正是分層架構將網絡數據傳輸一個複雜的問題逐層分解處理，使得應用軟件傳輸數據變得簡單很多，使得如今的軟件應用呈現百花齊放的態勢；
在硬件方面，工程師只需按照物理層的規範，無需關心本次的設計改造會對上游的影響不良影響，將注意力聚焦在覈心業務上，提高產品質量，助力行業發展，如5G技術。
2.2 經典三層分層
最簡單的分層架構模型。將數據操作、業務聚合邏輯、數據展示分開，核心目的是爲了 “高內聚，低耦合”。開發人員分工更明確，將精力更專注於應用系統核心業務邏輯的分析、設計和開發，加快項目的進度，提高了開發效率，有利於項目的更新和維護工作。由於三層架構太過簡單，具體就不詳細介紹了
2.3 DDD分層
傳統的領域分層是一種鬆散的分層架構，上一層可以依賴任意下游層級。但是一般實際落地的時候，建議還是使用嚴格的分層，即上一層只能直接依賴下一層結構，不可以跨層依賴。
| 層級說明 | 概述 |
|---|---|
| 用戶接口層 | 操作設備向服務器發的請求，服務器作出的響應結果，對應三層架構中的表現層。 |
| 應用層 | 協調多個服務和領域對象協作完成業務請求。 |
| 領域層 | 該層是軟件的核心，包含業務邏輯具體實現，包含實體、值對象、聚合、領域接口等； |
| 基礎設施層 | 依賴的應用程序服務等通用的技術、基礎服務、緩存、數據庫存儲、消息中間件等。基礎層以不同方式支持到其他三層，促進各層間通信。 |
3. 分層模型演進
3.1 單一應用-三層分層
最開始市面上比較流行的系統結構圖如下所示：
3.1.1，1.0架構
不同的客戶端通過不同網絡協議向服務器發起請求，服務器接收到請求後，解析網絡協議中的內容，轉發給表現層做基礎的權限、參數合法性、路由等邏輯處理，沒有問題轉交給服務層做具體業務邏輯處理，業務層根據參數聚合數據做對應處理，其中操作數據的部分交給存儲層，待服務層操作完畢後把結果轉交給表現層，表現層對數據做一定的加工渲染響應結果給客戶端。
此時誕生比較流行的技術有：SSH（Spring、Structs2、hibernate），Jsp等等，分層架構進入1.0時代。
3.1.2，1.5架構
隨着互聯網企業的興起，SSH逐漸暴露出缺點，如：
1，性能問題，Hibernate是完整的ORM框架，我們在操作pojo對象的時候都會最終操作到數據庫上，只是不能隨意操作pojo中的get/set方法，當做SQL優化的時候，Hibernate操作起來相對比較困難。 2，使用較爲複雜，Struts2請求很難支持Restful的URL，響應結果還需要在XML配置。
緊接着市面上出現了半自動化的ORM框架：Mybatis(之前叫ibatis)，新MVC框架：SpringMVC，替換之前Struts2、Hibernate。
於此同時國內的網民數量也在迅速增長，請求量相對之前翻了幾番，單臺機器已經無法應對巨大的訪問量，應對巨大訪問量的解決方案很多，其中橫向擴容的方式從中脫穎而出：在表現層上增加一層訪問層，分層架構進入1.5時代。
又過了幾年的發展，Spring生態蓬勃發展，創建一個Spring應用的成本越來越高，爲了簡化配置、整合Spring生態、快速創建一個Spring應用爲目標，出現了SpringBoot。內置了Tomcat，整合了SpringMVC、Spring、SpringJPA，在三層架構時期，單一應用多數痛點已被解決。
3.2 DDD分層架構模型
互聯網發展中期，單一應用的缺點逐漸暴露出來：
1，所有的應用都在一個項目中，團隊協作時代碼的衝突嚴重。
2，需求的不斷迭代導致項目逐漸臃腫，啓動時間長。
3，穩定性差，一些模塊的流量較大時會影響其他業務的使用。
4，等等
對於單一應用的解決方案首先想到的是就是系統拆分，其目的是將龐大的、複雜的、臃腫的系統拆輕量的微型服務，不僅解決了服務間的隔離問題，降低服務之間的耦合、內聚實體對，而且解決了傳統的單體應用在業務急劇增長時遇到的擴容問題，系統拆分後團隊可以節省精力來處理業務問題或優化系統。
在系統拆分的方法論中，DDD近幾年逐漸被各大公司所應用。
1，在 DDD分層架構中，重新定義了服務層：一個領域內核心業務邏輯實現層，通過聚合實體、值對象、實體行爲來完成支持業務。確定了層與層之間的交互規則和職責邊界。
2，在DDD領域劃分中，將產品、技術等相關人員通過統一語言的方式討論劃分系統，定義上下文含義，限界上下文則定義領域邊界，最終達成共識，沉澱領域知識。
3，在DDD實踐中，根據領域劃分是討論的名詞，找尋實體、值對象、和實體行爲等，探討實體間關係，生命週期等，完成子領域內的建模。
4，在大型系統交互中，通過上下文、精煉、大型結構三步來解決複雜的依賴、交互等問題。
系統拆分和微服務的興起標誌着系統分層進入2.0時代。
在小中型互聯網應用層中，DDD的實際落地一般不會將服務層拆成兩層，常見的落地是在接口層的中增加一個Manager來領域實體的聚合，Controller處理用戶的請求指令。
3.3 大型互聯網應用分層架構
此部分是DDD+大型互聯網的架構分層。
| 層級名稱 | 作用 |
|---|---|
| 客戶端 | 發起請求和指令的設備或程序 |
| 訪問層 | 用於web接入，反向代理，負載均衡，緩存等 |
| 接口層 | 用戶鑑權，服務轉發，會話管理等 |
| 服務層 | 業務服務的核心模塊，具備服務治理，調用，異步通信等核心服務能力 |
| 存儲代理層 | 用於提供透明的存儲結構的訪問代理 |
| 存儲層 | 最終數據的落地及提供數據的操作能力 |
一個請求經歷的流程：
1，客戶端發送請求經過DNS解析找到對應的LVS IP。
2，LVS根據配置的請求轉發模式，判斷如何轉發給請求，再根據配置的負載均衡策略將流量轉發給上游NGINX集羣。 3，上游服務器解析數據請求URL，根據負載均衡策略將請求轉發對應給應用NGINX集羣，將應用NGINX把結果響應給上有NGINX後，需要做數據響應壓縮等。
4，應用NGINX解析URL請求，判斷是否有權限訪問該URL，將要轉發到資源是否有能力處理請求，是否要做限流，判斷是否命中緩存等等功能，最後根據路由策略使用負載均衡將具體請求轉發給接口層。
5，接口層相當於又一層的NGINX，只不過這裏這裏會做具體業務上的解析校驗。該層解析請求拿到對應的Cookie/token/session等，獲取用戶信息等判斷是否有權限訪問資源，如果有，將流量轉發給對應的服務層或聚會服服務層的業務能力完成用戶的請求。如果機器壓力比較大，還可以做限流、降級等功能。接着調用服務層。
6，服務層提供領域內核心業務能力，在技術上需要保證服務通信、穩定性。在將系統按照領域拆分後，分析領域中的實體、值對象、實體行爲來確定提供的業務能力。系統拆分後，服務間一般都是通過RPC、MQ等技術實現子系統的通訊、橫向擴容等；分佈式的引入解決了橫向擴容等問題，但也會帶來新的問題：分佈式事務，冪等等；
7，隨着業務的發展，服務層機器的不斷增加，操作數據的連接數逐漸消耗殆盡、數據量與日俱增，性能也到了非處理不可的地方。爲此增加存儲代理層，代理一個或一羣后端的被訪問對象，使得被調用者看似在直接訪問後端對象一樣，代理訪問的代理器從而可以實現多種負載均衡、故障轉移、緩存策略等個性化配置，同時又可以分散被代理的後端對象壓力。
8，存儲層就是具體的數據落地的一層了。
4，總結
主要介紹爲什麼會分層，分層的演進史，目前常見的三種分層方式及每種分層的作用。