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

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

• 客戶端層：典型調用方是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的結論，本身就是不負責任的。

總結

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

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

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