上圖是一個典型的互聯網分層架構：

• 客戶端層：典型調用方是browser或者APP
• 站點應用層：實現核心業務邏輯，從下游獲取數據，對上游返回html或者json
• 數據-緩存層：加速訪問存儲
• 數據-數據庫層：固化數據存儲

如果實施了服務化，這個分層架構圖可能是這樣：

中間多了一個服務層。

同一個層次的內部，例如端上的APP，以及web-server，也都有進行MVC分層：

• view層：展現
• control層：邏輯
• model層：數據

可以看到，每個工程師骨子里，都潛移默化的實施著分層架構。

那么，互聯網分層架構的本質究竟是什么呢?

如果我們仔細思考會發現，不管是跨進程的分層架構，還是進程內的MVC分層，都是一個“數據移動”，然后“被處理”和“被呈現”的過程，歸根結底一句話：互聯網分層架構，是一個數據移動，處理，呈現的過程，其中數據移動是整個過程的核心。

如上圖所示：

數據處理和呈現要CPU計算，CPU是固定不動的：

• db/service/web-server都部署在固定的集群上
• 端上，不管是browser還是APP，也有固定的CPU處理

數據是移動的：

• 跨進程移動：數據從數據庫和緩存里，轉移到service層，到web-server層，到client層
• 同進程移動：數據從model層，轉移到control層，轉移到view層

數據要移動，所以有兩個東西很重要：

• 數據傳輸的格式
• 數據在各層次的形態

先看數據傳輸的格式，即協議很重要：

• service與db/cache之間，二進制協議/文本協議是數據傳輸的載體
• web-server與service之間，RPC的二進制協議是數據傳輸的載體
• client和web-server之間，http協議是數據傳輸的載體

再看數據在各層次的形態，以用戶數據為例：

• db層，數據是以“行”為單位存在的row(uid, name, age)
• cache層，數據是以kv的形式存在的kv(uid -> User)
• service層，會把row或者kv轉化為對程序友好的User對象
• web-server層，會把對程序友好的User對象轉化為對http友好的json對象
• client層：最終端上拿到的是json對象

結論：互聯網分層架構的本質，是數據的移動。

為什么要說這個，這將會引出“分層架構演進”的核心原則與方法：

• 讓上游更高效的獲取與處理數據，復用
• 讓下游能屏蔽數據的獲取細節，封裝

弄清楚這個原則與方法，再加上一些經驗積累，就能回答網友經常在評論中提出的這些問題了：

• 是否需要引入DAO層，什么時機引入
• 是否需要服務化，什么時機服務化
• 是否需要抽取通用中臺業務，什么時機抽取
• 是否需要前后端分離，什么時機分離

(網友們的這些提問，其實很難回答。在不了解業務發展階段，業務規模，數據量并發量的情況下，妄下YES或NO的結論，本身就是不負責任的。)

更具體的分層架構演進細節，下一篇和大家細究。

總結

• 互聯網分層架構的本質，是數據的移動
• 互聯網分層架構中，數據的傳輸格式(協議)與數據在各層次的形態很重要
• 互聯網分層架構演進的核心原則與方法：封裝與復用

思考

哪一個系統的架構，不是“固定CPU，移動數據”，而是“固定數據，移動CPU”呢?

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文