Container的优势有哪些

共计 4721 个字符，预计需要花费 12 分钟才能阅读完成。

本篇内容介绍了“Container 的优势有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

Container 的优势总结为以下四点:

提高计算密度

一个虚机占用的资源比一个 Container 占用的资源不止多十倍。在一个物理机上开一百个虚机是很困难的，但要实现 100 多个，甚至几百个 Container 是很正常的。腾讯在大量使用 Container。某大型互联网公司上次升级发行版，主要就是为了使用 Cgroups，方便限定资源，以 充分利用 CPU。要知道有能力维护自己版本内核的公司，做出这样的决定是非常不容易的，可见其好处是巨大的。

大互联网公司非常适合 Container，Facebook 一台虚机都没有，因为这些互联网公司要求充分利用计算资源。虚机起码还要再跑一个 Guest 系统，太耗资源。

同时，在这些大公司内部并没有很多操作系统，集群只有一种操作系统，甚至连版本号都是固定的。因此，不需要虚机的异构操作系统特性。

另外，在操作系统上还有 Runtime Library，Container 不需要重复加载，极大的节省内存占用。

最后，因为公用的资源更多，Container 相对来讲更容易超售，实际出售量的和超过了物理机的量

更精细的资源控制

这里以目前最为热门的 Linux Container（LXC）为例来说，Linux Container 分为两个部分，Cgroups 用来做资源限制，Namespace 来做资源隔离。最近 Linux 内核对 LXC 相关改进非常多，其中 3.8 版对 Namespace 新增了 user，未来的 3.11 会加入更好的 CRIU 支持，使得 Container 看上去可能更像一个虚拟机。

另外 Container 在数据库隔离方面也有着自身的优势。云化的数据库通常有两种思路：

第一，建立一个大数据库供所有人使用。但如何做资源隔离和安全隔离呢？
SAE 通过增加 SQL 过滤器（CSDN 近期将对 SAE 首席架构师丛磊进行采访，详解 SAE 的资源隔离策略），将不合理的 SQL 全部过滤掉。盛大云的 MongoDB 服务也采用类似的策 略，通过判断执行时间来限定不合理的请求。但这种方法存在弊端，首先不能穷举所有不合理的请求，这是一个典型的停机问题，即便是工程上实用的做法，维护巨 量的规则库也会让管理员痛不欲生，看看杀毒软件要维护多少特征就知道了。其次需要修改数据库代码，而这些修改目前看不会被社区接受，因为社区认为资源隔离 并不是数据库该做的事。

第二，把每个用户的数据库放一个 Container 里，用 Container 来做资源限制。不需要对数据库进行修改。每个 用户的 Container 内有自己的数据库，用户之间的资源是完全隔离开的。不过有观点认为每个 Container 启动一个实例太浪费资源。其实，相同的 Runtime 并不会重复占用资源，而且还能更好的限制资源，操作简单。目前一些 Heroku 的第三方插件是用这种方式进行数据库隔离的。OpenShift 通过 Gear 和 Cartridges 对资源进行隔离，每个应用有自己私有的小数据库。

更短的 provisioning 时间

虚机的 provisioning 时间在分钟级，而 Container 在秒级。设想在淘宝双十一的场景下，虚机需要几分钟时间启动显然太慢了。另外 LXC 目前还有个非常有趣的技术，叫做 systemd，是下一代的启动器，可以极大加快启动速度，并且与 LXC 结合得十分完美，有些高级功能就是依赖 LXC 实现的。

这部分还有另外一个非常重要的技术就是文件系统。提高 provisioning 时间，需要文件系统配合，像 ploop、aufs、overlayfs 等文件系统都有一些非常有趣的技术可以用在 Container 的快照、复制等方面。

Container 式的 PaaS 组装更灵活

用户根据自己的需要组装自己的 PaaS，我认为这是趋势。不同的模块之间有不同的实现，可以替换。比如你认为 Docker 对 LXC 的封装不好，就可以换一个。

Cloud Foundry 也开始重视 LXC，通过 Warden 把 Container 进行封装，但是从技术的角度来讲 Cloud Foundry 的架构过于大，它想把 PaaS 所有事都做了，但每一块做得都不怎么好，耦合度又高。比如我想把 Warden 换成 Docker 就很难。

Cloud Foundry 为代表的 PaaS 平台倾向做得很重，而像 Docker 是轻量的框架代表。我认为轻量的平台更好，更有前途，因为更加灵活。PaaS 到底该长成什么样去年我还觉得比较清楚，但今年反而觉得变数会非常多，所以我更看好灵活的方案。

Docker 项目在 Github 上发布不到两天，就在 Go 语言排行榜上排名第一，说明社区很认可。额外说一句 Go 语言写的 PaaS 工具非常多，有大放异彩的趋势。而 Cloud Foundry 几乎都是仰仗 VMware 财大气粗。大家共同参与，项目才有生命力。Cloud Foundry 的社区贡献度非常差，大部分都是 VMware（Pivotal）自己的工程师贡献。

Container 的趋势和挑战

和虚机相比，LXC 的隔离做个并不彻底，而包括热迁移的等高级功能也正在完善中。程显峰将 LXC 的发展趋势和挑战总结为以下四点：

Container 获得了更广泛的支持

OpenStack 对 LXC 现在有很强的支持。当 OpenStack 支持 Container 了，这会导致该技术在互联网圈子里得到推广。同时，在 OpenStack+LXC 基础上还会有些创新。

另外，ActiveState Software 早就把 Cloud Foundry 和 LXC 绑到一起，推出了商业版。

这一阵子比较火的 CoreOS、dotCloud、PiCloud 等公司都是 LXC 的坚定支持者，systemd 的作者以及 OpenVZ 的开发团队都齐心协力支持 LXC。

