为什么要Docker,为什么要虚拟化,为什么要容器?


最近在整理虚拟化,容器,Docker,K8S的相关技术。但是面临一个挥之不去的疑惑(其实很早前就有,一直未解):为什么要虚拟化,为什么要容器,为什么要Docker?(K8S另当别论)
网上的各种说法,虚拟化和容器化最核心的目的是为了分割物理机从而提高物理机的使用效率(以及其他目的,但是其他目的都是因为分割物理机导致)。Docker除了容器的价值,还能优化打包部署自动扩容等。
  但是细细想来,这些观点站得住脚吗?有没有其他更简单的办法来达到同样的目的呢?
  1、提高物理机的使用效率。
  提高物理机的使用效率就非得虚拟化或容器化吗?有没有其他更好的方式?虚拟化和容器化是有代价的:1)性能损耗,虚机损耗15%左右,容器也损耗5%左右(这已经很保守了)。2)虚拟机和容器技术的学习,研究,使用的门槛和成本可不小。3)虚机和容器化技术也导致了其他的新问题。
  2、打包发布,自动扩容。
  这个应该没有太大的技术难度,有多种实现方式。

  对开发来说,具体的需求设计开发等,虚拟化容器化Docker这些帮不上忙。虚拟化容器化Docker总的来说是优化部署和运维管理这个环节,能很好的实现Devops。
  但是我感觉有一种更简单有效的方案(更原始)实现Devops,大家看看怎么样。
  假设(先针对公司内部使用,先不说使用云Iaas):
1)不用虚机和容器,直接使用物理机。机房提供多种资源特点(CPU好,或者内存大,或者网卡牛逼,或者SSD等)的机器,提供十几种规格组合。评估实际需要,再考虑多准备一点。我想这是个简单的事情,一般的公司都是这样。如果说机房所有机器不够用了,虚拟化容器化Docker也无法解决,对吧。
  2)开发一个管理系统,主要实现2个功能:监控物理机的资源情况,以及自动扩容(缩容)。监控物理机的资源这个没有大的技术难度,很多年前就有Nagio, zabbix等。自动扩容也简单:自动申请空的物理机,拷贝应用程序执行包到目标机器的目标路径,解压,执行start.sh启动程序(物理机操作系统,账户,JVM,Tomcat等公司一般都是同一个标准,可以预先在物理机上安装好)。我们公司现在的上线更新是半自动,在管理平台页面上点几个按钮:后台自动备份,拷贝,解压,停止,启动,全程无需登录到服务器。
