从技术演变的角度看互联网后台架构

 

这是去年在部门内部作的一个面向后台开发新同窗的课程，由于其余BG一些同窗要求分享，因此发一下。

其实内容都是些常见开源组件的high level描述，好比flask, express框架，中间件的演化，micro service的概念，一些对nosql/column based db的概念介绍，docker的一些简单概念等等。从单个概念来讲，这只是一些科普。

可是为何当时要开这门课呢？重点是我发现不少新入职的后台开发同窗并不太清楚本身作的东西在现代互联网总体架构中处于一个什么样的角色，而在IEG内部则由于游戏开发和互联网开发的一些历史性差别，有些概念并不清晰。

拿中间件来讲，不少web application不用啥中间件同样能够跑很好，那么是否是都要上redis？到底解决什么问题？中间件又存在什么问题？中台和中间件又是个什么关系？若是开个mq就是中间件，微服务又是要作啥？

若是能从这十多年来互联网应用的整个tech stack变化去看待backend architecture的一些改变，应该是一件有趣也有意思的事情。这是当时写这个ppt开课的初衷。

我不敢说我在这个ppt里面的一些私货概念就是对的，可是也算是我的这么多年的一些认知理解，抛砖引玉吧。

强调一点，这个ppt的初衷是但愿从近十多年来不一样时代不一样热点下技术栈的变化来看看咱们是如何从最先的php/asp/jsp<=>mysql这样的两层架构，一个阶段一个阶段演变到如今繁复的大数据、机器学习、消息驱动、微服务架构这样的体系，而后在针对其中比较重要的几个方面来给新入门后台开发的同窗起个“提纲目录”的做用。若是要对每一个方面都深刻去谈，那确定不是一两页PPT就能作到的事情。

下面咱们开始。首先看第一页以下图：什么是System Design?什么是架构设计？为何要谈架构设计？

之因此抛出这个问题，是由于平时经常听到两个互相矛盾的说法：一方面不少人爱说“架构师都是不干活夸夸其谈”，另外一方面又有不少人苦恼限于平常业务需求开发，没法或者没有机会去从总体架构思考，不知道怎么成长为架构师。

上面ppt中颇有趣的是第一句英文，翻译过来刚好能够反映了论坛上常常有人问的“如何学习架构”的问题：不少leader一来就是扔几本书（书名）给新同窗，指望他们读完书就立刻升级。。。这种通常都只会带来失望。

何为架构师？不写代码只画PPT？

不是的，架构师的基本职责是要在项目早期就能设计好基本的框架，这个框架可以确保团队成员顺利coding知足近期内业务需求的变化，又能为进一步的发展留出空间（所谓scalability），这便是所谓技术选型。如何确保选型正确？对于简单的应用，或者没有新意彻底是实践过屡次的相同方案，确实靠几页PPT足矣。可是对于新的领域新的复杂需求，这个需求未必都是业务需求，也包括根据团队自身特色（人员太多、太少、某些环节成员不熟悉须要剥离开）来进行新的设计，对现有技术从新分解组合，这时候就须要架构师本身编码实现原型并验证思路正确性。

要达到这样的目标难不难？难！可是如今不是2000年了，是2019年了，大量的框架(framework)、开源工具和各类best practice，其实都是在帮咱们解决这件事情。而这些框架并非凭空而来，而是在这十多年互联网的演化中由于要解决各类具体业务难点而一点一点积累进化而来。不管是从mysql到mongodb到cassandra到time series db，或者从memcached到redis，从lucene到solr到elasticsearch，从离线批处理到hadoop到storm到spark到flink，技术不是忽然出现的，老是站在前人的肩膀上不断演变的。而要能在浩如烟海的现代互联网技术栈中选择合适的来组装本身的方案，则须要对技术的来源和历史有必定的了解。不然就会出现一些新人张口ELK，闭口tensorflow，而后一个简单的异步消息处理就会让他们张口结舌的现象。

