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

• 客戶端層：典型調用方是瀏覽器browser或者手機APP
• 站點應用層：實現核心業務邏輯，從下游獲取數據，對上游返回html或者json
• 服務層：業務服務，數據服務，基礎服務，對上游提供友好的RPC接口
• 數據緩存層：緩存加速訪問存儲
• 數據固化層：數據庫固化數據存儲

同一個層次的內部，例如端上的APP，以及web-server，也都會進行MVC分層：

• view層：展現
• control層：邏輯
• model層：數據

工程師骨子里，都潛移默化的實施著分層架構設計。

互聯網分層架構的本質究竟是什么呢?

如果我們仔細思考會發現，不管是跨進程的分層架構，還是進程內的MVC分層，都是一個“數據移動”，然后“被處理”和“被呈現”的過程。

如上圖所示：數據處理和呈現，需要CPU計算，而CPU是固定不動的：

• db/service/web-server都部署在固定的集群上
• 端上，不管是browser還是APP，也有固定的CPU處理

而數據是移動的：

• 跨進程的：數據從數據庫和緩存里，轉移到service層，到web-server層，到client層
• 同進程的：數據從model層，轉移到control層，轉移到view層

歸根結底一句話：互聯網分層架構，是一個CPU固定，數據移動的架構。

MapReduce的架構，是不是也遵循這個架構特點呢?

假如MapReduce也使用類似的的分層架構模式：

提前部署服務：

• map服務層：接收輸入數據，產出“分”的數據，集群部署M=1W個實例
• reduce服務層：接受“合”的數據，產出最終數據，集群部署R=1W個實例

當用戶提交作業時：

• 把數據數據傳輸給map服務集群;
• map服務集群產出結果后，把數據傳輸給reduce服務集群;
• reduce服務集群把結果傳輸給用戶;

存在什么問題?

將有大量的時間浪費在大量數據的網絡傳輸上。

畫外音：輸入給map，map給reduce，reduce給用戶。

會發現，“固定CPU，移動數據”的架構并不適合。

Google MapReduce工程架構是如何思考這一個問題的呢?

為了減少數據量的傳輸：

(1) 輸入數據，被分割為M塊后，master會盡量將執行map函數的worker實例，啟動在輸入數據所在的服務器上;

畫外音：不需要網絡傳輸了。

(2) map函數的worker實例輸出的的結果，會被分區函數劃分成R塊，寫到worker實例所在的本地磁盤;

畫外音：不需要網絡傳輸了。

(3) reduce函數，由于有M個輸入數據源(M個map的輸出都有一部分數據可能對應到一個reduce的輸入數據)，所以，master會盡量將執行reduce函數的worker實例，啟動在離這些輸入數據源盡可能“近”的服務器上;

• 畫外音：目的也是最小化網絡傳輸;
• 服務器之間的“近”，可以用內網IP地址的相似度衡量。

所以，對于MapReduce系統架構，“固定數據，移動CPU”更為合理。

這是為什么呢?

互聯網在線業務的特點是：

• 總數據量大
• 吞吐量比較大，同時發起的請求多
• 每個請求，處理的數據相對比較小
• 用戶對處理時延比較敏感

這類業務，使用“固定CPU，移動數據”的分層架構是合理的。

MapReduce離線業務的特點是：

• 吞吐量比較小，同時發起的任務比較少
• 每個任務，處理的數據量非常大
• 用戶對處理時延容忍性大

這類業務，使用“固定數據，移動CPU”的分層架構是合理的。

任何脫離業務的架構設計，都是耍流氓。

思考問題的本質，希望大家有收獲。

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

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