容器微服务的前世今生
在文章“云计算的前世今生”中提到: 云计算解决了基础资源层的弹性伸缩，却没有解决PaaS层应用随基础资源层弹性伸缩而带来的批量、快速部署问题。于是容器应运而生。
容器是Container，Container另一个意思是集装箱，其实容器的思想就是要变成软件交付的集装箱。集装箱的特点，一是打包，二是标准。
没有集装箱的时代，假设将货物从A运到B，中间要经过三个码头、换三次船。每次都要将货物卸下船来，摆的七零八落，然后搬上船重新整齐摆好。因此在没有集装箱的时候，每次换船，船员们都要在岸上待几天才能走。
有了集装箱以后，所有的货物都打包在一起了，并且集装箱的尺寸全部一致，所以每次换船的时候，一个箱子整体搬过去就行了，小时级别就能完成，船员再也不能上岸长时间耽搁了。
这是集装箱“打包”、“标准”两大特点在生活中的应用。下面用一个简单的案例来看看容器在开发部署中的实际应用。
假设有一个简单的Java网站需要上线，代码的运行环境如下：
那么容器如何对应用打包呢？还是要学习集装箱，首先要有个封闭的环境，将货物封装起来，让货物之间互不干扰，互相隔离，这样装货卸货才方便。好在Ubuntu中的LXC技术早就能做到这一点。
封闭的环境主要使用了两种技术，一种是看起来是隔离的技术，称为NameSpace，也即每个NameSpace中的应用看到的是不同的IP地址、用户空间、程号等。另一种是用起来是隔离的技术，称为Cgroup，也即明明整台机器有很多的CPU、内存，而一个应用只能用其中的一部分。
有了这两项技术，集装箱的铁盒子我们是焊好了，接下来是决定往里面放什么。
最简单粗暴的方法，就是将上面列表中所有的都放到集装箱里面。但是这样太大了！因为即使你安装一个干干静静的ubuntu操作系统，什么都不装，就很大了。把操作系统装进容器相当于把船也放到了集装箱里面！传统的虚拟机镜像就是这样的，动辄几十G。答案当然是NO！所以第一项操作系统不能装进容器。
撇下第一项操作系统，剩下的所有的加起来，也就几百M，就轻便多了。因此一台服务器上的容器是共享操作系统内核的，容器在不同机器之间的迁移不带内核，这也是很多人声称容器是轻量级的虚拟机的原因。轻不白轻，自然隔离性就差了，一个容器让操作系统崩溃了，其他容器也就跟着崩溃了，这相当于一个集装箱把船压漏水了，所有的集装箱一起沉。
另一个需要撇下的就是随着应用的运行而产生并保存在本地的数据。这些数据多以文件的形式存在，例如数据库文件、文本文件。这些文件会随着应用的运行，越来越大，如果这些数据也放在容器里面，会让容器变得很大，影响容器在不同环境的迁移。而且这些数据在开发、测试、线上环境之间的迁移是没有意义的，生产环境不可能用测试环境的文件，所以往往这些数据也是保存在容器外面的存储设备上。也是为什么人们称容器是无状态的。
至此集装箱焊好了，货物也装进去了，接下来就是如何将这个集装箱标准化，从而在哪艘船上都能运输。这里的标准一个是镜像，一个是容器的运行环境。
总而言之，容器是轻量级的、隔离差的、适用于无状态的，可以基于镜像标准实现跨主机、跨环境的随意迁移。
有了容器，使得PaaS层对于用户自身应用的自动部署变得快速而优雅。容器快，快在了两方面，第一是虚拟机启动的时候要先启动操作系统，容器不用启动操作系统，因为是共享内核的。第二是虚拟机启动后使用脚本安装应用，容器不用安装应用，因为已经打包在镜像里面了。所以最终虚拟机的启动是分钟级别，而容器的启动是秒级。容器咋这么神奇。其实一点都不神奇，第一是偷懒少干活了，第二是提前把活干好了。
因为容器的启动快，人们往往不会创建一个个小的虚拟机来部署应用，因为这样太费时间了，而是创建一个大的虚拟机，然后在大的虚拟机里面再划分容器，而不同的用户不共享大的虚拟机，可以实现操作系统内核的隔离。这又是一次合久必分的过程。由IaaS层的虚拟机池，划分为更细粒度的容器池。
容器管理平台
有了容器的管理平台，又是一次分久必合的过程。
容器的粒度更加细，管理起来更难管，甚至是手动操作难以应对的。假设你有100台物理机，其实规模不是太大，用Excel人工管理是没问题的，但是一台上面开10台虚拟机，虚拟机的个数就是1000台，人工管理已经很困难了，但是一台虚拟机里面开10个容器，就是10000个容器，你是不是已经彻底放弃人工运维的想法了。
所以容器层面的管理平台是一个新的挑战，关键字就是自动化：
自发现：容器与容器之间的相互配置还能像虚拟机一样，记住IP地址，然后互相配置吗？这么多容器，你怎么记得住一旦一台虚拟机挂了重启，IP改变，应该改哪些配置，列表长度至少万行级别的啊。所以容器之间的配置通过名称来的，无论容器跑到哪台机器上，名称不变，就能访问到。
自修复：容器挂了，或是进程宕机了，能像虚拟机那样，登陆上去查看一下进程状态，如果不正常重启一下么？你要登陆万台docker了。所以容器的进程挂了，容器就自动挂掉了，然后自动重启。
弹性自伸缩 Auto Scaling：当容器的性能不足的时候，需要手动伸缩，手动部署么？当然也要自动来。
当前火热的容器管理平台有三大流派：
一个是Kubernetes，我们称为段誉型。段誉(Kubernetes)的父亲(Borg)武功高强，出身皇族(Google)，管理过偌大的一个大理国(Borg是Google数据中心的容器管理平台)。
一个是Mesos，我们称为乔峰型。乔峰(Mesos)的主要功夫降龙十八掌(Mesos的调度功能)独步武林，为其他帮派所无。而且乔峰也管理过人数众多的丐帮(Mesos管理过Tweeter的容器集群)。后来乔峰从丐帮出来，在江湖中特例独行(Mesos的创始人成立了公司Mesosphere)。
一个是Swarm，我们称为慕容型。慕容家族(Swarm是Docker家族的集群管理软件)的个人功夫是非常棒的(Docker可以说称为容器的事实标准)，但是看到段誉和乔峰能够管理的组织规模越来越大，有一统江湖的趋势，着实眼红了，于是开始想创建自己的慕容鲜卑帝国(推出Swarm容器集群管理软件)。
三大容器门派，到底鹿死谁手，谁能一统江湖，尚未可知。
网易云之所以选型Kubernetes作为自己的容器管理平台，是因为基于 Borg成熟的经验打造的Kubernetes，为容器编排管理提供了完整的开源方案，并且社区活跃，生态完善，积累了大量分布式、服务化系统架构的最佳实践。
容器初体验
想不想尝试一下最先进的容器管理平台呢？我们先了解一下Docker的生命周期。如图所示。
图中最中间就是最核心的两个部分，一个是镜像Images，一个是容器Containers。镜像运行起来就是容器。容器运行的过程中，基于原始镜像做了改变，比如安装了程序，添加了文件，也可以提交回去(commit)成为镜像。
如果大家安装过系统，镜像有点像GHOST镜像，从GHOST镜像安装一个系统，运行起来，就相当于容器；容器里面自带应用，就像GHOST镜像安装的系统里面不是裸的操作系统，里面可能安装了微信，QQ，视频播放软件等。安装好的系统使用的过程中又安装了其他的软件，或者下载了文件，还可以将这个系统重新GHOST成一个镜像，当其他人通过这个镜像再安装系统的时候，则其他的软件也就自带了。
普通的GHOST镜像就是一个文件，但是管理不方便，比如如果有十个GHOST镜像的话，你可能已经记不清楚哪个镜像里面安装了哪个版本的软件了。所以容器镜像有tag的概念，就是一个标签，比如Dev-1.0，Dev-1.1，Production-1.1等，凡是能够帮助你区分不同镜像的，都可以。
为了镜像的统一管理，有一个镜像库的东西，可以通过push将本地的镜像放到统一的镜像库中保存，可以通过pull将镜像库中的镜像拉到本地来。
从镜像运行一个容器可使用下面的命令，如果初步使用Docker，记下下面这一个命令就可以了。
docker stop可以停止这个容器，start可以再启动这个容器，restart可以重启这个容器。在容器内部做了改变，例如安装了新的软件，产生了新的文件，则调用docker commit变成新的镜像。
镜像生产过程，除了可以通过启动一个docker，手动修改，然后调用docker commit形成新镜像之外，还可以通过书写Dockerfile，通过docker build来编译这个Dockerfile来形成新镜像。为什么要这样做呢？前面的方式太不自动化了，需要手工干预，而且还经常会忘了手工都做了什么。用Dockerfile可以很好的解决这个问题。Dockerfile的一个简单的例子如下：
这其实是一个镜像的生产说明书，Docker build的过程就是根据这个生产说明书来生产镜像：
FROM基础镜像，先下载这个基础镜像，然后从这个镜像启动一个容器，并且登陆到容器里面；
RUN运行一个命令，在容器里面运行这个命令；
COPY/ADD将一些文件添加到容器里面；
最终给容器设置启动命令 ENTRYPOINT，这个命令不在镜像生成过程中执行，而是在容器运行的时候作为主程序执行；
将所有的修改commit成镜像。
这里需要说明一下的就是主程序，是Docker里面一个重要的概念，虽然镜像里面可以安装很多的程序，但是必须有一个主程序，主程序和容器的生命周期完全一致，主程序在则容器在，主程序亡则容器亡。
就像图中展示的一样，容器是一个资源限制的框，但是这个框没有底，全靠主进程撑着，主进程挂了，衣服架子倒了，衣服也就垮了。
了解了如何运行一个独立的容器，接下来介绍如何使用容器管理平台。
容器管理平台初体验
容器管理平台会对容器做更高的抽象，容器不再是单打独斗，而且组成集团军共同战斗。
多个容器组成一个Pod，这几个容器亲如兄弟，干的也是相关性很强的活，能够通过localhost访问彼此，真是兄弟齐心，力可断金。有的任务一帮兄弟还刚不住，就需要多个Pod合力完成，这个由Replication Controller进行控制，可以将一个Pod复制N个副本，同时承载任务，众人拾柴火焰高。
N个Pod如果对外散兵作战，一是无法合力，二是给人很乱的感觉，因而需要有一个老大，作为代言人，将大家团结起来，一致对外，这就是Service。老大对外提供统一的虚拟IP和端口，并将这个IP和服务名关联起来，访问服务名，则自动映射为虚拟IP。老大的意思就是，如果外面要访问我这个团队，喊一声名字就可以，例如”雷锋班，帮敬老院打扫卫生！”，你不用管雷锋班的那个人去打扫卫生，每个人打扫哪一部分，班长会统一分配。
最上层通过NameSpace分隔完全隔离的环境，例如生产环境，测试环境，开发环境等。就像军队分华北野战军，东北野战军一样。野战军立正，出发，部署一个Tomcat的Java应用。
作者简介：刘超，网易云解决方案首席架构师。10年云计算领域研发及架构经验，Open DC/OS贡献者。长期专注于kubernetes, OpenStack、Hadoop、Docker、Lucene、Mesos等开源软件的企业级应用及产品化。
原文标题：云计算前世今生(下)
编者总结：
编者注意到更多文章把容器和虚拟机进行比较，他们之间存在很大区别和联系，下面进行简单总结。
容器和虚拟机都是虚拟化技术，用来解决资源隔离、提高系统资源利用率的一种技术，容器比较轻量(容器空间在MB级别、VM是GB级别)，部署密度高，性能损耗小。基于容器镜像分层技术可以实现通用依赖库和系统特定库分离，实现应用、配置文件和特定库依赖打包，可以做到了一处编译、到处运行。
容器运行效率基本接近于物理机，容器操作(启动，停止，重启等)毫秒到秒级，容器的灵活性极大促进混合云场景负载迁移。最重要的一点是，容器共享宿主机资源，所以可以最到弹性收缩，不像虚拟机，分配的物理硬件资源固化，不能灵活调整给其他资源使用。
但是容器也存在不足，如无热迁移，网络隔离性、安全性支持比较薄弱，Docker发布libnetwork增强网络特性，很多项目也在致力改善容器网络。容器应用只能针对应用和特定库进行修改，不能有kernel及通用库改动，因为任何改动都会影响到其他容器运行。
容器随着用户进程的停止而销毁，容器数据和日志数据无法更好管理和收集，运维能力较弱。业务相关高可用、可恢复性、容灾等需求，暂时还无法满足企业应用要求。
容器还有个重要约束，Linux容器在Linux主机上运行不同跨系统。也可以在Windows Server上运行Windows容器，采用Windows版的Docker容器管理器进行管理。如果要在Windows上运行Linux容器，可以在Windows下启动Linux虚拟机，使用Linux虚拟机作为容器宿主系统，或采用Boot2Docker完成安装。
容器主要通过依赖Linux系统的NameSpace、Cgroups和文件系统、镜像分层机制技术，实现容器资源隔离、空间隔离和跨平台打包部署。
NameSpace(命名空间)是Linux内核针对实现容器虚拟化而引入的特性。每个容器都可以拥有自己单独的命名空间，运行在其中的应用都像是在独立的操作系统中运行一样，保证了容器之间彼此互不影响。在操作系统中，所有包括内核、文件系统、网络、PID、UID、IPC、内存、硬盘、CPU等资源都是应用进程直接共享的。不但要实现对内存、CPU、网络IO、硬盘IO、存储空间等的限制，还要实现文件系统、网络、PID、UID、IPC等的相互隔离。前者相对容易实现，后者则需要宿主主机系统的深入支持。
随着Linux系统对于命名空间功能的逐步完善，虽然，在容器间都共用一个Linx系统内核和某些运行时环境(系统命令和系统基础库)，但是他们彼此是不可见的。
Cgroups(Control Groups)是linux内核提供的一种可以跟踪、限制、隔离进程组所使用的物理资源的机制。仅从资源管理上看，Linux Container是在Cgroups的基础上做了一层封装，Docker在LXC的基础上又做了一层封装。
Cgroups提供了给容器分配资源的控制机制，避免多个容器同时运行时的系统资源竞争。控制组可以提供对容器的内存、CPU、磁盘IO等资源进行限制和计费管理。控制组的设计目标是为不同的应用提供统一的接口，实现对单一进程到系统级虚拟化(包括OpenVZ、Linux VServer、LXC等)的控制。
温馨提示：
请识别二维码关注公众号，点击原文链接获取更多技微服务和容器术资料总结。