“互联网+”架构这个题目太大，要谈清楚这个架构的来龙去脉以及其中演变不容易。稍微不小心就容易挂一漏万，贻笑大方。所以决定要改变想到哪，写到哪的习惯，从总体上做一个规划。
云计算双雄——谷歌和亚马逊
谷歌和亚马逊引领分布式系统革命的四篇论文(谷歌关于GFS、Map/Reduce、Bigtable的三篇论文以及亚马逊一篇关于Dynamo的论文)为基础，涉及了云计算架构、Hadoop/Spark大数据生态平台、软件定义网络、软件定义存储、软件定义数据中心、Docker容器、Mesos和Kubernetes容器集群管理、微服务架构、比特币区块链、Peer-to-Peer全分布式架构、互联网+安全架构等一系列概念和技术。而谈完基础架构，然后就要针对不同的行业，讨论互联网+架构的特点，包括金融、电信等。行业方面的互联网+架构最难，需要找到具有实践经验的行业专家来提供第一手材料。
说完规划，我们回过头来谈谷歌的三篇著名论文。2003年到2004年，Google陆续发表了关于GFS、MapReduce和BigTable的三篇论文，基本上公开了谷歌内部用于处理搜索海量数据的平台架构。GFS是大规模的分布式文件系统，MapReduce是一个并行处理框架下的编程模式，BigTable是建立在GFS基础上一个按键值方式组织的非关系型数据库。由于当时的技术、产品和平台无法满足谷歌快速增长的业务发展，谷歌根据搜索业务的特点，大胆创新，打破了传统分布式文件系统的条条框框，开发了一个支持大规模扩展性的容错分布式文件系统，并在其基础上构建了并行计算平台和分布式数据库，使得谷歌的搜索平台能处理前所未有并不断爆炸性增长的海量数据。
下面我们简单介绍一下这三篇论文的重点：
谷歌的第一篇论文是详实的介绍了谷歌内部使用的分布式文件系统GFS。谷歌的GFS与其它分布式文件系统的设计理念不同，首先，GFS特别强调容错性。它的设计思想是在大规模分布式系统下，采用廉价硬件来构建分布式平台，系统各环节都会出错，因此出错不像传统系统设计那样当特例来处理，而是把出错作为常态来处理。第二，GFS的设计场景是处理多GB级甚至TB级的大文件，与传统分布式文件系统多数处理小文件不同。第三，大部分谷歌的搜索应用特点是追加文件而不是修改文件，几乎没有随机写的情形。写入后大部分的动作是读，而且是顺序读。第四，同时设计应用和文件系统API以提高系统灵活性。例如谷歌提供一个原子追加文件操作，可以让多客户端同时对一个文件进行追加操作而不需要同步客户端的操作。GFS采用一个集中式主从架构，主节点(Master)管理元数据，从节点(Chunk Server)存储数据。文件分成一块块固定长度64MB的块，存放在从节点上。每一块数据都同时存放在多个从节点上作为冗余备份以提供容错和高可用性。GFS不提供POSIX兼容支持，因此客户端不能像传统分布式文件系统那样直接挂载，只能通过GFS的客户端来和主节点、从节点通信以读写数据。除GFS客户端缓存元数据外，客户端和从节点不缓存数据。GFS通过持续监控、数据一致性校验，多副本、快速自动修复等手段来提供高可用和容错性。GFS的这些特点，开创性的奠定了大数据处理分布式文件系统的基础。
谷歌的第二篇论文是关于一个并行分布式处理系统的编程框架——MapReduce。用户使用Map函数来处理键值对的数据，同时生成中间过程的键值对，然后通过Reduce函数来合并相同的所有对应相同键的值。用户只需要写这两个函数，然后谷歌的MapReduce运行系统会自动的切分数据，并把任务分配到不同节点上，实现自动调度、均衡工作负载，同时自动监控、自动修复错误，管理节点间通信。传统的并行处理应用，需要开发者掌握MPI编程等技能，一般只是限于高性能计算领域。而MapReduce框架简化了并行处理系统的编程，大大降低了开发者开发并行处理系统的门槛。和GFS的设计思想类似，MapReduce也采用主从架构，Master负责将任务分发给Worker。Map和Reduce的名字来源于MapReduce设计者从Lisp语言中的Map和Reduce函数带来的灵感。
谷歌的第三篇论文公开的是谷歌内部使用的一个分布式数据库——BigTable。该数据库是用来管理PB级的结构化数据，并实现广泛应用性、高扩展性、高可用性、高性能的设计目标。和传统关系型数据库不一样，BigTable不提供关系数据库接口，它的数据模型是非常有特点，一个BigTable是一个稀疏的、分布的、永久的多维排序图。BigTable采用行键(rowkey)、列键(columnkey)和时间戳(timestamp)对图进行索引，数据是字符串，没有传统数据库的字段定义(Schema)，因此BigTable实际上是一种基于多维键值模型的NoSQL数据库。
BigTable也是采用集中式架构，BigTable实现包括三个主要的功能组件：一是库函数，链接到每个客户端;二是一个主服务器;三是许多的Tablet服务器。Tablet服务器可以根据工作负载的变化，从一个簇中动态地增加或删除。主服务器负责把Tablet分配到Tablet服务器，探测Tablet服务器的增加和过期，进行Tablet服务器的负载均衡，以及GFS文件系统中的垃圾收集。除此以外，它还处理模式变化，比如表和列家族创建。每个Tablet服务器管理一个Tablet集合，通常，在每个Tablet服务器上会放置10到1000个Tablet。
BigTable客户端并不是通过主服务器来读取数据，而是直接从Tablet服务器上读取数据。因为BigTable客户端并不依赖于主服务器来获得Tablet的位置信息，从而使得在实际应用中，主服务器负载很小。一个BigTable簇存储了许多表。每个表都是一个Tablet集合，每个Tablet包含了位于某个域区间内的所有数据。在最初阶段，每个表只包含一个Tablet。随着表的增长，它会被自动分解成许多Tablet，每个Tablet默认尺寸大约是100到200MB。BigTable的数据最后是存放在GFS文件系统上，使用分布式锁Chubby来保证数据一致性。
谷歌的三篇论文奠定了互联网大规模分布式系统的架构基础，掀启了大数据时代的帷幕。谷歌的贡献主要是基于其自身的业务需求，在对比传统分布式架构优劣势的基础上，提出了一套全新的分布式存储、分布式并行计算和分布式数据库的架构。其特点还是在集中管理下的可扩展分布式系统。
谷歌是首先提出云计算概念的公司，而另一个首创云计算业务模式的亚马逊也不甘落后，于2007年发表了Dynamo分布式数据库论文。与谷歌相同的是，亚马逊也是根据自身的业务特点来做创新，都将系统出错作为常态处理;而与谷歌不同的是，亚马逊采用了一个无中心、完全分布式的架构。下面我们简单介绍Dynamo论文的要点：
亚马逊的Dynamo论文公开了分布式键值数据库Dynamo的设计和实施细节。Dynamo的设计主要是针对大规模电商的应用场景，例如购物车，需要提供“Always on”(总是在线)，任何时候用户都能修改，也就是高可用的客户体验。其设计目标是把可用性提到第一位，在某些场合牺牲一致性。Dynamo论文很明确的提出“Eventual Consistency”(最终一致性)的概念。其设计理念参考Peer-to-Peer架构，整个分布式系统采用无中心架构。Dynamo综合了一些著名的技术来实现可伸缩性和可用性：数据划分(Data partitioned)和使用一致性哈希的复制(replicated)，并通过对象版本(object versioning)提供一致性。在更新时，副本之间的一致性是由仲裁(quorum)中心化的副本同步协议来维持的。Dynamo中一共涉及三个重要的参数，其中N代表数据的副本数，W代表一次写操作的最小必须写成功节点数;R达标一次读操作的最小读成功节点数。要求W+R>N，读数据时，只要有除了Coodinator之外的R-1个节点返回了数据，就算是读成功(此时可能返回多个版本的数据)。同理，写数据时，只要有除Coordinator之外的W-1个节点写入成功，就算数据写入成功。Dynamo采用了基于gossip协议分布式故障检测及成员(membership)协议。Dynamo只需要很少的人工管理，存储节点可以添加和删除，而不需要任何手动划分或重新分配(redistribution)。Dynamo很早就成为Amazon电子商务平台的核心服务的底层存储技术，它能够有效地扩展到极端高峰负载，在繁忙的假日购物季节没有任何的停机时间。
Dynamo和BigTable都属于非关系型数据库，也就是常说的NoSQL数据库。但两者设计理念有很大的不同。Dynamo是完全无中心的设计，其假设是在内部信任网络部署，没有安全的措施。而BigTable是集中式管理，利用权限控制来提供安全措施。Dynamo的数据模型是键值模型，而BigTable是多维排序图。Dynamo采用一致性哈希来实现分布式元数据管理，而BigTable采用集中式的元数据管理。两者的适应场景也各不相同。Dynamo主要针对电商购物车应用，对可用性要求高，一致性要求不高。在CAP(见上期CAP的解释)上强调对A(可用性)和P(分区容错性)的要求，是一个典型的AP数据库。而BigTable对一致性和可扩展性的要求比较高，比较适合处理结构化的数据，是一个典型的CP数据库。
互联网双雄的这几篇论文，内容非常详实，基本上公开了从设计到实施的细节。当时在Yahoo的Doug Cutting受到Google三篇论文的启发，组织了Hadoop项目组，开发了风靡一时的Hadoop大数据平台。Hadoop的HDFS实际上是GFS的开源实现，HBase是BigTable的实现，Hadoop的MapReduce也是Google的MapReduce的开源实现。著名的Cassandra数据库则是结合Dynamo和BigTable两者的优势实现的NoSQL数据库。
看完这几篇论文，一个很大的感触是谷歌和亚马逊的创新，都是基于他们各自实际的业务需求，都是从实际出发，突破传统架构的条条框框来做创新。而我们看到更多的IT公司则是跟随者，甚至是生搬硬套一些当下流行的技术或框架。例如，在大数据炙手可热的今天，我们看到一个“大数据宗教”正在兴起，不管业务场景是什么，言必称大数据，甚至一些用Excel表都能做的数据分析，也有很多人不惜搭一个Hadoop平台来号称大数据项目。这使笔者想起毛泽东生前最反对的就是教条主义，最提倡的是实事求是。当初以王明为首的国际派，就是生搬苏联模式来指导中国革命而造成巨大损失。IT也一样，必须一切从实际出发，从客户需求出发，否则就会造成资源浪费而不能解决实际问题。
另外一个感触，也是一个问题，就是为什么像谷歌和亚马逊会公开这些这么重要的架构设计和技术细节?如果单从商业角度来看，这些都应该是高度商业机密。但是从另一角度看也容易理解，从谷歌和亚马逊这些公司来说，挣钱从来就不是他们的唯一目的，引领互联网架构变革和技术方向，成为行业的领军企业才是像谷歌和亚马逊这样志存高远的公司所追求的目标。谷歌在这方面一直引领潮流，大幅超越其他IT公司。当大部分互联网公司还在围绕着谷歌的老三篇论文或是Hadoop做大数据平台的时候，谷歌在2010年又发布了后Hadoop时代的新三篇论文，分别是Caffeine、Pregel和Dremel。后续我们会对新三篇论文进行解读。
【文章来源：云梦园微信公众号】
