爲何說，MapReduce，顛覆了互聯網分層架構的本質？

爲何說，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」的分層架構是合理的。

任何脫離業務的架構設計，都是耍流氓。
思考問題的本質，但願你們有收穫。

架構師之路-分享可落地的技術文章

相關推薦：《GFS架構啓示》《Google MapReduce解決什麼問題？》《Google MapReduce巧妙優化思路？》《Google MapReduce架構設計實踐》《互聯網分層架構的本質》