专家观察 | 汤人杰：“浙江移动DCOS规模实践与演进”(2)

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平台变得更加完善,能够支撑更多类型的应用.

这个是我们的云管理平台,我们现在也在自主研发云管理平台,云管理平台会有一个统一的门户,通过一个总线下面有四大中心,通过一套资源接口平台去对接底层的能力层.

（编辑：ASP站长网）