經常有朋友問我，為什麼要做分層架構，什麼時候架構要抽象一層，今天來聊一聊這個問題。

上圖是一個典型的網際網路分層架構：

（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）網際網路分層架構演進的核心原則與方法：封裝與複用；