有关容器的六大误区和八大正确场景
|
而宣传有状态容器的自动重启，对于服务客户来讲是很不经济的行为，因为客户往往没有那么清楚应用的逻辑，甚至应用都是买的，如果使用有状态容器，任凭自动重启，最终客户发现数据丢失的时候，还是会怪到你的头上。 所以有状态的服务自动重启不是不可用，需要足够专业才行。 误区五：容器可以使用容器平台进行服务发现 容器平台swarm, kubernetes，mesos都是支持服务发现的，当一个服务访问另一个服务，都会有服务名转化为VIP，然后访问具体的容器。
然而人们会发现，基于Java写的应用，服务之间的调用多不会用容器平台的服务发现，而是用Dubbo或者spring cloud的服务发现。因为容器平台层的服务发现，还是做的比较基础，基本是一个域名映射的过程，对于熔断，限流，降级都没有很好的支持，然而既然使用服务发现，还是希望服务发现中间件能够做到这一点，因而服务之间的服务发现之间使用容器平台的少，越是需要高并发的应用，越是如此。
那容器平台的服务发现没有用了么？不是，慢慢你会发现，内部的服务发现是一方面，这些Dubbo和spring cloud能够搞定，而外部的服务发现就不同了，比如访问数据库，缓存等，到底是应该配置一个数据库服务的名称，还是IP地址呢？如果使用IP地址，会造成配置十分复杂，因为很多应用配置之所以复杂，就是依赖了太多的外部应用，也是最难管理的一方面。如果有了外部的服务发现，配置就会简单很多，也只需要配置外部服务的名称就可以了，如果外部服务地址变了，可以很灵活的改变外部的服务发现。 误区六：容器可以基于镜像进行弹性伸缩 在容器平台上，容器有副本数的，只要将副本数从5改到10，容器就基于镜像进行了弹性伸缩。其实这一点虚拟机也能做到，AWS的Autoscaling就是基于虚拟机镜像的，如果在同一个云里面，就没有区别。
当然如果跨云无状态容器的弹性伸缩，容器方便很多，可以实现混合云模式，当高并发场景下，将无状态容器扩容到公有云，这一点虚拟机是做不到的。
容器理解误区总结
如图，左面是经常挂在嘴边的所谓容器的优势，但是虚拟机都能一一怼回去。 如果部署的是一个传统的应用，这个应用启动速度慢，进程数量少，基本不更新，那么虚拟机完全能够满足需求。 应用启动慢：应用启动15分钟，容器本身秒级，虚拟机很多平台能优化到十几秒，两者几乎看不出差别 内存占用大：动不动32G，64G内存，一台机器跑不了几个。 基本不更新：半年更新一次，虚拟机镜像照样能够升级和回滚 应用有状态：停机会丢数据，如果不知道丢了啥，就算秒级启动有啥用，照样恢复不了，而且还有可能因为丢数据，在没有修复的情况下，盲目重启带来数据混乱。 进程数量少：两三个进程相互配置一下，不用服务发现，配置不麻烦 如果是一个传统应用，根本没有必要花费精去容器化，因为白花了力气，享受不到好处。 第二部分：容器化，微服务，DevOps三位一体
什么情况下，才应该考虑做一些改变呢？ 传统业务突然被互联网业务冲击了，应用老是变，三天两头要更新，而且流量增大了，原来支付系统是取钱刷卡的，现在要互联网支付了，流量扩大了N倍。 没办法，一个字：拆 拆开了，每个子模块独自变化，少相互影响。 拆开了，原来一个进程扛流量，现在多个进程一起扛。 所以称为微服务。
微服务场景下，进程多，更新快，于是出现100个进程，每天一个镜像。 容器乐了，每个容器镜像小，没啥问题，虚拟机哭了，因为虚拟机每个镜像太大了。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
