Docker在云环境中的应用实践初探：优势、局限性与效能评测

问题导读
1、Docker云环境的实践测试环境有哪些？
2、Docker在实际应用中的一些问题和局限性
3、你如何看待，Docker的生态系统发展趋势？






概要
本文依据笔者所在团队的一些近期开发和应用的实践，整理出一些有意义的信息，拿出来和社区分享。其中既包括在云端应用Docker与相关技术的讨论，同时也有实施过程中的一些效能评测，以及整个过程中遇到的一些国内特有的问题和我们的一些解决方案，想法。希望可以给方兴未艾的Docker用户群体和社区，提供一些有价值的参考，并引出有意义的讨论。


背景简介
Docker以及一系列与之相关的容器化的技术，经过多年的积累，在过去数月间得到了迅速的市场流行和关注，可谓厚积薄发。一方面是因为容器技术本身的优点，比如更节省测试，部署，弹性扩容和运维的成本及资源，另一方面也是由于业界的重要公司都十分重视并且投入容器虚拟技术，比如Google、RedHat、IBM、Facebook、Amazon以及微软。其中微软开放技术作为微软在开源社区领域的主要参与者，一直以来都积极的跟踪容器基础上的虚拟化技术，并且积极参与到相关的开源项目中，比如今年夏天宣布的由微软开放技术参与的，在微软公有云环境下对Google的Kubernetes和Docker的libswarm的支持。我们已经成功把Kubernetes和libswarm引入到Azure，使得容器技术超越简单部署迈向更加复杂拓扑的云端。

2014年10月15日，Docker公司刚刚在美国与微软共同宣布，双方展开战略合作，在即将发布的Windows Server中，将为发展迅速的Docker分布式应用开放平台的全新容器技术提供支持。利用Docker技术开发容器应用的开发者与企业，将得以在Windows Server或Linux平台上共享快速成长的Docker生态系统，充分利用其中的用户、应用和工具等资源。



Docker在实际应用中的一些问题和局限性

之前有文章讨论过，基于容器的云现在还没有成为主流，主要还是安全性的问题。但是我们在整个实验中也总结出一些在真实环境中遇到的安全性之外的问题。

第一个就是很重要的Docker Hub的访问问题。我们知道国内访问一些海外的网站有时候会有稳定性的问题。Docker Hub在我们的实践中就经常出现访问不了的问题。但这种访问的问题并不是持续的，而是时有时无。由于大量的成熟Docker映像（image）都需要从Docker Hub下载，很多脚本在执行到这一步时，结果很难预料。一种方案是修改缺省的Docker Hub地址，改为采用国内的一些镜像（mirror）。但是在没有官方认证的成熟稳定的镜像网站时，Docker映像的更新不容易得到保证；另一种方案是自行搭建自己的Docker Hub。但是一来这样就失去了强大的社区贡献的映像资源，二来要花费很多精力来保持更新和同步。容器技术带来的简单化，又因为映像管理而复杂化，得不偿失。

第二个就是容器技术的资源管理和运维。因为容器技术本身更适于解决大规模应用场景，所以通常都是集群基础上的部署、运维，但是目前对这一系列任务的自动化处理尚无统一的或者标准的框架。如果要让Docker真正在实际环境中发挥最大的效能并且易于维护，就需要有很成熟稳定的资源编排（orchestration）、资源调度（scheduling）和部署（deployment）的支持，但是这方面暂时还没有很明显的最佳解决方案，所以大多数人都在摸索和搭建自己的解决方案。我们在微软开放技术内部也是在一些开源技术的基础之上，自行开发了容器在微软公有云Azure上的资源管理调度和部署运维的系统，传统上的开发运维和持续集成，持续部署的技术，比如Chef，Puppet，Jenkins等，都可以很容易的与容器技术一起工作。

