《专家观察 | 汤人杰:“浙江移动DCOS规模实践与演进”》要点:
本文介绍了专家观察 | 汤人杰:“浙江移动DCOS规模实践与演进”,希望对您有用。如果有疑问,可以联系我们。
由工业和信息化部指导,中国信息通信研究院主办,业界知名组织云计算开源产业联盟(OSCAR)承办的2017全球云计算开源大会于4月19日-20日在北京国家会议中心顺利召开.本文为本届大会嘉宾分享的大会演讲速记内容,敬请浏览.
嘉宾介绍:汤人杰
公司职务:中国移动通信集团浙江有限公司高级架构师
大会演讲速记
非常荣幸有机会来这里跟大家分享我们浙江移动在云计算方面的实践.我主要分享的议题是DCOS,可以说谷歌很早就有,在运营商内部我们自主研发这个平台还是做得比较早.先讲一下整个驱动力,云计算的驱动力有很多种说法,把大家也都说得云里雾里.
有很多的名词,比如像去IOE、DevOps敏捷开发,在这些东西的背后,云计算最根本的商业驱动力是什么,更高的效率、更低的成本以及更敏捷的业务响应,这样就能支撑我们降低TCO,第二是小前台、大前台的快速业务敏捷的变化.
为了达到云计算的效果,我们浙江公司这几年来从传统的IT孤岛到最后的DCOS化,中间也经历了一个漫长的历程,前前后后七八年总是有的.
最早的时候我们用的都是小型机和高端存储,在上面独立做应用,都是孤岛的程序,每一套应用有很多套,每套都是独立的,机器也百花齐放,有用惠普的芯片,也用Spark的芯片,还有用IBM的,各不相同.
那时候我们做了标准化,都用了X86芯片.再接下来我们在IaaS层做了资源池化,我们当时用VMware软件做了虚拟化,我们实现了虚拟机级的弹性伸缩,超过单台物理机就没办法弹性伸缩了,所以是非常有局限的.后来我们又做了PaaS化,做了集群级的弹性伸缩,通过集群间的负载均衡,做了PaaS的云化,我们在中间件这个层面做了切换.
最后我们参考了谷歌和阿里云的架构,做了DCOS化,真正做到细粒度的资源贡献,实现大云,这时候我们资源调度和弹性伸缩不再局限单台物理机,而是在整个浙江移动的数据中心就可以快速切换,实现了数据中心级的弹性伸缩,这也就是DCOS名称的来源.这种级别的弹性伸缩和资源隔离是DCOS化一个非常大的特点.
这个历程里面,IaaS层云化不足的问题有几个地方,一个是部署是静态的,快速的应用部署受到很大的制约.
其实说到底,虚拟化无非就是装了个VMware软件,上面把它格成几个虚拟机,跟在物理机上除了管理方便一点,没有特别大的区别,可能资源的利用率更细一点,大的区别没有,因为它的应用还是要完全重新部署的.
弹性伸缩更加谈不上,在一个虚拟机内部弹性伸缩,客观上讲,当时我们甚至没有在物理机内部做弹性伸缩,没有必要,找不到任何的驱动.利用率低,CPU平均利用率10%.
在这个情况下,我们提出了我们整个云平台的蓝图,我们要构建我们的大云,我们要建浙江移动自主研发的大云,做我们的DCOS.这个DCOS大概是在2015年、2016年这个时间完成的,大概分成这么几个部分.底层还是IaaS层,IaaS层不细讲了,重点讲PaaS层.PaaS层上面我们做了一个弹性计算服务平台,其实跟阿里的飞天是一样的.
我们做了一套分布式协调服务、分布式调度服务和负载均衡的一套东西,整个一套东西能够实现我们在数据中心层面的资源调度.上面我们到底调度了什么进程,比如说有中间件的进程,有数据库服务平台,还有大数据的一些服务,这是在它之上的承载的一些服务,网管的支撑系统,业务的支撑系统,还有管理信息系统等,这个是大类,不重点展开了.需要去运维的东西还有一个云管理平台,通过这个云管理平台我们可以做一些一站式的开发,可以做一些运维、配置管理等等,包括一些容量的管理.
什么是DCOS,数据中心操作系统,是整个移动公司所有的异地的机房全部加进去,所有机房里的所有服务器我当成一个大型计算机来调度.
通过这个思路,我们打破静态隔离,实现资源共享.云化有两个重要的特点,一个是资源调度,一个是资源隔离.在资源调度方面,DCOS实现了数据中心级的资源调度.
在资源隔离方面,我们也抛弃了传统虚拟机比较笨重的模式,采用容器进行资源隔离.
下面是个互联网的图,不同的几种运算模式,可能有些说是晚上运算比较密集,有些说白天比较密集,如果联合起来统一的资源调度,整体的CPU利用率就会非常高,削峰填谷,云化的集约效果真正体现出来了,不像以前纯粹的虚拟化模式下,CPU利用率仍然非常低.
这一页是我们当初1.0版本的DCOS平台整体架构,可以看到核心是采用Mesos这个平台,用马拉松作为一个任务型的调度器,Mesos作为一级调度,去分配资源,通过MesosSlave启我的一个任务,里面的Container主要做仲裁的一些功能.
DCOS总体推进策略,DCOS这个平台研发出来以后,在内部是有争议的,大家认为比较先进,但是不一定稳定,确实也是这样.我们当时就考虑了采用先前端后后端推进的DCOS平台,先推进的是手机营业厅和CRM,然后是PaaS企业的核心服务,中心全部做了DCOS的改造.
看一下我们改造的顺序,第一个改造的是我们的手机营业厅,手机营业厅做秒杀的时候性能不行,确实存在着瓶颈,当秒杀的时候基本上手机访问量是平时访问量几百倍,这个时候确实性能产生很大的瓶颈,这个瓶颈有两方面,中间件和数据库,我们都做了改进,重点讲一下中间件方面的改进.Web服务全部建议到了DCOS,服务的可用性99.99%,基本上很好的完成了当时秒杀的活动.
第二个是实体营业厅,所有营业厅的服务,我们十年以前就是三层架构了,首先是WEB层,后面是APP层,还有数据库层.要改造,瞬间迁移,快速failover,把WEB信息无状态化,前端能够动态注册,就像前面写的服务的动态注册和发现一样,要能动态注册和发现.
通过对它的改造,把有状态信息都放在了Redis里面.这是我们浙江移动整体的架构,前端是WEB这一层,全部都把它做上去了.
我们当时第二个改造的时候做了一个中心化的改造,我们根据高内聚、低耦合、高自治、高复用原则,都说高内聚,怎么内聚,我认为是按照领域模型内聚的,以微服务的技术手段对它进行一个服务的部署和服务的设计.最终这些服务都承载在我们的DCOS平台上去.
当时整个SaaS层规划了14个核心的能力中心,当时有线建设的是订单中心、开通中心、账户中心、计费中心和渠道中心.到这个节点上,基本上我们整体的系统已经全部搬到了DCOS上面去.当然大家也应该听出来,我说的搬到DCOS上面去指的是WEB层和APP这一层,就是中间件的那一层,数据库的服务到目前为止肯定还不可能实现数据中心级的伸缩.
DCOS建设至今,我们整体已经接入65套系统,从地市怎么分的,两个分发,一个是按照地市支撑和省支撑.地势支撑有24套系统,省业务支撑有41套系统.
如果按互联网系统、前端系统、后端核心系统、外围系统划分,互联网类有15套,前端系统有12套,后端核心类有14套,APP这一层,相当于复用的核心能力层已经迁移上去了.外围的系统有24套系统已经迁上去了,包括金华综合管理平台、台州考试系统等等.
DCOS无论在技术上还是实用性上还是应用的迁移上都应该经受了考验,应该说相当的稳定和可靠.
这套系统我们有哪些创新点,一个,我们有一套ADCloud的平台,通过和DCOS平台对接,通过ADCloud平台能够打通开发、测试交付、运维部署全流程,实现代码编译、单元测试和生产部署的一键化和自动化,极大提高软件开发部署效率.
第二个,向租户开放一站式运维服务,整个DCOS平将发布、扩容、重启、日志下载等等这些工作全部做到标准化、自动化,通过可视化界面让运维管理人员、租户人员自行管理,做到理解一致、执行一致、结果一致.
弹性扩缩容,传统的在虚拟机时代我们说弹性扩缩容多么困难,如果平时部署在那边不用又浪费大量的资源.
从传统的方式2-3天缩短到秒级,业务进来以后,会收集各方面的信息,根据一个自己学习的策略,做到自动弹性扩缩容.
这是原来的开源产品不具备的功能,虽然说我们也是整合了开源的产品.这里讲弹性扩缩容怎么做,我们从各个层面,Docker、Mesos、Marathon、HAProxy、Application,最后形成了给Marathon下发的扩容的任务.
最后讲一下DCOS3.0后续的演进规划,第一点是统一API,现在是用Python写的,后面会用Golang全部重构.
微服务设计,容器部署支持用户自定义开发API,依托API功能扩展服务范围安全加固.镜像库,企业级自定义镜像仓库.
融合支持,新增kubernetes、Spark、Hadoop支持,新增Array调度管理功能,支持灰度发布.服务集成除了现有的无状态服务以外,我们将加入有状态的服务,比如Redis、ES、MySQL、MQ.
另外一块,我们将会增加数据持久化的一些服务,还会采用一些网络层面的,使得DCOS平台变得更加完善,能够支撑更多类型的应用.
这个是我们的云管理平台,我们现在也在自主研发云管理平台,云管理平台会有一个统一的门户,通过一个总线下面有四大中心,通过一套资源接口平台去对接底层的能力层.
最后是我们的数据资源池,Oracle这些目前包括跟阿里交流,他们也都是直接用物理机上做,因为Oracle这种东西太重,有状态的服务实在太重,也不适合放到DCOS这样的平台里去,所以我的资源对大概就对接一个是数据库、大数据、DCOS还有IaaS层,我们会把它对接统一封装之后,在我们的云管理平台里进行统一的运营、资源管理、运维开发的一键式支撑.
谢谢大家.
文章来自微信公众号:云计算开源产业联盟
转载请注明本页网址:
http://www.vephp.com/jiaocheng/4094.html