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

此文已由作者刘超授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验

误区五：容器可以使用容器平台进行服务发现

 

容器平台swarm, kubernetes，mesos都是支持服务发现的，当一个服务访问另一个服务，都会有服务名转化为VIP，然后访问具体的容器。

 

 

然而人们会发现，基于Java写的应用，服务之间的调用多不会用容器平台的服务发现，而是用Dubbo或者spring cloud的服务发现。因为容器平台层的服务发现，还是做的比较基础，基本是一个域名映射的过程，对于熔断，限流，降级都没有很好的支持，然而既然使用服务发现，还是希望服务发现中间件能够做到这一点，因而服务之间的服务发现之间使用容器平台的少，越是需要高并发的应用，越是如此。

 

那容器平台的服务发现没有用了么？不是，慢慢你会发现，内部的服务发现是一方面，这些Dubbo和spring cloud能够搞定，而外部的服务发现就不同了，比如访问数据库，缓存等，到底是应该配置一个数据库服务的名称，还是IP地址呢？如果使用IP地址，会造成配置十分复杂，因为很多应用配置之所以复杂，就是依赖了太多的外部应用，也是最难管理的一方面。如果有了外部的服务发现，配置就会简单很多，也只需要配置外部服务的名称就可以了，如果外部服务地址变了，可以很灵活的改变外部的服务发现。

 

误区六：容器可以基于镜像进行弹性伸缩

 

在容器平台上，容器有副本数的，只要将副本数从5改到10，容器就基于镜像进行了弹性伸缩。其实这一点虚拟机也能做到，AWS的Autoscaling就是基于虚拟机镜像的，如果在同一个云里面，就没有区别。

 

当然如果跨云无状态容器的弹性伸缩，容器方便很多，可以实现混合云模式，当高并发场景下，将无状态容器扩容到公有云，这一点虚拟机是做不到的。

 

 

容器理解误区总结

 

 

如图，左面是经常挂在嘴边的所谓容器的优势，但是虚拟机都能一一怼回去。

 

如果部署的是一个传统的应用，这个应用启动速度慢，进程数量少，基本不更新，那么虚拟机完全能够满足需求。

 

• 应用启动慢：应用启动15分钟，容器本身秒级，虚拟机很多平台能优化到十几秒，两者几乎看不出差别

• 内存占用大：动不动32G，64G内存，一台机器跑不了几个。

• 基本不更新：半年更新一次，虚拟机镜像照样能够升级和回滚

• 应用有状态：停机会丢数据，如果不知道丢了啥，就算秒级启动有啥用，照样恢复不了，而且还有可能因为丢数据，在没有修复的情况下，盲目重启带来数据混乱。

• 进程数量少：两三个进程相互配置一下，不用服务发现，配置不麻烦

 

如果是一个传统应用，根本没有必要花费精去容器化，因为白花了力气，享受不到好处。

 

第二部分：容器化，微服务，DevOps三位一体

 

 

什么情况下，才应该考虑做一些改变呢？

 

传统业务突然被互联网业务冲击了，应用老是变，三天两头要更新，而且流量增大了，原来支付系统是取钱刷卡的，现在要互联网支付了，流量扩大了N倍。

 

没办法，一个字：拆

 

拆开了，每个子模块独自变化，少相互影响。

拆开了，原来一个进程扛流量，现在多个进程一起扛。

 

所以称为微服务。

 

 

微服务场景下，进程多，更新快，于是出现100个进程，每天一个镜像。

 

容器乐了，每个容器镜像小，没啥问题，虚拟机哭了，因为虚拟机每个镜像太大了。

 

所以微服务场景下，可以开始考虑用容器了。

 

 

 

虚拟机怒了，老子不用容器了，微服务拆分之后，用Ansible自动部署是一样的。

 

这样说从技术角度来讲没有任何问题。

 

然而问题是从组织角度出现的。

 

一般的公司，开发会比运维多的多，开发写完代码就不用管了，环境的部署完全是运维负责，运维为了自动化，写Ansible脚本来解决问题。

 

然而这么多进程，又拆又合并的，更新这么快，配置总是变，Ansible脚本也要常改，每天都上线，不得累死运维。

 

所以这如此大的工作量情况下，运维很容易出错，哪怕通过自动化脚本。

这个时候，容器就可以作为一个非常好的工具运用起来。

 

除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。

 

这样做的好处就是，虽然进程多，配置变化多，更新频繁，但是对于某个模块的开发团队来讲，这个量是很小的，因为5-10个人专门维护这个模块的配置和更新，不容易出错。

 

如果这些工作量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量会大非常多。

 

容器是一个非常好的工具，就是让每个开发仅仅多做5%的工作，就能够节约运维200%的工作，并且不容易出错。

 

然而本来原来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？

 

这就不是技术问题了，其实这就是DevOps，DevOps不是不区分开发和运维，而是公司从组织到流程，能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。

 

 

 

所以微服务，DevOps，容器是相辅相成，不可分割的。

 

不是微服务，根本不需要容器，虚拟机就能搞定，不需要DevOps，一年部署一次，开发和运维沟通再慢都能搞定。

 

所以，容器的本质是基于镜像的跨环境迁移。

 

镜像是容器的根本性发明，是封装和运行的标准，其他什么namespace，cgroup，早就有了。这是技术方面。

 

在流程方面，镜像是DevOps的良好工具。

 

容器是为了跨环境迁移的，第一种迁移的场景是开发，测试，生产环境之间的迁移。如果不需要迁移，或者迁移不频繁，虚拟机镜像也行，但是总是要迁移，带着几百G的虚拟机镜像，太大了。

 

第二种迁移的场景是跨云迁移，跨公有云，跨Region，跨两个OpenStack的虚拟机迁移都是非常麻烦，甚至不可能的，因为公有云不提供虚拟机镜像的下载和上传功能，而且虚拟机镜像太大了，一传传一天。

 

所以跨云场景下，混合云场景下，容器也是很好的使用场景。这也同时解决了仅仅私有云资源不足，扛不住流量的问题。

 

第三部分：容器的正确使用场景

 

根据以上的分析，我们发现容器推荐使用在下面的场景下。

 

1. 部署无状态服务，同虚拟机互补使用，实现隔离性

 

2. 如果要部署有状态服务，需要对里面的应用十分的了解

 

3. 作为持续集成的重要工具，可以顺利在开发，测试，生产之间迁移

 

4. 适合部署跨云，跨Region，跨数据中心，混合云场景下的应用部署和弹性伸缩

 

5. 以容器作为应用的交付物，保持环境一致性，树立不可变更基础设施的理念

 

6. 运行进程基本的任务类型的程序

 

7. 用于管理变更，变更频繁的应用使用容器镜像和版本号，轻量级方便的多

 

8. 使用容器一定要管理好应用，进行health check和容错的设计

相关阅读：有关容器的六大误区和八大正确场景 （1）

容器服务是网易云提供的无服务器容器服务，让企业能够快速部署业务，轻松运维服务。容器服务支持弹性伸缩、垂直扩容、灰度升级、服务发现、服务编排、错误恢复及性能监测等功能。点击可免费试用。

免费体验云安全(易盾)内容安全、验证码等服务

更多网易技术、产品、运营经验分享请点击。