有关容器的六大误区和八大正确场景
|
spark的这种做法思想类似无服务架构，你会发现我们原来学操作系统的时候，说进程粒度太大，每次都创建和销毁进程会速度太慢，为了高并发，后来有了线程，线程的创建和销毁轻量级的多，当然还是觉得慢，于是有了线程池，事先创建在了那里，用的时候不用现创建，不用的时候交回去就行，后来还是觉得慢，因为线程的创建也需要在内核中完成，所以后来有了协程，全部在用户态进行线程切换，例如AKKA，Go都使用了协程，你会发现趋势是为了高并发，粒度是越来越细的，现在很多情况又需要进程级别的，有种风水轮流转的感觉。 误区三：容器有镜像，可以保持版本号，可以升级和回滚 容器有两个特性，一个是封装，一个是标准。有了容器镜像，就可以将应用的各种配置，文件路径，权限封装起来，然后像孙悟空说“定”,就定在了封装好的那一刻。镜像是标准的，无论在哪个容器运行环境，将同样的镜像运行起来，都能还原当时的那一刻。 容器的镜像还有版本号，我们可以根据容器的版本号进行升级，一旦升级有错，可以根据版本号进行回滚，回滚完毕则能够保证容器内部还是原来的状态。
但是OpenStack虚拟机也是有镜像的，虚拟机镜像也是可以打snapshot的，打snapshot的时候，也会保存当时的那一刻所有的状态，而且snapshot也可以有版本号，也可以升级和回滚。
似乎容器有的这些特性OpenStack虚拟机都有，二者有什么不同呢？ 虚拟机镜像大，而容器镜像小。虚拟机镜像动不动就几十个G甚至上百G，而容器镜像多几百M。 虚拟机镜像不适合跨环境迁移。例如开发环境在本地，测试环境在一个OpenStack上，开发环境在另一个OpenStack上，虚拟机的镜像的迁移非常困难，需要拷贝非常大的文件。而容器就好的多，因为镜像小，可以很快的从不同的环境之间迁移。 虚拟机镜像不适合跨云迁移。当前没有一个公有云平台支持虚拟机镜像的下载和上传(安全的原因，盗版的原因)，因而一个镜像在不同的云之间，或者同一个云不同的region直接，无法进行迁移，只能重新做一个镜像，这样环境的一致性就得不到保障。而容器的镜像中心是独立于云之外的，只要能够连上镜像中心，到哪个云上都可以下载，并且因为镜像小，下载速度快，并且镜像是分层的，每次只需要下载差异的部分。 OpenStack对于镜像方面的优化，基本上还是在一个云里面起作用，一旦跨多个环境，镜像方便的多。 误区四：容器可以使用容器平台管理自动重启实现自修复 容器的自修复功能是经常被吹嘘的。因为容器是衣服，人躺下了，衣服也躺下了，容器平台能够马上发现人躺下了，于是可以迅速将人重新唤醒工作。而虚拟机是房子，人躺下了，房子还站着，因而虚拟机管理平台不知道里面的人能不能工作，所以容器挂了会被自动重启，而虚拟机里面的应用挂了，只要虚拟机不挂，很可能没人知道。 这些说法都没错，但是人们慢慢发现了另外的场景，就是容器里面的应用没有挂，所以容器看起来还启动着，但是应用以及不工作没有反应了。当启动容器的时候，虽然容器的状态起来了，但是里面的应用还需要一段时间才能提供服务。所以针对这种场景，容器平台会提供对于容器里面应用的health check，不光看容器在不在，还要看里面的应用能不能用，如果不能，可自动重启。 一旦引入了health check，和虚拟机的差别也不大了，因为有了health check，虚拟机也能看里面的应用是否工作了，不工作也可以重启应用。 还要就是容器的启动速度快，秒级启动，如果能够自动重启修复，那就是秒级修复，所以应用更加高可用。 （编辑：网站开发网_安阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
