經常有朋友問我，為什么要做分層架構，什么時候架構要抽象一層，今天來聊一聊這個問題。
上圖是一個典型的互聯網分層架構：
（1）客戶端層：典型調用方是browser或者App；
（2）站點應用層：實現核心業務邏輯，從下游獲取數據，對上游返回html或者json；
（3）數據-緩存層：加速訪問存儲；
（4）數據-數據庫層：固化數據存儲；
如果實施了服務化，這個分層架構圖可能是這樣：
中間多了一個服務層。
同一個層次的內部，例如端上的APP，以及web-server，也都有進行MVC分層：
（1）view層：展現；
（2）control層：邏輯；
（3）model層：數據；
可以看到，每個工程師骨子里，都潛移默化的實施著分層架構。
那么，互聯網分層架構的本質究竟是什么呢？
如果我們仔細思考會發現，不管是跨進程的分層架構，還是進程內的MVC分層，都是一個“數據移動”，然后“被處理”和“被呈現”的過程，歸根結底一句話：互聯網分層架構，是一個數據移動，處理，呈現的過程，其中數據移動是整個過程的核心。
如上圖所示，數據處理和呈現要CPU計算，CPU是固定不動的：
（1）db/service/web-server都部署在固定的集群上；
（2）端上，不管是browser還是APP，也有固定的CPU處理；
數據是移動的：
（1）跨進程移動：數據從數據庫和緩存里，轉移到service層，到web-server層，到client層；
（2）同進程移動：數據從model層，轉移到control層，轉移到view層；
數據要移動，所以有兩個東西很重要：
（1）數據傳輸的格式；
（2）數據在各層次的形態；
先看數據傳輸的格式，即協議很重要：
（1）service與db/cache之間，二進制協議/文本協議是數據傳輸的載體；
（2）web-server與service之間，RPC的二進制協議是數據傳輸的載體；
（3）client和web-server之間，http協議是數據傳輸的載體；
再看數據在各層次的形態，以用戶數據為例：
（1）db層，數據是以“行”為單位存在的row(uid, name, age)；
（2）cache層，數據是以kv的形式存在的kv(uid -> User)；
（3）service層，會把row或者kv轉化為對程序友好的User對象；
（4）web-server層，會把對程序友好的User對象轉化為對http友好的json對象；
（5）client層：最終端上拿到的是json對象；
結論：互聯網分層架構的本質，是數據的移動。
為什么要說這個，這將會引出“分層架構演進”的核心原則與方法：
（1）讓上游更高效的獲取與處理數據，復用；
（2）讓下游能屏蔽數據的獲取細節，封裝；
有了上面的鋪墊，水友經常問的這些問題：
（1）是否需要引入DAO層，什么時機引入；
（2）是否需要服務化，什么時機服務化；
（3）是否需要抽取通用中臺業務，什么時機抽取；
（4）是否需要前后端分離，什么時機分離；
就非常好回答了，下期和大家深究。
畫外音：網友們的這些提問，其實很難回答。在不了解業務發展階段，業務規模，數據量并發量的情況下，妄下YES或NO的結論，本身就是不負責任的。
總結
（1）互聯網分層架構的本質，是數據的移動；
（2）互聯網分層架構中，數據的傳輸格式（協議）與數據在各層次的形態很重要；
（3）互聯網分層架構演進的核心原則與方法：封裝與復用；