市场上还有很多的一些比较有希望的相关新技术，比如Twitter的Apache Mesos，Facebook 的Tupperware，Docker自己的libswarm，以及Google的Kubernetes。其中Kubernetes因为在Google经历了数年的实战检验，加上最近微软、RedHat、IBM和Docker等也都宣布支持参与此项目，使得Kubernetes有着很好的前景。

第三个是个对用户有益，但是对公有云运营商带来挑战的问题。因为实际评测中发现，同样的应用和负载，相比原有的虚拟化场景，容器化部署的资源花费通常只有10%甚至1%。意味着某些场景下的应用如果迁移至容器环境，用户会大量节约成本，从而促进用户向云环境迁移的意愿，但同时也给云服务商带来新的挑战。

基于特定场景的Docker效能评测与分析

微软开放技术一直以来积极参与容器技术，不但在微软的公有云平台实现了对Docker的支持，而且我们内部的很多项目也开始积极采用或者迁移到Docker环境中。其中有一个项目，早期是利用原有的虚拟化技术，在云平台上通过部署与启动大量虚拟机，来达到对多用户同时在线提供弹性的云服务。由于项目的设计和要求，需要做到用户的环境隔离，所以基本上一个用户需要有一个对应的虚拟机。当服务需求达到高峰时，需要部署和启动大量的Linux虚拟机。这带来了显著的资源开销，并且在云环境下最终转换为等价的成本开销。由于虚拟机的启动是由需求动态驱动的，对终端用户来说启动时间也造成了用户体验的下降。

针对这一问题，我们在第一时间就开始尝试Docker基础上的容器技术。但是针对我们的特定应用场景，需要评估一下效能，以及功能上是否达到甚至好于原有虚拟机架构基础上一样的要求。功能和效能的测试思路描述如下：

功能测试。我们采取将原有的多个虚拟机的集群部署，改为在少量的虚拟机上的Docker容器集群，即原来的一个虚拟机上的所有的代码和库，都转制生成完全对应的Docker容器，基本上一对一。例如原来是8个不同角色和任务的虚拟机节点组成的集群，转化为8个不同角色和任务的Docker容器。端口映射到宿主虚拟机的不同端口，进而通过云服务面向互联网公共端口。整个容器基础上的集群启动运行后，经测试，功能上和原有的虚拟机集群没有任何区别。

效能测试。我们并不做性能测试（benchmark），因为我们相对于极值，更关心在模拟实际应用部署场景时的次序，资源的利用效率和容量。因为实际场景中，每一个新的节点的生成需求并不是同步和同时的，所以我们的模拟生成频率是每隔数秒启动一个预制的容器，每个容器映像预装了一个最简单的python脚本，启动运行后，持续的循环做很简单的基本运算，使得单个容器的CPU平均使用量大致与我们实际应用时实测的真实应用的CPU使用量相当，在0.1%-0.9%之间。

测试环境：
宿主的虚拟机配置：1 core， 2GB RAM， 20GB HD， 入门级的低端配置。

Docker映像尺寸：500MB， Ubuntu 14.04，with ssh, ruby, python and a simple application

对应的虚拟机映像尺寸：5GB （对应Docker和VM尺寸大概有一个数量级差别）

当Docker映像下载到本地后，启动一个容器耗时不到1秒，和云端虚拟机的启动动辄1-2分钟甚至更久基本上不在一个数量级。

容器启动后，无延迟，立即可以使用。

首先监测随启动的容器总量增加，可用内存的递减规律。结果如下图（y轴单位kB，x轴容器实例数），在200个容器以内，内存耗费基本呈线性。并且Docker并未将映像的所有内容都加载到内存。




再监测单个容器平均占总内存百分比随容器增加的变化。如下图（y轴单位%，x轴容器实例数），前20个容器平均内存开销虽然较小，但是波动较大，之后是相对均匀区域，有小量增长，但是波动被平均化了。当继续增加到约150时，平均花费和波动都开始增加，显示额外开销（overhead）加大，波动也增大到无法被平均值平滑了。具体的研究也与此一致，从150个容器开始，开始出现不可用，无反应或者无法杀掉的僵尸容器（Zombie）。升至200时我们平均录得6个僵尸容器。所以在我们这个特定的配置，场景和环境下，可以认为150是个资源分配上的有效极值。




