原文地址：http://mp.weixin.qq.com/s/4UB4AZe2R0lVCT6f5ExEMw
上圖是一個典型的互聯網分層架構：
客戶端層：典型調用方是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”呢？