为何说，MapReduce，颠覆了互联网分层架构的本质？
2020-07-31 14:00:59
- 客户端层：典型调用方是浏览器browser或者手机APP
- 站点应用层：实现核心业务逻辑，从下游获取数据，对上游返回html或者json
- 服务层：业务服务，数据服务，基础服务，对上游提供友好的RPC接口
同一个层次的内部，例如端上的APP，以及web-server，也都会进行MVC分层：
如果我们仔细思考会发现，不管是跨进程的分层架构，还是进程内的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个实例
(2) map服务集群产出结果后，把数据传输给reduce服务集群；画外音：输入给map，map给reduce，reduce给用户。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，移动数据”的分层架构是合理的。这类业务，使用“固定数据，移动CPU”的分层架构是合理的。