在从零到200个容器实例的部署启动过程中我们监控了此一过程中的CPU使用情况。由于我们的容器尚未附加大量工作负载，所以这个数据反应的的是基准CPU开销（baseline）。结果如下图，由宿主环境录得的数据显示（y轴单位%，x轴为容器实例数），在单一宿主环境下启动容器的CPU开销很小，200个容器时也基本在5-6%以下。而且在此区间内随部署容器的增加，CPU花费基本呈线性。




由于时间所限，我们暂时还没有对网络带宽花费做测试，这将在后续的工作中逐步完成。但是基于经验估算，假设一台宿主机的带宽为1000M bps，当被大量共享时实际可用带宽不到70%，再折算为Bps，并考虑HTTP的额外开销之后，实际可用带宽约60MBps，分到200个同样的容器，每个容器的现实带宽大概只有300K Bps。这对一般的网站或网络应用是基本够用，但是高峰和一些消耗带宽的应用就需要认真测算。

结果讨论
综上所述，在云计算环境用户主要关注的资源——CPU、内存、存储、网络带宽四大要素中，在一定范围内，增加同质容器实例的数目时，资源的耗费基本为线性。所以如果要做优化的资源调配，需要进行单个应用的平均和峰值评测，结合负载的模式（pattern），来计算最有可能先达到瓶颈的资源，并以此为上限优化资源调配算法。由于异源容器应用实例的不确定性，最有效的部署方式是同源的容器应用实例，尽量部署到同样的宿主环境，因为这样可以相对精确的取得单个容器实例的平均资源花费，从而作为经验参数代入资源配置的算法里，得到优化的结果。

此外在架构层面，由于对资源使用效率要做精细化分配，不同角色的模块，扩展曲线会有很大不同，所以建议松散耦合，按角色、堆栈层分离模块，分别做标准的分布式部署，以达到最大效能。比如标准MVC网站架构，可以将所有模块打包到一个容器映像，部署和扩容时会很简单。但是如果要最大化资源利用效率，应当数据层，应用层和网络服务器层分开建立容器映像，分开部署，独立扩容。当然这就需要更有效的工具和框架的帮助来实现。


总结
我们在微软公有云环境下的对Docker现实场景的应用实践，使我们得到了从用户角度出发，在类似场景下应用时可能遇到的问题及第一手资料。经过对某些特定场景下的资源利用效率评测，也更好的了解了以Docker为代表的容器化技术的适应对象和需要关注的问题。微软开放技术会一如既往的持续加大对容器技术的研发和投入。并希望和国内的开源社区一起推动容器技术的应用，使这项可以为用户节省大量资源的技术能在更多的产品环境中和应用场景中真真正正得到广泛而持久的应用。

进深阅读
携手 Google 和 Docker 为 Microsoft Azure 带来全新的开源容器技术

Docker与微软展开战略合作，实现基于Container的跨平台应用开发

Create a Docker Host on Microsoft Azure

Understanding Docker Containers on Microsoft Azure with Kubernetes Visualizer

Getting Started with Docker on Microsoft Azure



作者介绍
商之狄，现任微软开放技术（中国）首席项目经理，从事开源技术、云计算和大数据相关的新技术研发与推广工作。商之狄曾在美国硅谷的start-up、互联网及电子商务领域工作多年：曾参与过用超级计算机进行最早的人类基因组全注释；用机器学习、并行计算和计算机视觉技术帮助全球最大的制药公司从数百万潜在药物中快速筛选抗癌新药；参与开发过语义基础上的垂直搜索引擎；在全球最大的支付企业技术研发部进行超高通量交易和欺诈检测业务向大规模云环境迁移的试验。在全球最大零售企业的电子商务部门任资深架构师时，领导开发了大数据基础上的全自动精准在线推广营销系统。