ITPub博客

容器化,微服务,DevOps,什么情况下会三位一体?

Docker/K8 作者:danny_2018 时间:2018-08-07 18:11:55 0 删除 编辑

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

 

传统业务突然被互联网业务冲击了,应用老是变,三天两头要更新,而且流量增大了,原来支付系统是取钱刷卡的,现在要互联网支付了,流量扩大了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和容错的设计


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31547898/viewspace-2199349/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-07-30

  • 博文量
    69
  • 访问量
    73064