VPS 就是 Container 典型的应用场景，基本上全球市场上 90% 的 VPS 平台都使用 OpenVZ。它是一种 Container，但是因为对 Container 的修改过大，不被社区接受。但 OpenVZ 的商业版本比 Linux Container 成熟得多，可以支持热迁移。OpenVZ 的作者为 Linux  Container 提交了百十多个 patch。已经有很多社区的活跃者对 Linux  Container 做贡献。

LXC 在有些方面与虚机有差距

资源限定和隔离做得并不彻底，比如时间就隔离不了。现在 LXC 隔离也就几个方面，进程、挂载资源、用户，大概也就六点，实际上还远远不够。

虚机热迁移技术已经非常成熟，而 LXC 还有差距，也在改进中。据报道，在 Linux kernel 3.11 中会有很大改善。

调试工具逐步完善

云计算调试是个非常头疼的事情，如果应用跑在虚机里，管理员是很难进行管理的。而 Container 对操作系统有一些透明性，如 process 有异常调用，管理员可以看到。

大家为什么不用云计算？大部分人都说部署习惯不一样，调试部署不方便，大家为什么还愿意用虚拟机？虚拟机的调试方式跟他在实体机上调试方式没有任何差异，这种习惯是很难改变的。

Cloud Foundry、SAE、Azure 的调试都解决的不彻底。仅仅通过本地模拟器进行调试，并不能解决根本问题。

调试工具近期也会有一些新的突破，语言级别的像 Ruby2.0 以后加了对 DTrace 支持。我很看好 Dtrace 和 SystemTap 之类的技术的，尤其是在 PaaS 调试上，大家可以关注一下 章亦春、余锋的博客。

PaaS 服务依然不够完善

尽管各种 PaaS 层出不穷，Cloud Foundry、OpenShift、Azure 也在不遗余力的打造更易用的 PaaS 平台，但仍存在各种不足和挑战。无论自建还是使用第三方平台，PaaS 还远未成熟。程显峰认为：

PaaS 平台没有统一的认识

PaaS 到底应该搭成什么样？什么样是成熟的 PaaS？现在都没有统一的认识。微软 Azure、Heroku 以及 Cloud Foundry，各家 PaaS 的边界和内容都不一样。

微软 Azure 有弹性的数据库、Service Bus。亚马逊也有类似的服务。这些服务到底属于 IaaS 还是 PaaS 呢？用户需要的是非常完整的服务，无论对于 IaaS 还是 PaaS 都有大量的工作需要去做。所 以，现在看 PaaS，要想在一个体系下提供服务，我认为是很难的。而 Docker 这种灵活的方案，只做某一块服务，再组装在一起可能是更好的方式。

从上面说的我们也可以看出，现在的云计算模型已经远远不是三层的 IaaS、PaaS、SaaS 那么简单的了。很多组件都能作为一个服务呢，这些组件 应该放在什么位置呢？实际上这个关系非常复杂，各家都有各家的看法，这些看法随着时间改动也还是很大。我的一个观点是从单个技术上突破做成大家都认可的组 件比较容易，总体结构要想达成一致比较难。

国内没有完善的公有云 自建 IaaS 也很麻烦

PaaS 要底层基础资源必须弹性，如果采取自建私有云的方式，很可能需要去搭建 OpenStack，工作量非常大。如果植根于公有云，国内没有美国 那样成熟的亚马逊、Azure 或 Rackspace，阿里云的 API 还不够健全，无法支撑。在国内如果底层资源弹性问题无法解决，PaaS 就是空中楼阁。

标准和互操作也是比较头痛的问题。国内互联网公司相互合作不够，对于标准和规范重视程度也远远不够。有人说云就是水电，但问题是水电是高度同质的，目前还没看到哪些云是同质的。国外还有些公司做跨平台云的管理，国内就更难了，这也是做一个公有 PaaS 的潜在风险。

当然，国内的网络割裂比较严重也是对云计算发展的不利影响。这些都本不该是一个 PaaS 提供商该考虑的问题，但是我们的国情就要求必须要考虑。

需要坚实的服务支持

PaaS 还需要其他服务支撑，比如 Cache、负载均衡、数据库、消息队列、日志，这些服务只有全部包含 PaaS 平台才有价值。当开发者在 PaaS 上运行了应用，如果还要自己搭建这些服务，然后做 HA，这就背离了 PaaS 的设计初衷。因为，实际上应用并不是运维的重点，重点上面提到的那些周边的服务，这些服务的运维成本很高，而且还不体现开发者的核心价值。

京东做得更好。由于 Cloud Foundry 的服务并不是云化的，不提供 HA。京东需要做云化，自己做了上面所说的基础服务。

展望 Cloud Foundry、OpenShift、Azure

Cloud Foundry 今年将推出商业版，Azure 越来越重视开源社区，变的更加开放，OpenShift 继续着云化战略。在采访结束前，程显峰进行了总结：

京东云底层使用了 OpenStack + Cloud Foundry，从长远上看仍然会走互联网式的技术路线。也许再晚一个月做决策，京东就会选择 OpenShift 了，因为从技术角度来讲，OpenShift 比 Cloud Foundry 要好一点。

OpenShift 代码写的还算规矩，而 Cloud Foundry 的代码并不是社区的产物，很多地方都不像大公司的作品。我认为但凡是脱离社区单搞一套，从历史上看绝大多数都没好结果。

从我看的一些报告来看，VMware 在虚拟化技术上的领先优势已经不明显。微软的平台与 VMware 看不出明显的差距。毕竟微软有操作系统和大量商 用软件，这些技术积累是其他公司很难拥有的。同时微软有自己的商用的公有云 Azure，对新技术是很好的试验场，VMware 还没运营自己的公有云。

“Container 的优势有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！