加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 云计算 > 正文

有关容器的六大误区和八大正确场景

发布时间:2018-08-15 08:47:06 所属栏目:云计算 来源:云技术实践
导读:做容器的研究和容器化几年了,从最初对于容器的初步认识,到积攒了大量的容器迁移经验,并和客户解释了容器技术之后,发现原来对于容器的理解有大量的误解,而且容器并非虚拟机的替代,而是有十分具体的应用场景的。 第一部分:容器的理解误区 误区一:容

spark的这种做法思想类似无服务架构,你会发现我们原来学操作系统的时候,说进程粒度太大,每次都创建和销毁进程会速度太慢,为了高并发,后来有了线程,线程的创建和销毁轻量级的多,当然还是觉得慢,于是有了线程池,事先创建在了那里,用的时候不用现创建,不用的时候交回去就行,后来还是觉得慢,因为线程的创建也需要在内核中完成,所以后来有了协程,全部在用户态进行线程切换,例如AKKA,Go都使用了协程,你会发现趋势是为了高并发,粒度是越来越细的,现在很多情况又需要进程级别的,有种风水轮流转的感觉。

误区三:容器有镜像,可以保持版本号,可以升级和回滚

容器有两个特性,一个是封装,一个是标准。有了容器镜像,就可以将应用的各种配置,文件路径,权限封装起来,然后像孙悟空说“定”,就定在了封装好的那一刻。镜像是标准的,无论在哪个容器运行环境,将同样的镜像运行起来,都能还原当时的那一刻。

容器的镜像还有版本号,我们可以根据容器的版本号进行升级,一旦升级有错,可以根据版本号进行回滚,回滚完毕则能够保证容器内部还是原来的状态。

 

但是OpenStack虚拟机也是有镜像的,虚拟机镜像也是可以打snapshot的,打snapshot的时候,也会保存当时的那一刻所有的状态,而且snapshot也可以有版本号,也可以升级和回滚。

微信图片_20180807173202

似乎容器有的这些特性OpenStack虚拟机都有,二者有什么不同呢?

虚拟机镜像大,而容器镜像小。虚拟机镜像动不动就几十个G甚至上百G,而容器镜像多几百M。

虚拟机镜像不适合跨环境迁移。例如开发环境在本地,测试环境在一个OpenStack上,开发环境在另一个OpenStack上,虚拟机的镜像的迁移非常困难,需要拷贝非常大的文件。而容器就好的多,因为镜像小,可以很快的从不同的环境之间迁移。

虚拟机镜像不适合跨云迁移。当前没有一个公有云平台支持虚拟机镜像的下载和上传(安全的原因,盗版的原因),因而一个镜像在不同的云之间,或者同一个云不同的region直接,无法进行迁移,只能重新做一个镜像,这样环境的一致性就得不到保障。而容器的镜像中心是独立于云之外的,只要能够连上镜像中心,到哪个云上都可以下载,并且因为镜像小,下载速度快,并且镜像是分层的,每次只需要下载差异的部分。

OpenStack对于镜像方面的优化,基本上还是在一个云里面起作用,一旦跨多个环境,镜像方便的多。

误区四:容器可以使用容器平台管理自动重启实现自修复

容器的自修复功能是经常被吹嘘的。因为容器是衣服,人躺下了,衣服也躺下了,容器平台能够马上发现人躺下了,于是可以迅速将人重新唤醒工作。而虚拟机是房子,人躺下了,房子还站着,因而虚拟机管理平台不知道里面的人能不能工作,所以容器挂了会被自动重启,而虚拟机里面的应用挂了,只要虚拟机不挂,很可能没人知道。

这些说法都没错,但是人们慢慢发现了另外的场景,就是容器里面的应用没有挂,所以容器看起来还启动着,但是应用以及不工作没有反应了。当启动容器的时候,虽然容器的状态起来了,但是里面的应用还需要一段时间才能提供服务。所以针对这种场景,容器平台会提供对于容器里面应用的health check,不光看容器在不在,还要看里面的应用能不能用,如果不能,可自动重启。

一旦引入了health check,和虚拟机的差别也不大了,因为有了health check,虚拟机也能看里面的应用是否工作了,不工作也可以重启应用。

还要就是容器的启动速度快,秒级启动,如果能够自动重启修复,那就是秒级修复,所以应用更加高可用。

这个观点当然不正确,应用的高可用性和重启的速度没有直接关系。高可用性一定要通过多个副本来实现,在任何一个挂掉之后,不能通过这一个应用快速重启来解决,而是应该靠挂掉的期间,其他的副本马上把任务接过来进行解决。虚拟机和容器都可以有多副本,在有多个副本的情况下,重启是一秒还是20秒,就没那么重要了,重要的是挂掉的这段时间内,程序做了什么,如果程序做的是无关紧要的操作,那么挂了20秒,也没啥关系,如果程序正在进行一个交易和支付,那挂掉一秒也不行,也必须能够修复回来。所以应用的高可用性要靠应用层的重试,幂等去解决,而不应该靠基础设施层重启的快不快来解决。

对于无状态服务,在做好重试的机制的情况下,通过自动重启修复是没有问题的,因为无状态的服务不会保存非常重要的操作。

微信图片_20180807173206

对于有状态服务,容器的重启不但不是推荐的,而且可能是灾难的开始。一个服务有状态,例如数据库,在高并发场景下,一旦挂了,哪怕只有一秒,我们必须要弄清楚这一秒都发生了什么,哪些数据保存了,哪些数据丢了,而不能盲目的重启,否则会很可能造成数据的不一致性,后期修都没法修。例如高频交易下的数据库挂了,按说DBA应该严格审核丢了哪些数据,而不是在DBA不知情的情况下,盲目的重启了,DBA还觉得没什么事情发生,最终很久才能发现问题。

所以容器比较适合部署无状态服务的,随便重启都可以。

微信图片_20180807173210

而容器部署有状态容器不是不能,而是要非常小心,甚至都是不推荐的。虽然很多的容器平台都支持有状态容器,然而平台往往解决不了数据问题,除非你对容器里面的应用非常非常非常熟悉,当容器挂了,你能够准确的知道丢了哪些,哪些要紧,哪些不要紧,而且要写代码处理这些情况,然后才能支持重启。网易这面的数据库主备同步的情况下,是通过修改mysql源代码,保证主备之间数据完全同步,才敢在主挂了的情况下,备自动切换主。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读