20多年前的经典著做DesignPatterns中讲过学习设计模式的意义，放在这里很是经典：学习设计模式并非要你学习一种新的技术或者编程语言，而是创建一种交流的共同语言和词汇，在方案设计时方便沟通，同时也帮助人们从更抽象的层次去分析问题本质，而不被一些实现的细枝末节所困扰。同时，当咱们能把不少问题抽象出来以后，也能帮咱们更深刻更好地去了解现有系统-------这些意义，对于今天的后端系统设计来讲，也仍然是正确的。

下图是咱们要谈的几个主要方面。

上面的几个主题中，第一个后台架构的演化是本身从业十多年来，体会到的互联网技术架构的总体变迁。而后分红后台前端应用框架、middleware和存储三大块谈一下，最后两节微服务和docker则是给刚进入后台开发的同窗作一些概念普及。其中我的以为最有趣的，是第一部分后台架构的演化和第三部分的中间件，由于这二者是很好地反映了过去十多年互联网发展期间技术栈的变化，从LAMP到MEAN Stack，从各类繁复的中间层到渐渐统一的消息驱动+流处理，每一个阶段的业界热点都至关有表明性。

固然，不是说web框架、数据存储就不是热点了，姑且不说这几年web前端的复杂化，光后端应用框架，node的express，python的django/flask，go在国内的盛行，都是至关有趣的。在数据存储领域，列存储和时序数据随着物联网的发展也是备受重视。可是篇幅所限，在这个课程中这些话题也就只能一带而过，由于这些与其说是技术的演变过程，不如说是不一样的技术选型和方向了，好比说Mysql适合OLTP（Online Transaction Processing），而Cassandra/Hbase等则适合OLAP(Online Analyical Processing)，并不能说后者就优于前者。

下面咱们先来看后台架构的演化

严格说这是个很大的标题，从2000年到如今的故事太多了，我这里只能尽力而为从我的体验来分析。

首先是2008年之前，我把它称为网站时代。为何这么说？由于那时候的后台开发就是写网站，并且一般是页面代码和后台数据逻辑一块儿写。你只要能写JSP/PHP/ASP来读写Mysql或者SQL Server，基本就能保证一份不错的工做了。

要强调一下，这种简单的两层结构并不能说就是落后。在如今各个企业、公司以及小团队的大量web应用包括移动App的后端服务中，采用这种架构的不在少数，尤为是不少公司、学校、企业的内部服务，用这种架构已经足够了。

注意一个时间节点：2008。

固然，这个节点是我YY的。这个节点能够是2007，或者2006。这个时间段发生了两个影响到如今的事情：google上市，facebook开始推开

我我的相信前者上市加上它发表的那三篇大数据paper影响了后来业界的技术方向，后者的火热则形成了社交成为业务热点。恰恰社交网站对大数据处理有着自然的需求，技术的积累和业务的需求就这么阴差阳错完美结合了起来，直接影响了大海那边后面的科技发展。

同时在中国，那个时候倒是网络游戏MMO的黄金年代，对单机单服高并发实时交互的需求，远远压过了对海量数据data mining的须要，在这个时间点，中美两边的互联网科技树发生了比较大的分叉。这却是并无优劣之说，只是业务场景的重要性致使了技能树的侧重。直到今天，单机(包括简单的多服务器方案)高并发、高QPS仍然也是国内业界所追求的目标，而在美国那边，这只是一个业务指标而已，更看重的是如何进行水平扩展(horizontal scaling)和分散压力。

国内和美国的科技树回到一条线上，大数据的业务需求和相关技术发展紧密结合起来，可能要到2014年左右，随着互联网创业的盛行，O2O业务对大数据实时处理、机器学习推荐提出了真正的需求时，才是国内业界首次出现技术驱动业务，算法驱动产品的现象，从新和美国湾区那边站在了一条线上，而这则是后话了。

