Docker能取代虚拟化吗？
关注嘉为科技，获取运维新知
Docker和容器技术真正在企业比较大规模的使用也是最近几年的事情，包括阿里也是在2015年的时候才开始引入Docker的镜像技术，在此之前，使用的是名为T4的阿里定制容器技术来支撑应用。
消费需求的持续升级，技术的不断进步，使得很多行业和公司都在进行互联网+和业务数字化的转型，服务、敏捷、高效、动态、松耦合、持续迭代等成为企业对于IT的新的要求。随之，在IT领域，自动化、微服务、DevOps等理念被不断推出并付诸实践，由此推动了Docker技术的传播和大规模应用。
事实上，容器技术本身并不是太新鲜的技术，核心技术组件在很多年以前就已经成熟，在此之前没有得到大规模使用的原因：一是使用过于复杂，缺乏类似Docker这样的管理引擎；二是没有找到合适的场景，传统IT运营管理中，容器能干的事情，虚拟化都能干，甚至干的更好，容器的优势在这些场景中得不到发挥。
直到微服务理念被提出，并得到应用，Docker容器才算真正找到了自己的用武之地。
在这篇文章中，我们一起探讨下以下两个问题：
- 容器大致在企业中有哪些典型的使用场景？
- 可见的未来，Docker能替代虚拟化吗？
Docker容器的典型应用场景
Docker容器当然可以作为普通的主机资源使用，但是单单如此，并不能体现Docker的优势。
总结而言，Docker比较典型的、独特应用场景包括以下几个方面：
- Web应用的自动化打包、发布和动态伸缩
- 持续集成、自动化测试、持续部署与交付
- 作为微服务架构使用：部署无状态服务，同虚拟机互补使用，实现隔离性
- 作为微服务架构使用：部署有状态服务，需要十分了解应用
- 适合部署跨云，跨Region，跨数据中心，混合云场景下的应用部署和弹性伸缩
- 以容器作为应用的交付物，保持环境一致性，树立不可变更基础设施的理念
- 用于管理变更，变更频繁的应用使用容器镜像和版本号，轻量级方便的多
事实上，我们能够列出Docker容器的非常多的优势，主要的有：
- 容器启动速度快，秒级启动
- 容器轻量级，每个主机会运行成百上千个容器
- 容器有镜像，可以保持版本号，可以升级和回滚
- 容器可以使用容器平台管理自动重启实现自修复
- 容器可以使用容器平台进行服务发现
- 容器可以基于镜像进行弹性伸缩
但是，上面这些优势都是“表面”的优势，即便是这样的“表面”优势，也很难说虚拟化完全不具备。
容器启动速度快
容器为什么启动快呢，一是没有内核，二是镜像比较小。然而容器是有主进程的，也即Entrypoint，只有主进程完全启动起来了，容器才算真正的启动起来。
对于Java应用，里面安装的是tomcat，而tomcat的启动，加载war，并且真正的应用启动起来，还是需要一些时间的，根本不是秒级。
而且容器之所以启动速度快，往往建议使用一个非常小的镜像，例如alpine，里面很多东西都裁剪掉了，启动的速度就更快了。
现在OpenStack中的VM的启动速度也优化的越来越快了，启动一个VM的时候，原来需要从Glance下载虚拟机镜像，后来有了一个技术，是的Glance和系统盘共享Ceph存储的情况下，虚拟机镜像无需下载，启动速度就快很多。OpenStack的虚拟机镜像也可以经过大量的裁剪，实现快速的启动。
容器轻量级，每个主机支持成百上千的大密度
这种情况并没有具体的应用场景，对于容器来讲，重要的是里面的应用，应用的核心在于稳定性和高并发支撑，而不在于密度。
当前的Java应用基本上4核8G是标配，如果4核8G是标配，不到20个服务就可以占满一台物理服务器。一台主机跑成百上千个应用不是一个严肃的，贴合实际的使用场景。
容器有镜像，有版本号，随时升级和回滚
OpenStack虚拟机也有镜像，镜像也可以打快照的，打快照的时候，也会保存当时的那一刻所有的状态，快照当然也可以有版本号，也可以升级和回滚。
事实上，在这点上，Docker镜像的真正优势在于镜像小、易于跨数据中心、跨区域和跨云迁移。
容器支持重启实现自修复
说起来理论上是这样的，但是存在这样一种场景：就是容器里面的应用没有挂，所以容器看起来还启动着，但是应用已经不工作没有反应了。当启动容器的时候，虽然容器的状态起来了，但是里面的应用还需要一段时间才能提供服务。
所以针对这种场景，容器平台会提供对于容器里面应用的health check，不光看容器在不在，还要看里面的应用能不能用，如果不能，可自动重启。
一旦引入了health check，和虚拟机的差别也不大了，因为有了health check，虚拟机也能看里面的应用是否工作了，不工作也可以重启应用。
容器支持服务发现
容器平台kubernetes，mesos都支持服务发现，当一个服务访问另一个服务，都会有服务名转化为IP，然后访问具体的容器。
然而基于Java写的应用，服务之间的调用多不会用容器平台的服务发现，而是用Dubbo或者spring cloud的服务发现。
因为容器平台层的服务发现，还是做的比较基础，基本是一个域名映射的过程，对于熔断，限流，降级都没有很好的支持，然而既然使用服务发现，还是希望服务发现中间件能够做到这一点，因而服务之间的服务发现之间使用容器平台的少，越是需要高并发的应用，越是如此。
容器支持弹性伸缩
在容器平台上，容器有副本数的，只要将副本数从5改到10，容器就基于镜像进行了弹性伸缩。其实这一点虚拟机也能做到，AWS的Autoscaling就是基于虚拟机镜像的，如果在同一个云里面，就没有区别。
甚至Vmware的VSAN也能做到副本的自动分布式管理。
总结一下，容器化的本质？
Docker能取代虚拟化吗？
答案是：不能。并且双方之间也不是对立的取代与被取代的关系，而更应该是互补合作的关系。
并非所有应用都适合用容器：比如传统的关系型数据库应用，则不是像容器场景中宣称的那样随时都可以随便重启的，而且，数据库的高可用也不是像Kubernetes那样挂一个服务发现就能解决的，而是应当使用数据库本身的高可用架构来实现以确保数据的可靠性和一致性！
容器是有自己十分具体的应用场景的，至少目前来看，在超出上述领域之外的其他传统应用分发、部署、运维管理中，容器并没有特别的优势，反而具备一定的劣势。场景化需求才是两种技术选择的关键。
总结下来，虚拟机和容器技术本身并不对立，也不存在谁取代谁的问题，关键是企业是否合理运用技术在合理的应用场景当中解决相应的技术问题，未来的企业级云平台也应该囊括对这些技术的支持，以满足企业对不同业务所需不同技术栈的灵活选择！
如需转载，请注明出处。
金秋十月，是适合学习的好日子。
2018蓝鲸智云分享会正在报名中，如何打造坚实的自动化运维基础，如何稳步向数据化运维迈进，如何全方位推动研发运营一体化，我们共同探讨。
报名请戳如下链接：
10月23日上海站：https://www.bagevent.com/event/1904525
10月25日北京站：https://www.bagevent.com/event/1908569
10月30日广州站：https://www.bagevent.com/event/1908633
10月31日深圳站：https://www.bagevent.com/event/1908650
