為何說，MapReduce，顛覆了互聯網分層架構的本質？
下圖是一個典型的，互聯網分層架構：
- 客戶端層：典型調用方是瀏覽器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沈劍”原創稿件，轉載請聯系原作者】