到了2010年先后，facebook在全球已是现象级产品，当时微软直接放弃了windows live，就是为了不在社交领域硬怼facebook。八卦一下当时在美国湾区那边聚餐的时候，若是谁说他是facebook的，那基本就是全场羡慕的焦点。

facebook的崛起也带动了其余大量的社交网站开始出现，社交网站最大的特色就是频繁的用户搜索、推荐，当用户上亿的时候，这就是前面传统的两层架构没法处理的问题了。所以这就带动了中间件的发展。实际上在国外不多有人用中间件或者middelware这个词，更可能是探讨如何把各类service集成在一块儿，像国内这样强行分红frontend/middleware/storage的概念是没听人这么谈过的，后面中间件再说这问题。当时的一个惯例是用php作所谓的胶水语言(glue language)，而后经过hessian这些协议工具来把其余java服务链接到一块儿。与此同时，为了提升访问速度，下降后端查询压力，memcached/redis也开始大量使用。基于lucene的搜索（2010左右不少是自行开发）或者solr也被用在用户搜索、推荐以及type ahead这些场景中。

我记忆中在2012年以前消息队列的使用还不是太频繁，不像后来这么重要。当时常见的应该就是beanstalkd/rabbitmq, zeromq其实我在湾区那边不多听人用，却是后来回国后看到国内用的人还很多。Kafka在2011年已经出现了，有少部分公司开始用，不过还不是主流。

2013年以后就是大数据+云的时代了，若是你们回想一下，基本上国内也是差很少在2014年左右开始叫出了云+大数据的口号（2013年国内还在手游狂潮中...）。不谈国外，在中国那段时间就是互联网创业的时代，从千团大战到手游爆发到15年开始的O2O，业务的发展也带动了技术栈的飞速进步。左上角大体上也写了这个时代互联网业界的主要技术热点，实际上这也就是如今的热点。不管国内国外，绝大部分公司还并无离开云+大数据这个时代。不管是大数据的实时处理、数据挖掘、推荐系统、Docker化，包括A/B测试，这些都是不少企业还正在努力全面解决的问题。

可是在少数站在业界技术顶端或者没有历史技术包袱的新兴公司，从某个角度上来讲，他们已经开始在往下一个时代前进：机器学习AI驱动的时代

2018年开始，实际上多是2017年中开始，AI驱动成了各大公司口号。上图是facebook和uber的机器学习平台使用状况，基本上已经所有进入业务核心。固然并非说全部公司企业都要AI驱动，显然最近发生的波音737事件就说明该用传统的就该传统，别啥都往并不成熟的AI上堆。但另外一方面，不少新兴公司的业务自己就是基于大数据或者算法的，所以他们在这个领域也每每走得比较激进。因为这个AI驱动还并无一个很明确的定义和概念，还处于一种早期萌芽的阶段，在这里也就很少YY了。

互联网后台架构发展的简单过程就在这里讲得差很少了，而后咱们快速谈一下web开发框架。

