闭门会:企业的容器化改造之道

  • 薛梁

2016 年 9 月 14 日

话题:架构DevOps语言 & 开发文化 & 方法Kubernetes运维

编者按:容器技术作为目前一项炙手可热的新技术,具有很多的优势,比如轻量化、简单易用、稳定性高。同时,它与微服务、DevOps 等流行的理念也不谋而合,受到越来越多的公司关注,本届CNUTCon 2016 容器大会中的很多电信和金融公司都已经逐步开始容器化,部署自己的容器云平台。但容器技术并不是万能,特别是对于刚刚发展只有 3 年的 Docker 来说,Docker 等技术到底使用于怎么样的场景?对于不同的行业,在容器化之前,需要考虑哪些因素?容器化又可以有哪些收益?有什么样的门槛

为此,本次[架构师闭门会议]邀请了金融、电信、电商等行业的代表前来讨论他们在容器化过程中遇到的问题以及解决方案。

为什么会考虑容器,目前的顾虑或者问题是什么?为什么没有考虑用 VM?

金融云平台刚开始搭建的时候基本上是给自己用,后来提供给金融客户用。使用的计算的形态是定了三种:一开始是云平台,以前做云计算就计算形式进入运输机,实际上这个形态对很多用户来讲还不够,所以现在想经过三种不同的计算形态从小到大是容器、运储机还有 BMS 物理机三种平台都有,基于容器做的事情在于将容器放在 IS 上面,原来云储机上面再放在物理机上面,结果是效率高,减少中间环节,架构更可靠,故障概率小一些。此外,底下已经有云服务了,容器本身的隔离性不是特别好,如果放在 VM 上面相当于可以直接底下租户的网络隔离,根本不存在容器层解决网络隔离的事情。最后采用了两套方案,如果是在对外提供服务的租户形态就把容器放在 VM 上面,最好是一个租户里面如果有云储机、服务的话都在自己的网络环境里面。如果是自己内部使用往大平台部署可能就放在云储机上面,这两个技术方案各有优势。

证券公司引入容器技术到现在为止基本上所有应用的交付都是通过容器去交付的,从自身来讲容器技术是价值非常大的。之前传统证券行业没有太多的虚拟化能力,但同样需要有云服务,提供原生的特性。就是说它要能够容错,要能够去响应变化,自身开发的流程上要做持续集成,通过容器这一层可以做到弯道超车,因为容器出现之后可以马上把容器技术用到开发当中,能够快速的把所有应用迁移到容器平台,这就是容器技术对传统行业的一个好处。

上交所为什么会考虑要容器呢?之前也考虑过用 VM,但是因为企业性质和去 IOE 的大前提,所以不用商业的云服务。另外是不以盈利为目的,所以就没有使用VM。后来发现引入容器之后对整个软件的方式方法理念变化很大,原来都是单体应用。现在使用 Docker 之后,镜像打包都是统一的,自动化之后很方便。目前内部自己也在做 Docker 涉及到集群管理,做一个 cisco 离上云就不远了。但是也有顾虑,因为 Docker 本身是开源的,而企业自身开发的系统里分三类:交易、业务处理、大数据,主要是担心 Docker 开源的性质会影响稳定性,但是仍然会尝试着做一些技术层面的改变。

恒生电子为为什么会考虑容器?因为应用的环境依赖,举个例子,32 位上的库跑到 64 位上经常要装很多依赖的包,而且会有一些冲突或者用其他的库,这时候工程运维或者让券商运维人员在安装包的时候会有问题,所以考虑使用 Docker 容器会比较好用。其次,恒生电子是传统的软件提供商,客户所有软件在虚拟机上或者是在物理机上对于恒生电子自身来说没有太多的影响,但是后来客户采购了类似的虚拟化程序,恒生电子是跑在虚拟机上面,这样对接起来就比较方便。恒生碰到的问题应该有两个,第一个问题是网络方面的,因为有些交易系统对延时要求是比较高的,要求低延时,这时候到底 Docker 采用哪种方案也是个问题,到底用什么样的网络方案还是急速交易、快速交易的,延时越低越好甚至微秒级别的,这时候考虑 Docker 会更好?另一个问题就是传统的软件厂商面对容器运维这个问题,其实是运维人员不一定是厂商,有可能是各个用户自己做运维的,经验不足的话会遇到很多问题。

容器技术选型落地怎么做?

根据专家们讨论的结果,现在可选的方案有几种:

  • 一个是在 IS 之上用 Mesos,在其他基础上做了包装更好用,让 Mesos 先做分布式的治理,用它制定 Mesos 的容器是足够的
  • 另外一块是用 DevOps,一个是物理机上一个是云平台上。
  • 在架构层面选择一些开源技术。
  • 在使用分布式容器技术上要遵循 CAP 理念,和一致性指间做好权衡。
  • 保证框架可用性的逻辑,尽量不修改。

容器落地过程中的一些坑、一些经验!

阿里最早在 Docker 上遇到的坑是在存储的隔离性上面,由于早期网络选型上的困惑,因为用户不希望一个 IP 多人共享。所以后来使用 Docker,用 Docker 整合服务这块主要还是从用户习惯重点考虑。经验上可以说,在网络上也做的比较简单,还是用的独占型的网络,像安全尤其是磁盘隔离都是自己写,做了很多定制的安全性,用的比较克制。但是存储从来不拿 Docker 存储,都是用集团内部的数据库。面对上交所这样的传统企业,在安全方面,用了 Docker 之后那些老的安全配置规范基本上都抛弃了,根据自身的需求重新设计。

搜狗之前遇到的问题大概就是 DockerRM 不能删除,近期或者之前面临的问题是 OM 的问题,如果客户端被 OM 掉,集群上就会存在一个脚本,这个脚本是不会被杀死的,同时跑两个一样的脚本是资源的浪费,其次面临最大的问题就是 DockerOM。现在处理方式是记录下来要存个位置,写的过程中有延迟,是异步执行的。

部分电商使用容器技术并不担心挂掉,最怕它的运行速度慢,因为不知道是挂还没挂,这种情况最直接的要求就是代码的密导性,这种密导性的实现是对开发业务的人更高的要求,因为他们可能没有考虑过这些东西,数据可能不完整,这就要有定时的修复,或者有好的处理方式,这确实可能是对现在的开发人员具有挑战的。

『架构师俱乐部』

架构师俱乐部是国际知名技术社区 InfoQ 发起和主办的,以资深架构师为主的不定期技术交流活动,旨在通过及时的分享和深入的交流,在资深技术人员之间搭建一个平台,让彼此之间的信息无障碍流通,同时增加彼此识朋交友的机会。

架构DevOps语言 & 开发文化 & 方法Kubernetes运维