3)每个程序根据自身特点选择不同规格的物理机。一个程序的一个实例独占一个物理机。
  4)如果检测到某个应用程序所有实例所在的机器资源都紧张了(比方说以CPU使用率85%为参照),管理系统自动为这个程序申请适当数量的空的物理机,然后自动部署程序,自动启动。
  5)如果检测到某个应用程序的多个实例所在的机器资源存在空闲,就自动下线适当数量的实例,再回收机器(清除部署过的程序,再登记到管理平台,供后续被申请)。

  大家看看我说的这个方案有没有问题。
  我个人的理解是:
  1)这个比使用虚拟化,Docker, K8S要简单很多。开发这么一个管理系统2~3个人3~5个月就可以了。而且同样可以标准化,适用任何公司。
  2)应用程序的一个实例独占一个物理机,并充分利用机器资源,这个也没有什么难度:能独占一个1~2核的虚机(或者容器)并充分利用,就同样能独占一个2*8核的物理机并充分利用。背后就是线程和内存使用方式的问题,启动时检测核数和内存,再确定相关参数,只要有并发压力,就把CPU,内存,网络打满。
  3)以物理机为扩容的最小粒度是否会导致浪费。分析一下:线上某个应用,至少部署2个实例,检测到机器资源稍有紧张,新加一台物理机,但现在3个物理机总体又比较空闲,这会导致20~30%左右的浪费。但是实际中:可以采用一定的策略,考虑同一个系统的不同应用混合部署到同一个物理机以提高机器利用率。同时一个应用的实例越多浪费就越少,已经用10台机器了,再加1台,不会导致多少浪费。另外,如果说为了单点问题每个应用至少部署2个实例,但是基本没什么并发机器基本空跑,这种情况现实中应该很少:大点的公司基本不会存在这样的问题,小的公司浪费几台机器也没什么(比起使用虚机,Docker,K8S的开销小得多,1个人1年的开销可以买几台服务器了)。
  4)另外,就算是云Iaas,也未必非要虚拟化和容器。虚拟化和容器无非就是把资源的分配粒度弄小点。一个普通服务器粒度不算大。小的应用,Iaas上租2~3个这样的服务器,混合部署就好了(虽说有些不好的方面,但是完全可行)。

  这样来看,明显是有更加简单有效的方案。为什么要费那么大的精力去做虚拟化(硬件厂商在不断的努力提高硬件性能,我们反过来嫌硬件太好,分割成几个虚机或容器),容器,Docker,K8S呢?为什么那些大厂都跟进这些技术。

  本人也混互联网多年,对互联网中的很多技术还是很认可,比方说,分布式MySQL中间件很好的处理分库分表,这比业务代码自己来实现分库分表明显要好很多;Dubbo实现服务治理,这个好处也是非常明显;分布式调用链跟踪系统也是有非常明显的好处。等等。
  虽说还不是很懂Docker的实际使用,但是从概念上来说,实在不明白虚拟化,容器,Docker到底能为我们带来什么明显的好处(已经有很简单有效的方法了)。要知道,这几个技术要学会用好,门槛不低代价不小,小公司更是很难入手(京东商城的JDOS2.0就是基于虚拟化和Docker,据说是国内做的最好的。问题是背后是一个大团队2年的投入,对Docker做了不少深度定制)。
 
  懂得一个技术背后的内涵,才能更好的掌握和使用这个技术。如果只是为了技术而技术,估计很难有好的技术方向感。
  昨天在知乎上发了帖子,没有得到有效的答复。
  希望在这里能得到一些具体的,明确的讨论和交流。
已邀请:

ScofieldDM

赞同来自:


个人觉得移植性也是容器的一个优势吧,开发的系统如果只在当前的机房进行上进行部署发布,那当然问题没有太多,如果到其他机房不同机房进行部署。会是一个比较麻烦的事情,由于环境的不同,操作系统版本不一致导致的问题也会很多。

FrankCba

赞同来自:


比较失望。Docker的论坛,看不到对Docker本质性问题的讨论和答复。

需要特别说一下的是,
google很早之前就开始使用容器技术,但是大家不要疏忽了,同是互联网公司,应用的类型可能是有很大的不同的。Google的应用和国内阿里和腾讯的应用是有很大不同的。google适用容器技术,不等于国内所有互联网公司适用容器技术。比方说google的分布式文件系统是处理单个G级的大文件(文件不怎么被下载,主要用于离线算法分析),但是国内很多互联网公司的分布式文件系统都是保存K级的小文件,主要供下载。这就要求其背后的架构思路不同,否则就行不通。
所以就需要首先弄明白这些技术背后的内涵和根本出发点。

昨天和一个做Docker和k8s的老同事讨论这个问题,他的观点是,单个物理机分配给单个应用太浪费了——核数超过4个就很难提升应用程序的性能。
这个说法有一定的道理——应用程序对资源的倾向不同。但是也不是100%可靠。即便是这样,也有很好的应对方式:同一个应用程序在同一个物理机上部署多个实例,尽量把机器跑满。这还是比折腾虚拟化,Docker, K8S简单很多。

所以说,这么根本性的一个问题,至少目前来看,大家都是各执己见,没有一个明确的答案,这自身就是很大很大的问题。不懂的人一味的冲进来,懂点人发发帖子“指点江山”。

如果这个东西的价值所在没有弄清楚,如果这个东西的适用场景没有弄清楚——基本就是瞎折腾。

云龙云 - Agile, DevOps

赞同来自:


其实Docker以前的官网的口号的说的挺清楚“Build once,Run anywhere,Configure once,Run anything”。它并不改变软件的任何开发方式,但是改变了软件的构建,测试,部署,运维的方式。

所以单纯从研发上讲,没有任何改变。 但是从软件交付端到端的过程上能大大提高研发效率。

要回复问题请先登录注册