首先在前面我提到，在后端架构中其实也有所谓的frontend(前台）开发存在，通常来讲这是指响应用户请求，实现具体业务逻辑的业务逻辑层。固然这么定义略微粗糙了些，不少中间存储、消息服务也会封装一些业务相关逻辑。总之web开发框架每每就是为了更方便地实现这些业务逻辑而存在的。

前文提到在一段较长时间内，国内的技术热点是单机高并发高QPS，所以不少那个时代走过来的人会本能地质疑web框架的性能，而更偏好TCP长连接甚至UDP协议。然而这每每是自寻烦恼，由于除开特别的强实时系统，不管是休闲手游、视频点播仍是信息流，都已是基于HTTP的了。

上图所提到的两个问题中，我想强调的是第一点：全部的业务，在能知足需求的状况下，首选HTTP协议进行数据交互。准确点说，首选JSON，使用web API。

Why? 这就是上图第一个问题所回答的：无状态、易调试易修改、通常没有80端口限制。

最为诟病的无非是性能，然而实际上对非实时应用，晚个半秒一秒不该该是大问题，要考虑的是水平扩展scalability，不是实时响应（由于前提就是非实时应用）；其次实在不行你还有websocket能够用。

这一部分是简单列举了一下不一样框架的使用，能够看出不一样框架的概念其实差很少。重点是要注意到middleware这个说法在web framework和后端架构中的意义不一样。在web framework中是指具体处理GET/POST这些请求以前的一个通用处理（每每是链式调用），好比能够把鉴权、一些日志处理和请求记录放在这里。但在后端架构设计中的middleware则是指相似消息队列、缓存这些在最终数据库以前的中间服务组件。

 

最后这里是想说web framework并非包治百病，实际上那只是提供了基础功能的一个library，做为开发者则更多须要考虑如何定义配置文件，一些敏感参数如token、密码怎么传进来，开发环境和生产环境的配置如何自动切换，单元测试怎么搞，代码目录怎么组织。有时候咱们能够用一些好比Yeoman之类的scaffold工具来自动生成项目代码框架，或者相似django这种也可能自动生成基本目录结构。

下面进入Middleware环节。again，强调一下这里只是根据我的经验和感觉谈谈演化过程。

这一页只是大体讲一下怎么定义中间件middleware。说句题外话，在美国湾区那边提这个概念的不多，而阿里又特别喜欢说中间件，二者相互的交流很是头痛。湾区那边很多google、facebook还有pinterest/uber这些的朋友好几回都在群里问说啥叫中间件。

中间件这个概念很含糊，应该是阿里提出来的，对应于middleware（不过彷佛也不是彻底对应），多是由于早期java的EJB那些概念里面比较强调middleware这一点吧（我的猜的）。大体上，若是咱们把web后端分为直接处理用户请求的frontend，最后对数据进行持久存储(persistant storage)这两块，那么中间对数据的全部处理环节均可以视为middleware。

和中间件对应的另外一个阿里发明的概念是中台。近一年多阿里的中台概念都至关引人注意，这里对中台不作太多描述。整体来讲中台更可能是偏向业务和组织架构划分，不能说是一个技术概念，也不是面向开发人员的。而中间件middleware是标准的技术组件服务。

那么咱们天然会有一个问题：为何要用中间件？

谈到为何要用middlware，这里用推荐系统举例。

推荐系统，对数据少用户少的状况下，简单的mysql便可，好比早期论坛的什么top 10热门话题啊，最多回复的话题啊，均可以视为简单的推荐，数据量又不大的状况下，直接select就能够了。

若是是用户推荐的话，用户量不大的状况下，也能够如法炮制，选择同一区域（城市）年龄至关的异性，最后随机挑几个给你，相信世纪佳缘之类的交友网站早期实现也就是相似的模式。

那么，若是用户量多了呢？每次都去搜数据库，同时在线用户又多，那对数据库的压力就巨大了。这时候就是引入缓存，memcached、redis就出现了。

简单的作法就是把搜索条件做为key，把结果做为value存入缓存。打个比方你能够把key存为 20:40:beijing:male (20到40岁之间北京的男性），而后把第一次搜索的结果所有打乱shuffle后，存前1000个，10分钟过时，再有人用相似条件搜索，就直接把缓存数据随机挑几个返回。放心，通常来讲不会有人10分钟就把1000个用户的资料都看完了，中间偶有重复也没人在乎（用世纪佳缘、百合网啥的时候看到太重复的吧）。

不过话又说回来，现代数据库，尤为是相似mongodb/es这些大量占用内存的nosql，已经对常常查询的数据作了缓存，在这之上再加cache，未必真的颇有效，这须要case by case去分析了，总之盲目加cache也并不推荐。

加缓存是为了解决访问速度，减轻数据库压力，可是并不提升推荐精准度。若是咱们要提升推荐效果呢？在2015年以前机器学习还没那么普及成熟的时候，咱们怎么搞呢？

提升推荐效果，在机器学习以前有两种作法：

- 引入基于lucene的搜索引擎，在搜索的同时经过定制方案实现scoring，好比我能够利用lucene对用户的年龄、性别、地址等进行indexing，可是再返回结果时我再根据用户和查询者两人的具体信息进行关联，自定义返回的score（能够视为推荐相关系数）

- 采用离线批处理。当然能够用hadoop，可是就太杀鸡用牛刀了。常见的是定时批处理任务，按某种规则划分用户群体，对每一个群体再作全量计算后把推荐结果写入缓存。这种能够作很繁复准确的计算，虽然慢，但效果每每不错。这种作法也经常使用在手机游戏的PvP对战列表里面。

这些处理方法对社交网络/手游这类型的其实已经足够了，可是新的业务是不断出现的。随着uber/滴滴/饿了么/美团这些须要实时处理数据的app崛起，做为一个司机，并不想你上线后过几分钟才有客人来吧，你但愿你开到一个热点区域，一开机就立刻接单。

因此这种对数据进行实时（近实时）处理的需求也带动了后端体系的大发展，kafka/spark等等流处理大行其道。这时候的后端体系就渐渐引入了消息驱动的模式，所谓消息驱动，就是对新的生产数据会有多个消费者，有的是知足实时计算的需求（好比司机信息须要马上可以被快速检索到，又不能每次都作全量indexing，就须要用到spark），有的只是为了数据分析，写入相似cassandra这些数据库里，还有的多是为了生成定时报表，写入到mysql。

大数据的处理一直是业界热点领域。记得2015年硅谷一个朋友就是从一家小公司作php跳去另外一家物联网公司作spark相关的工做，以前还很担忧玩不转，搞了两年就俨然业界大佬被oracle挖去负责云平台～～～

anyway，这时候对后端体系的要求是一方面能快速知足实时需求，另外一方面又能知足各类耗时长的数据分析、data lake存储等等，以及当时渐渐普及的机器学习模型（当时2015年初和几个朋友搞startup，其中一个是walmart lab的机器学习专家，上来就一堆模型，啥数据和用户都尚未就把模型摆上来了，后来搞得很是头痛。当时没有keras/pytorch/tf这些，那堆模型是真心搞不太懂，可是又不敢扔，要靠那东西去包装拿投资的。。。）

可是咱们再看上面的图，是否是感受比较乱呢？各类系统的数据写来写去，是否是有点messy？当公司团队增多，系统复杂度愈来愈高的时候，咱们该怎么梳理？

到了2017以后，前面千奇百怪的后端体系基本上都趋同了。kafka的实时消息队列，spark的流处理（固然如今也能够换成flink，不过大部分应该仍是spark），而后后端的存储，基于hive的数据分析查询，而后根据业务的模型训练平台。各个公司反正都差很少这一套，在具体细节上根据业务有所差别，或者有些实力强大的公司会把中间一些环节替换成本身的实现，不过无论怎么变幻无穷，总体思路基本都一致了。

这里能够看到机器学习和AI模型的引入。我的认为，machine learning的很大一个好处，是简化业务逻辑，简化后台流程，否则一套业务一套实现，各类数据和业务规则很难用一个总体的技术平台来完成。相比前面一页的后台架构，这一页要清晰许多，并且是一个DAG有向无环图的形式，数据流向很明确。咱们在下面再来讲这个机器学习对业务数据流程的简化。

在传统后端系统中，业务逻辑其实和数据是客观分离的，逻辑规则和数据之间并不存在客观联系，而是人为主观加入，并没造成闭环，如上图左上所示。而基于机器学习的平台，这个闭环就造成了，从业务数据->AI模型->业务逻辑->影响用户行为->新的业务数据这个流程是自给自足的。这在不少推荐系统中表现得很明显，经过用户行为数据训练模型，模型对页面信息流进行调整，从而影响用户行为，而后用新的用户行为数据再次调整模型。而在机器学习以前，这些观察工做是交给运营人员去手工猜想调整。

上图右边谈的是机器学习相关后台架构和传统web后台的一些差异，重点是耗时太长，必须异步处理。所以消息驱动机制对机器学习后台是一个必须的设计。

这页是一些我的的感觉，现代的后端数据处理愈来愈偏向于DAG的形态，Spark不说了，DAG是最大特点；神经网络自己也能够看做是一个DAG（RNN其实也能够看做无数个单向DNN的组合）；tensorflow也是强调其Graph是DAG，另外编程模式上，Reactive编程也很受追捧。

其实DAG的形态重点强调的就是数据自己是immutable（不可修改），只能transform后成为新的数据进入下一环。这个思惟其实能够贯穿到现代后台系统设计的每一个环节，好比trakcing、analytics、数据表设计、microservice等等，但具体实施仍是要case by case了。

不管如何，数据，数据的跟踪tracking，数据的流向，是现代后台系统的核心问题，只有data flow和data pipeline清晰了，整个后台架构才会清楚。

数据库是个很是复杂的领域，在下面对几个基本经常使用的概念作一些介绍。注意一点是graph database在这里没有提到，由于平常使用较少，相对来讲facebook提出的GraphQL却是个有趣的概念，但也只是在传统db上的一个概念封装。

上图是2018年12月初热门数据库的排名，咱们能够看到关系数据库RDBMS和NOSQL数据库基本上势均力敌。而NOSQL中实际上又能够分为key-value storage（包括文档型）及column based DB.

mysql这个没啥好讲，大概提一下就是。有趣的是曾经看到一篇文章是aws CTO谈的一些内容，其中印象深入是：若是你的用户还不到100万，就别折腾了，无脑使用mysql吧）

在2015年以前的一个趋势是很多公司使用mysql做为数据存储，可是把indexing放在外部去作。这个思路最先彷佛是friendster提出的，后来uber也模仿这种作法设计了本身的数据库schemaless。然而随着postgreSQL的普及(postgreSQL支持对json的索引)，这种作法是否还有意义就值得商榷了。

 

nosql最先的使用就是key-value的查找，典型的就是redis。实际上后来的像mongo这些documentbased db也是相似的key value，只是它对document中的内容又作了一次index (inverted index)，用空间换时间来提供查找数据，这也是cs不变的思惟。

mongo/elasticsearch收到热捧主要是由于它们的schemaless属性，也就是不须要提早定义数据格式，只要是json就存，还都能根据每一个field搜索，这很是方便程序员快速出demo。可是实际上数据量大以后仍是要规范数据结构，定义须要indexing的field的。

这里提一个比较好玩的开源project nodebb, 这是个node.js开发的论坛系统。在我前几年看到这个的时候它其实只支持redis，而后当时由于一个项目把它改造了让他支持mysql。去年再看的时候发现它同时支持了redis/postres/mongo，若是对比一下一样的功能他如何在这三种db实现的，相信会颇有帮助。

稍微谈谈列存储。常见mysql你在select的时候其实每每会把整行都读出来，再在其中挑那么一两个你须要的属性，很是浪费。而mongo这些文件型db，又不支持常见SQL。而列存储DB的好处就是快，不用把一行全部信息读出来，只是按列读取你须要的，对如今的大数据分析特别是OLAP(Online Analytical Processing)来讲特别重要。然而据另外的说法，实际上像casssandra/hbase这些并非真正的列存储，而只是借用了一些概念。这个我也没深刻去了解，有兴趣的同窗能够本身研究研究。

列存储的一个重要领域是时序数据库，物联网用得多。其特点是大量写入，只增不改（不修改数据），可是读的次数相对于不多（想一想物联网的特色，随时有数据写入，可是你不会随时都在看你家小米电器的状态。。。）

注意说write/read是正交的。这意思是每次写入是一次一行，而读是按列，加上又不会修改数据，所以各自都能保持极快的速度

下面简单谈一下微服务，大部分直接看PPT就能够了，有几页略微谈一下我的思考。

上面这页说说，其实微服务所谓的服务发现/name service不要被忽悠以为是多神奇的东西。最简单的Nginx/Apache这些都能作（域名转向，proxy），或者你要写个name : address的对应关系到db里面也彻底能够，再配一个定时healthcheck的服务，最简单的服务发现也就好了。

高级点用到zookeeper/etcd等等，或者SpringCloud全家桶，那只是简化配置，原理都同样。从开发角度来看，微服务的开发并非难点，难点是微服务的配置和部署。最近一段时间微服务部署也是业界热点，除了全家桶形态的SpringCloud，也能够看看lstio这些开源工具。

上图主要大体对比一下，看看从早期的Spring到如今Spring Cloud的变化。想来用过Java Tomcat的朋友都能体会Java这一套Config based development的繁琐，开发的精力不少不是在业务代码上，每每会化很多精力去折腾配置文件。固然，Spring Cloud在这方面简化了很多，不过我的仍是不太喜欢java，搞不少复杂的设计模式，封装了又封装。

这里要说并非微服务解决一切，热门的Python Django尽管有restful-framework，可是它其实是一个典型的Monolithic体系。对不少核心业务，其实未必要拆开成微服务。

这二者是互补关系，不是替代关系。

下面的docker我就不仔细谈了，PPT基本表达了我想表述的概念，主要意思是

- docker可以简化部署，简化开发，可以在某种程度上让开发环境和产品环境尽可能接近

- 不要担忧docker的性能，它不是虚拟机，能够看做在server上运行的一个process。

 

 

上图是描述docker以前开发人员的常见开发环境，首先在本身机器上装一大堆服务，像mysql, redis, tomcat啥的。也有直接在远程服务器安装环境后，多人共同登陆远端开发，各自使用一个端口避免冲突…. 实际上这种土法炼钢的形态，在2019年的今天仍然在国内很是普及。

这种形态的后果就是在最后发布到生产环境时，不一样开发人员会经历长时间的“联调”，各类端口、权限、脚本、环境设置在生产环境再来一遍…这也是过去运维人员的主要工做。

上一页提到的问题，并非必定要docker来解决。在这以前，虚拟机VM的出现，以及vagrant这样的工具，都让开发环境的搭建多少轻松了一些。不过思路仍然是把VM做为一个独立服务器使用，只是由于快照、镜像和辅助工具，让环境的配置、统一和迁移更加简单快捷。

上图是对比程序运行在物理服务器、VM及docker时的资源共享状况，能够看到运行在Docker的应用，并无比并发运行在物理服务器上占用更多资源。

下图是简单的docker使用，不作赘述。

这一页主要是强调Docker并不等同于虚拟机。虚拟机所占资源是独享的，好比你启动一个VM，分配2G内存，那么这个VM里无论是否运行程序都会占用2G内存。然而若是你启动一个Docker，里面运行一个简单web服务，在不强制指定内存占用状况下，若是没有请求进入，没有额外占用内存，那么这个docker服务对整机的内存占用几乎为0（固然仍然存在一些开销，但主要是根据该程序自身的运行情况而定）。

最后Kubernetes这里大概说说host-pod-container的关系，一个host能够是物理机或者vm，pod不是一个docker，而是能够看做有一个ip的...（不知道怎么形容），总之一个pod能够包括多个container(docker)，pod之中的container能够共享该pod的资源（ip，storage等）。不过现实中彷佛大可能是一个pod对一个container。

对互联网一些热门概念和演变过程的一个很简略的描述就到这里了，谢谢。

原文： https://cloud.tencent.com/developer/article/1404117