為什麼說，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個例項

當用戶提交作業時：

(1) 把資料資料傳輸給map服務叢集；

(2) map服務叢集產出結果後，把資料傳輸給reduce服務叢集；

(3) 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”的分層架構是合理的。
任何脫離業務的架構設計，都是耍流氓。

思考問題的本質，希望大家有收穫。
原文釋出時間為：2018-12-14
本文作者： 58沈劍
本文來自雲棲社群合作伙伴“ 架構師之路”，瞭解相關資訊可以關注“road5858”微信公眾號