容器化,微服务,DevOps,什么情况下会三位一体?-创新互联

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

创新互联是一家专注于成都网站设计、网站建设与策划设计,孝义网站建设哪家好?创新互联做网站,专注于网站建设十年,网设计领域的专业建站公司;建站业务涵盖:孝义等地区。孝义做网站价格咨询:18980820575

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

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

没办法,一个字:拆

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

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

所以称为微服务。

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

容器的正确使用场景:

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

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

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

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

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

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

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

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

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


名称栏目:容器化,微服务,DevOps,什么情况下会三位一体?-创新互联
网站URL:http://myzitong.com/article/jpejg.html