上交所业务系统的Docker化实践

上交所业务系统的Docker化实践_第1张图片

(上图为上交所架构师黄成)

  在日前数人云战略2.0的发布会上,来自上交所的架构师黄成介绍了上交所业务系统Docker的实践。
  数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。基于Docker+Mesos,数人云致力于打造最轻量化的PaaS平台。


  以下为黄成的分享,略经编辑:
  黄成:今天我跟大家分享一下上交所作为一个传统金融企业对Docker新技术的探索和实践。
  首先解释一下上交所的业务系统,这是一个除交易平台之外,还对业务数据进行处理的一个操作系统。在这个系统的开发和运维过程中,我们碰到了开发和运维分工量的问题。我们现在的开发和运维属于两个独立的部门,而且两个部门之间技术沟通一般都是通过公文或者备忘录等渠道,不是一个密切、高效的沟通方式。
  为了提高资源的利用率,我们的业务系统在一个节点上共享部署。在这个节点上,开发和运维的分工比较细,运维部门负责对操作系统的技术运维,应用的运维实际上是由开发部门负责的。在这样一个沟通架构下面,把运维工作分得这么细,其实对公司带来有很多不便,我们也一直在寻找一个解决方案。


  选择Docker的四个原因
  之所以选择Docker,可能比较简单,有四个原因。首先就是虚拟化。我们开发和运维,资源利用的环境管理,用虚拟化的方式来解决是比较正确的方向,这是有共识的。其次,Docker现在确实是热门,包括微信朋友圈、网站上都能看到相关介绍,Docker跟以前的DevOps、微服务等热门话题也密切联系,我们想通过接触Docker来获得额外的收益。第三是Docker入门真的非常简单,只要装上Docker daemon,写一个两到三行的Dockerfile,就能够看到效果。最后一个是开发主导,因为开发和运维分工来讲,运维基本上是做基础运维,我们把Docker当作应用型技术,由开发部门来主导,省了很多沟通的成本。


  容器云实践
  首先,我们做的是一种容器云,经过一段时间跟数人云密切的交流和合作,我们建立了自己的一个私有容器云。这个容器云主要是用它来解决三个方面的问题;第一个方面就是资源调度,之前的集群基本上都是手工管理。用了容器云之后,想做一个统一的自动化资源调度,当一个应用要上线的时候,不再需要去跟其它项目沟通协调资源,也不需要跟运维协调,减少了成本、提高了效率。另外就是软件发布,也是想借助Docker的特性来制定标准化的软件发布过程。目前,我们的软件发布过程可以说是五花八门,经常会有人来抱怨说为什么这个包运行不起来或者为什么两次运行的结果不一样等,所以想通过Docker来解决这样的问题。第三,就是集群的监控与部署。我们想制定一个比较标准化的监控平台,所有的应用都是按同一个方式去处理。另外,我们也想把运维所监控到数据及时反馈给开发,促进软件水平的发展和软件能力的提升。


  Docker不能解决所有的问题
  但是当真要做这个事情的时候,发现Docker并不能完全解决所有的问题。首先我们基础设施比较落后,操作系统不能很好地支持Docker操作系统;其次,我们的网络环境跟外网完全隔离。第三,我们想改变目前对集群管理手工运维的方式,也想做自动化的集群管理。第四,用了Docker之后,现有的应用监控系统也不能满足需求,所以还需要建设这样一套体系。第五,对于上层来说,现有软件规范包括安全配置,其实都没有覆盖Docker。第六,对于用Docker,我们还关注到微服务和分布式架构,所以也引进来。为了满足分布式架构,也想构建一套自动化、更高效的软件构架。


  软件架构的演变
  有了容器云之后,我们自然就会想到软件分布式架构,也在尝试将微服务架构引入到软件体系里面来。目前上交所的业务系统基本上是一个单体的MVC架构,这有两个挑战:第一就是三十个人左右的项目团队,功能比较多,特别赶时间,所以采用敏捷开发、迭代交付的方式,但是到了版本发布的时候确实还是非常困难。第二个就是软件质量基本上都是在功能测试最后一关去把守,导致业务系统的质量很难提上去。那么在微服务架构中,我们首先基于微服务的方式,每个服务有自己的版本,在整个软件来看每个服务的小版本都是有序协调;另外就是微服务架构,会把软件做前端、API接入和微服务的分层,在每一层都会加入质量控制,从而规避质量风险。


  软件过程自动化
  有了容器云和新的软件架构,我们也想把软件过程做得更加自动化、更加高效。在软件过程自动化中,容器云是非常值得期待的。第一个就是在开发阶段,它能够便利的提供开发工具,比如说Jenkins,我们之前的Jenkins节点管理比较松散,基本上每个项目有一套。希望用Jenkins on Cloud的方案,能够在更新的时候,就不需要去申请主机、不需要去部署,直接在Jenkins新建一个Job就可以了。对于测试环节,我们也特别重点关注。后面的接口测试、UI测试、功能测试,希望通过Docker或者容器云应用编排的能力,能够在几分钟之内构建一个测试环境去做自动化,这样可以极大的降低测试门槛。然后在软件发布的时候,由于Docker也有标准化环境的特性,可以加速这块的进程。目前我们的业务系统由于采用主备灾的架构、多节点部署,正常下来应该是在一到两个小时成功部署完一套操作系统,通过Docker也希望把这时间降到半个小时以内或者更少的时间。


  遇到的挑战
  希望容器云帮助把我们的软件和基础设施发展的核动力提上去。作为一个传统企业,我们也会碰到问题,接下来特别分享一下遇到的挑战。首先,我们开发网络与外网是完全物理隔离,这对构建一个自动化的软件过程是很头疼的问题。另外就是我们的开发网、生产网和外网又是完全隔离的,大家可能安装一个开源包只要几秒钟,在我们这里可能是五小时。我们正在想尽一切办法去解决这些技术挑战。
  其次就是严格的技术标准,我们的操作系统目前用的是Redhat6,如果想更好的用Docker,那么就必须说服相关的人去用Redhat7。另外一块就是Docker用sudo的方式来管理应用,我们认为这种方式是无法接受的,它会提出一个问题说:用sudo的方式管理应用,怎么知道是为了哪些应用,会不会让系统崩掉?所以还要详细的列出容器云到底需要什么样的最小权限才能运行下去,这也是我们比较期盼的地方。
  在投入方面,我们基本上是一个业务导向的单位,在技术基础设施投入这块一般都是以小投入或者试点为主,也找了像数人云这样的战略合作伙伴一起完成这个目标。
  最后一个是Docker的局限性,这可能更多的是跟基础设施有关系,我们现在做了容器云,对于IaaS层的资源管理,包括网络以及分布式存储其实都是空白的或者说不能充分满足我们的需求,我们也在探索新的解决方案。
  因为我们也在尝试技术的转型,也在想向互联网行业学习新的技术和方法,愿意跟大家做进一步的交流。(文/宁川)


  【更多精彩内容 尽在《云科技时代》微信 微信号:CloudTechTime】


你可能感兴趣的:(云计算,docker,red,hat,容器云)