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